Добрый вечер, Александр! «Бьёрн Страутструп упорно доказывал, что эффективность ++ не ниже, а иногда и выше, чем С на то время.»
Знаем эти басни. Эффективность достигается объёмом кода и временем компиляции. Функция qsort() языка Си принимает указатель на функцию сравнения и для каждого сравнения осуществляется косвенный доступ. Функция std::sort() может быть проспециализирована компаратором во время выполнения — на каждый компаратор будет построен свой экземпляр функции std::sort(). Объём экзешника clang++.exe около 50 Мбайт. 50 миллионов байт. Интересно, сколько среди этого кода написано вручную, а сколько развернулось из инстанцирований всяких std::vector’ов? Для сравнения дистрибутив Windows 95 занимал сравнимый объём. Дистрибутив неплохой для своего времени операционной системы. «Недостатком С мне видится не вполне ясная его портируемость. … особенно если нужно подключать различные специфические библиотеки.» Я решил проблему так: в самом компиляторе не используется ничего, кроме стандартной библиотеки языка и стандартных API операционной системы. Я поддерживаю Windows, Linux и macOS. Правда, есть некоторые проблемы на запуске Linux’а десятилетней давности. На Windows я по умолчанию собираю проект компилятором C++ 20-летней давности (быстро компилирует). «Зато разработчики обещают полную совместимость кода на целом ряде платформ.» Включая Windows XP? Вообще, мне бы хотелось, чтобы Рефал-5λ мог бы работать даже на Windows 98. Но, к сожалению, в актуальной версии дистрибутива используются bat’ники для cmd.exe и на Windows 98 они не запустятся. А переписывать на батники для command.com я считаю нецелесообразным. «Насчёт golang: автоматизация работы с памятью касается прежде всего полбъектного malloc , для цепочек никто не мешает организовать выделение большими блоками и оптимизировать самому.» Проблема не только в этом. Как на счёт union? Go я знаю довольно поверхностно, но объединений в нём вроде нет. Возможно я не прав, но я слышал, что в Go очень высокий оверхед на вызов сишных функций. Что как минимум, обращение к системным вызовам в нём дороже, чем из Си. «Для меня главным свойством при выборе была возможность лёгкого подключения к проекту всех современных технологий, даже ещё не существующих.» У меня не было такой цели. У меня есть более близкая цель: Рефал с интерфейсом к языку Си. Чтобы можно было писать свои библиотеки на Си и загружать их из кода Рефала. Цель более-менее достигнута, но имеющийся интерфейс меня категорически не устраивает, его надо серьёзно перепроектировать. Ну и заодно переписывать рантайм. «Производительность же современных серверных платформ весьма высока, что в большинстве случаев позволяет снизить критичность оптимизации и скорости выполнения задач. Но это моё мнение на данный момент.» Меня больше интересуют домашние машины, причём не самые свежие и производительные. Например, на стареньком нетбуке компилятор раскручивает себя за 2 минуты и это много. Одна из причин — неудачная система команд байткода, гораздо хуже байткода Романенко. Её надо перепроектировать. Ну и заодно переписывать рантайм. С уважением, Александр Коновалов From: Александр Гусев gusev_aleksandr_AT_mail.ru <[email protected]> Sent: Tuesday, May 18, 2021 11:56 PM To: Александр Коновалов <[email protected]>; refal <[email protected]> Subject: Re: RE: RE: RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e Александр, Конечно я признаю С очень ясным с точки зрения оптимизации и компактности кода. Опыт был около 10 лет программирования на нём весьма нагруженных систем. Относительно С++ могу сказать, что его автор, Бьёрн Страутструп упорно доказывал, что эффективность ++ не ниже, а иногда и выше, чем С на то время. Беда в современных шаблонах и библиотеках. К слову, мне на этом языке не удалось сделать чего-нибудь значимого. Недостатком С мне видится не вполне ясная его портируемость. Если для установки его для микроконтроллера или АТС можно и повозиться, то для менее тиражируемых проектов это может оказаться лишней тратой сил, особенно если нужно подключать различные специфические библиотеки. Или я не знаю текущего положения дел с языком. Насчёт golang: автоматизация работы с памятью касается прежде всего полбъектного malloc , для цепочек никто не мешает организовать выделение большими блоками и оптимизировать самому. Зато разработчики обещают полную совместимость кода на целом ряде платформ. Без «танцев с бубном». При выборе базового языка я рассматривал также node.js. Который нынче тоже весьма шустрый и компилируемый. Для меня главным свойством при выборе была возможность лёгкого подключения к проекту всех современных технологий, даже ещё не существующих. Производительность же современных серверных платформ весьма высока, что в большинстве случаев позволяет снизить критичность оптимизации и скорости выполнения задач. Но это моё мнение на данный момент. Отправлено из мобильной Почты Mail.ru вторник, 18 мая 2021 г., 17:53 +0300 от Александр Коновалов <[email protected] <mailto:[email protected]> >: Александр! Цель перевода рантайма на Си — переход на более низкоуровневый язык. Не смотря на то, что на C++ можно писать также, как и на Си, всё-таки стиль программирования на обоих языках различается. На C++ проще вводить новые абстракции: классы с методами, шаблоны, у C++ есть богатая библиотека шаблонов и т.д. И из-за этого код пишется с избыточным числом абстракций, более высокоуровневый и, возможно, более медленный. А использование стандартных библиотечных контейнеров ещё и замедляет компиляцию. Бедность выразительных возможностей Си (по сравнению с C++, конечно) приводит к тому, что код получается более плотным и более низкоуровневым. Когда пишешь, больше думаешь об эффективности и экономии ресурсов. Ну, вот такие у меня ощущения и такое восприятие Си и C++. И исходя из этих ощущений, думаю, что Си лучше подходит как язык реализации рантайма языка. С Golang’ом я знаком и считаю его слишком высокоуровневым для написания рантайма. Для каждой конструкции языка Си можно догадаться, в какой машинный код она откомпилируется, для Golang’а это не всегда верно (на мой взгляд). К тому же в Golang’е есть сборка мусора, а тут мне хочется управлять памятью самому. У Си рантайм очень тонкий. У Golang’а рантайм наоборот толстый. С уважением, Александр Коновалов From: Александр Гусев <[email protected] <mailto:[email protected]> > Sent: Tuesday, May 18, 2021 3:28 PM To: Александр Коновалов <[email protected] <mailto:[email protected]> > Cc: Andrei Klimov <[email protected] <mailto:[email protected]> >; Arkady Klimov <[email protected] <mailto:[email protected]> >; Yuri Klimov <[email protected] <mailto:[email protected]> >; Antonina Nepeivoda <[email protected] <mailto:[email protected]> >; Igor Adamovich <[email protected] <mailto:[email protected]> >; Sergei Romanenko <[email protected] <mailto:[email protected]> >; Boyko Bantchev <[email protected] <mailto:[email protected]> >; Михаил Апахов <[email protected] <mailto:[email protected]> >; Владислав Пичугин <[email protected] <mailto:[email protected]> > Subject: Re: RE: RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e Добрый день, Александр! Интерес, конечно, есть! Я завёлся на масштабный проект по Рефалу, а одной моей головы на всё не хватает. Приходится исследовать и чужой опыт. Относительно языка реализации рекомендую ознакомиться с golang - он очень напоминает С, не требует переучиваться с нуля и гораздо легче в разработке, для меня по крайней мере. И очень неплохо интегрирован в современные технологии. Мой личный интерес тут - использование различных диалектов внутри одного серверного продукта, которым занимаюсь последнее время. Это бы повысило его качество, я думаю, и конкурентоспособность. Я очень заинтересован в возможности интеграции с другими разработчиками. И у меня в основе - golang.
