Добрый вечер, Александр!

«Бьёрн Страутструп упорно доказывал, что эффективность ++ не ниже, а иногда и 
выше, чем С на то время.»

Знаем эти басни. Эффективность достигается объёмом кода и временем компиляции. 
Функция 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 <refal@botik.ru> 
Sent: Tuesday, May 18, 2021 11:56 PM
To: Александр Коновалов <a.v.konovalo...@mail.ru>; refal <refal@botik.ru>
Subject: Re: RE: RE: RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 

Александр,

 

Конечно я признаю С очень ясным с точки зрения оптимизации и компактности кода. 
Опыт был около 10 лет программирования на нём весьма нагруженных систем.

 

Относительно С++ могу сказать, что его автор, Бьёрн Страутструп упорно 
доказывал, что эффективность ++ не ниже, а иногда и выше, чем С на то время. 
Беда в современных шаблонах и библиотеках. К слову, мне на этом языке не 
удалось сделать чего-нибудь значимого.

 

Недостатком С мне видится не вполне ясная его портируемость. Если для установки 
его для микроконтроллера или АТС можно и повозиться, то для менее тиражируемых 
проектов это может оказаться лишней тратой сил, особенно если нужно подключать 
различные специфические библиотеки. Или я не знаю текущего положения дел с 
языком.

 

Насчёт golang: автоматизация работы с памятью касается прежде всего 
полбъектного malloc , для цепочек никто не мешает организовать выделение 
большими блоками и оптимизировать самому. Зато разработчики обещают полную 
совместимость кода на целом ряде платформ. Без «танцев с бубном».

 

При выборе базового языка я рассматривал также node.js. Который нынче тоже 
весьма шустрый и компилируемый. Для меня главным свойством при выборе была 
возможность лёгкого подключения к проекту всех современных технологий, даже ещё 
не существующих.

 

Производительность же современных серверных платформ весьма высока, что в 
большинстве случаев позволяет снизить критичность оптимизации и скорости 
выполнения задач. Но это моё мнение на данный момент.

 



Отправлено из мобильной Почты Mail.ru



вторник, 18 мая 2021 г., 17:53 +0300 от Александр Коновалов 
<a.v.konovalo...@mail.ru <mailto:a.v.konovalo...@mail.ru> >:

Александр!

Цель перевода рантайма на Си — переход на более низкоуровневый язык. Не смотря 
на то, что на C++ можно писать также, как и на Си, всё-таки стиль 
программирования на обоих языках различается. На C++ проще вводить новые 
абстракции: классы с методами, шаблоны, у C++ есть богатая библиотека шаблонов 
и т.д. И из-за этого код пишется с избыточным числом абстракций, более 
высокоуровневый и, возможно, более медленный. А использование стандартных 
библиотечных контейнеров ещё и замедляет компиляцию. Бедность выразительных 
возможностей Си (по сравнению с C++, конечно) приводит к тому, что код 
получается более плотным и более низкоуровневым. Когда пишешь, больше думаешь 
об эффективности и экономии ресурсов.

Ну, вот такие у меня ощущения и такое восприятие Си и C++. И исходя из этих 
ощущений, думаю, что Си лучше подходит как язык реализации рантайма языка.

С Golang’ом я знаком и считаю его слишком высокоуровневым для написания 
рантайма. Для каждой конструкции языка Си можно догадаться, в какой машинный 
код она откомпилируется, для Golang’а это не всегда верно (на мой взгляд). К 
тому же в Golang’е есть сборка мусора, а тут мне хочется управлять памятью 
самому. У Си рантайм очень тонкий. У Golang’а рантайм наоборот толстый.

 

С уважением,
Александр Коновалов

 

From: Александр Гусев <gusev_aleksa...@mail.ru <mailto:gusev_aleksa...@mail.ru> 
> 
Sent: Tuesday, May 18, 2021 3:28 PM
To: Александр Коновалов <a.v.konovalo...@mail.ru 
<mailto:a.v.konovalo...@mail.ru> >
Cc: Andrei Klimov <and...@klimov.net <mailto:and...@klimov.net> >; Arkady 
Klimov <arkady.kli...@gmail.com <mailto:arkady.kli...@gmail.com> >; Yuri Klimov 
<y...@klimov.net <mailto:y...@klimov.net> >; Antonina Nepeivoda 
<a_ne...@mail.ru <mailto:a_ne...@mail.ru> >; Igor Adamovich 
<i.a.adamov...@gmail.com <mailto:i.a.adamov...@gmail.com> >; Sergei Romanenko 
<sergei.romane...@gmail.com <mailto:sergei.romane...@gmail.com> >; Boyko 
Bantchev <boyk...@gmail.com <mailto:boyk...@gmail.com> >; Михаил Апахов 
<m_apak...@mail.ru <mailto:m_apak...@mail.ru> >; Владислав Пичугин 
<vlad19041...@yandex.ru <mailto:vlad19041...@yandex.ru> >
Subject: Re: RE: RE: Рефал-семинар 17 мая 2021 в 10:30 в Zoom'e

 

Добрый день, Александр!

 

Интерес, конечно, есть! Я завёлся на масштабный проект по Рефалу, а одной моей 
головы на всё не хватает. Приходится исследовать и чужой опыт.

 

Относительно языка реализации рекомендую ознакомиться с golang - он очень 
напоминает С, не требует переучиваться с нуля и гораздо легче в разработке, для 
меня по крайней мере. 

И очень неплохо интегрирован в современные технологии.

Мой личный интерес тут - использование различных диалектов внутри одного 
серверного продукта, которым занимаюсь последнее время. Это бы повысило его 
качество, я думаю, и конкурентоспособность. Я очень заинтересован в возможности 
интеграции с другими разработчиками. И у меня в основе - golang.

Ответить