LINUX.ORG.RU

Мини-версия рантайма для программирования микроконтроллеров на D

 ,


0

4

Dylan Graham представил LWDR. Это легковесный D-рантайм для программирования на D микроконтроллеров на базе ОС реального времени. Текущая версия нацелена на ARM Cortex-M.

Разработка не ставит целью полное покрытие всех возможностей D, но предоставляет базовые средства. Распределение памяти производится вручную (new / delete), мусорщик не реализован, но имеется ряд хуков для использования средств RTOS.

В этой версии поддержаны:

  • Выделение и разрушение экземпляров классов и кучи для структур * инварианты
  • ассерты
  • контракты, базовые средства RTTI (за счёт средств Typeinfo)
  • интерфейсы
  • виртуальные функции
  • абстрактные и статические классы
  • статические массивы
  • выделение, освобождение и изменение размера динамических массивов
  • добавление элементов в динамический массив и конкатенация динамических массивов,

В статусе экспериментальных возможностей:

  • Исключения и Throwables (так как требуют поддержку мусорщика)

Не реализованы:

  • Конструкторы и деструкторы модулей
  • ModuleInfo
  • локальные переменные потока (TLS)
  • делегаты и замыкания
  • ассоциативные массивы
  • разделяемые и синхронизированные данные,
  • хэшированые объекты

Проект на GitHub

>>> LWDR (Light Weight D Runtime) for Microcontrollers v0.2.3



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 6)
Ответ на: комментарий от yetanother

И что? Разница в 1,5 раза всё равно остаётся небольшой. Время программиста стоит существенно дороже, чем техника.

next_time ★★★★★
()
Ответ на: комментарий от glebiao

Вот здесь очень хотелось бы послушать человека, который действительно разбирался в потрохах .net/core.

Вот отсюда, можешь 2 минуты посмотреть. Это какие режимы есть в mono: https://youtu.be/D9gQoU3LkhM?t=2403

fsb4000 ★★★★★
()
Ответ на: комментарий от glebiao

минимум + 35М по памяти

это копейки. размер хеллоуворлда никого не волнует, вот если бы разница была бы хотя бы 500мб, дело другое

провалы на загрузке процессора, а ведь это явное указание на переключение с выполнения целевого кода, на некоторый служебный код

какой служебный код не требует загрузки процессора?

next_time ★★★★★
()
Ответ на: комментарий от next_time

Чушь. 32-битные микроконтроллеры имеют для своей работы от десятков килобайт до 2 мегабайт памяти. Здесь обсуждается не сам по себе язык D, а его использование для микроконтроллера.

Partisan ★★★★
()
Ответ на: комментарий от next_time

провалы на загрузке процессора, а ведь это явное указание на переключение с >>выполнения целевого кода, на некоторый служебный код

какой служебный код не требует загрузки процессора?

Я этого не говорил. Очевидно, что имеется служебный код, который периодически исполняется, вытесняя пользовательский. Что совершенно логично для интерпретатора. И периоды «паузы» достаточно значимы: иначе, их было-бы невозможно заметить на графике загрузке процессора.

Оно, может и неплохо. Но очевидно есть сценарии, где такое поведение неприемлемо.

glebiao
() автор топика
Ответ на: комментарий от byko3y

Граница между компиляторами и интерпретаторами уже давно стерта.

Эту мантру я слышу если не 30, то лет 20, как минимум.

Но чистые компиляторы продолжают разрабатываться. Внезапно.

glebiao
() автор топика
Ответ на: комментарий от byko3y

накатанной дороге, то тебе уже никакой интерактивности не нужно в обработке >миллиардов сущностей. И вот тут-то питон отправляется в мусорник, потому что быстро >выполняться он не умеет.

да, конечно. это случай, когда интерактивность может постоять в сторонке. Но кто мешает переписать отлаженную на Питоне программу на тех-же плюсах?

если бы у питона существовало понятие «время выполнения программы».

Ну вот смотри. Если соглашаемся на такое ограничение, из программы должны уйти, к примеру, eval. Значит, всё равно речь идёт о ограниченном подмножестве языка.

glebiao
() автор топика
Ответ на: комментарий от next_time

И что? Разница в 1,5 раза всё равно остаётся небольшой. Время программиста стоит >существенно дороже, чем техника.

Да, в том-то и дело. На D писать проще, чем на C# и тем более, C++ (при условии, что есть необходимые библиотеки, конечно). Вот и время и его стоимость :)

glebiao
() автор топика
Ответ на: комментарий от glebiao

Но чистые компиляторы продолжают разрабатываться. Внезапно

Кем? И как отлаживают программы на «чистых компиляторах»?

byko3y ★★★★
()
Ответ на: комментарий от glebiao

Но кто мешает переписать отлаженную на Питоне программу на тех-же плюсах?

Кто мешает писать программу сразу на плюсах, минуя Питон? Там далеко не один-в-один трансляция, это в любом раскладе переписывания почти с нуля.

если бы у питона существовало понятие «время выполнения программы»

Ну вот смотри. Если соглашаемся на такое ограничение, из программы должны уйти, к примеру, eval. Значит, всё равно речь идёт о ограниченном подмножестве языка

https://docs.python.org/3/library/audit_events.html

Это штатные инструменты CPython для того, чтобы бить про рукам за exec, eval, загрузку динамических библиотек, обращение к GC, и просто к целой куче системных функций, вроде выполнение внешней команды, изменения файлов, выполнения сетевого подключения, и так далее.

byko3y ★★★★
()
Ответ на: комментарий от glebiao

На D писать проще, чем на C# и тем более, C++ (при условии, что есть необходимые библиотеки, конечно)

Смелое заявление по поводу C# vs D. На чем оно основано? Ты в курсе, насколько C# продвинулся за последние годы. позаимствовав у того же F#?

byko3y ★★★★
()
Ответ на: комментарий от next_time

Время программиста стоит существенно дороже, чем техника.

Умиляет, что эта фраза все еще популярна. Равно как и дегроидные фразочки про «байтое@ство».

В целом он так, но ващет, если ты не заметил, мы все уже давно дружно вкатились в ровный флэт, когда то тут, то там вылезают противоположные примеры.

Но самый сок - это подождать еще пару лет и, с не меньшим умилением, читать визги сегодняшних «гуру» о том, что они все такие опытные, да только их недосягаемые компетенции нахер никому не сдались :)

Может @dk__ позвать да еще на одну бутылку забиться по этому поводу?)

Oberstserj ★★
()
Ответ на: комментарий от Oberstserj

Во-первых, флэта нет, есть ежегодный рост производительности минимум процентов на 20%.

Во-вторых, пару лет я уже подождал - как купил себе макбук 7 лет назад, так до сих пор смузи-программисты загрузить его по полной не могут.

Но с работы меня что-то не выгоняют.

next_time ★★★★★
()
Ответ на: комментарий от glebiao

Какие ваши доказательства? И не вы ли только что заявляли, что у С# есть виртуальная машина, которая якобы даёт невероятные преимущества?

next_time ★★★★★
()
Ответ на: комментарий от glebiao

Внезапно, т.к. используют вместе с JIT компиляторами один и тот же код. Берём clang, компилим C++ в промежуточный язык, а на целевой машине из него в машинный код - вот вам JIT-компилятор. Берём С++, компилим тем же самым clang-ом сразу в машинный код - вот вам AOT-компилятор. Одно и тоже)

next_time ★★★★★
()
Ответ на: комментарий от byko3y

Граница между компиляторами и интерпретаторами уже давно стерта.

Скорее стоит говорить о том, что интерпретаторы умерли. JIT компиляторы - это тоже компиляторы. Т.е. сейчас все языки компилируются. Кроме баша и MS cmd.

next_time ★★★★★
()
Ответ на: комментарий от glebiao

Очевидно, что имеется служебный код, который периодически исполняется, вытесняя пользовательский.

Ну так этот код будет также есть ресурсы процессора. И на графике ничего особо не поменяется.

Что совершенно логично для интерпретатора.

Нет, конечно. Интерпретатор берёт кусок текста и на лету интерпретирует его в машинный код, затем следующий кусок… Загрузка будет более-менее постоянной

next_time ★★★★★
()
Ответ на: комментарий от Oberstserj

В целом он так, но ващет, если ты не заметил, мы все уже давно дружно вкатились в ровный флэт, когда то тут, то там вылезают противоположные примеры

Вкатились потому, что костыли, которыми подпирают недостаток инструментов для экономии времени разработчика, сжирают настолько много ресурсов железа, что перекос становится недопустимым и приходится все-таки тратить время разработчика на оптимизацию времени выполнения. Питон или какой-нибудь React.js являются типовыми примерами противоположных крайностей, которые уже обросли слоями костылей сишных модулей, TensorFlow и PyPy, а другое обросло V8, React Native, и WebComponents.

byko3y ★★★★
()
Ответ на: комментарий от next_time

Во-первых, флэта нет, есть ежегодный рост производительности минимум процентов на 20%

Меньше. Тупик современной индустрии заключается в отсутствии роста производительности однопоточной обработки, а также неспособность менйстрим индустрии родить инструменты для разработки многопоточных решений, и это одна из причин, почему машинное обучение применяется где попало — потому что это очень простой способ приложив минимум усилий использовать максимум аппаратных ресурсов и сделать что-то похожее на рабочее решение.

Чел, которому ты отвечаешь, вроде как пишет то же, что и я, но не показывает того же понимания альтернатив развития, какое есть у меня, но пытается кидать какие-то понты про «посмотрим, кого оценят». Востребованность в индустрии слабо коррелирует с способностями программиста, потому что по крайней мере в западной экономике востребованы погонщики и впариватели, а трудяги «как-нибудь сами найдутся».

Эта парадоксальная, на первый взгляд, ситуация, становится более очевидной, если вспомнить другие аналогичные феномены из прошлого, например, луддитов. Или советский союз, где на самом высоком уровне пытались придумать решение той же проблемы. которую луддиты решали погромами. То есть, оптимизируя производство, мы приходим к ухудшению социально-экономической ситуации, потому что товары становятся дешевле, труда для их создания нужно меньше, и люди становятся не нужны, как и избыточные товары. Я совсем не удивлюсь, если окажется, что есть какое-то секретное агенство где-то у банкиров-промышленников, которое занято не только технологическим шпионажем, не только поиском новых перспективных технологий, но и помогают конкурентам и общей публике идти по тупиковому неэффективному пути. Пути, гарантирующему спрос на железо, чтобы новые видеокарты от AMD/NVidia и новые процессоры покупали всё больше и больше, чтобы вместо одного грамотного программиста с удобным инструментам средний коммерс в вакууме кормил десяток посредственных программистов, и еще столько же людей на поддержку и тестирование.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от next_time

Скорее стоит говорить о том, что интерпретаторы умерли. JIT компиляторы - это тоже компиляторы. Т.е. сейчас все языки компилируются. Кроме баша и MS cmd

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

byko3y ★★★★
()
Ответ на: комментарий от next_time

Разве современные райзены не превосходят раза в 2 в производительности core i7 5-летней давности?

https://www.cpubenchmark.net/singleThread.html

Смотришь на i9-7900X (2017) — 2600 сусликов.

Смотришь на i9-11900KF (2021) — 3600 сусликов.

(3600/2600)^1/4 = 8% роста в год.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от next_time

это i9. что там насчёт райзена и старых i7?

Да там плюс минус то же самое, только 3500 и 2500 соответственно.

byko3y ★★★★
()
Ответ на: комментарий от X512

сделать-то все можно, вопрос целесообразности и желания, пока желающих не нашлось

EugeneBas ★★
()
Ответ на: комментарий от glebiao

ну компактнее да, о чем я собственно и говорил, что улучшайзинг присутствует, его отрицать глупо, но вот прям революции я не вижу

EugeneBas ★★
()
Ответ на: комментарий от yetanother

есть подозрения, что тут уже нарушается принцип «zero cost abstraction», который является одним из основополагающих в С++, так что тут уже начинаются различия в философии языков

EugeneBas ★★
()
Ответ на: комментарий от next_time

И что? Разница в 1,5 раза всё равно остаётся небольшой. Время программиста стоит существенно дороже, чем техника.

Серьезно? Разница в 50% небольшая?

yetanother ★★
()
Ответ на: комментарий от EugeneBas

есть подозрения, что тут уже нарушается принцип «zero cost abstraction», который является одним из основополагающих в С++, так что тут уже начинаются различия в философии языков

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

З.Ы. Правда здесь есть ловушка, как и в том же С++ - слишком много шаблонного кода может раздуть бинарь и просадить производительность. В общем как всегда, все должно быть в меру.

yetanother ★★
()
Ответ на: комментарий от next_time

Вы готовы заплатить за приложение не 500$, а 700$, только потому, что оно считает в 1,5 раза быстрее?

Вы путаете мягкое и теплое. Если для вас устраивает быстродействие за 50К, то вы не будете платить больше, но если оно вас не устраивает, то вы будете платить и 100К и 1М. И будете выбирать язык. И будете железо подбирать вплоть до ASIC. И разница в 50% она очень большая.

yetanother ★★
()
Ответ на: комментарий от next_time

То есть, не готовы. ЧТД

Вы подменяете понятия. Это называется софистика. Во многих ситуациях быстродействия C# достаточно для решения задач. Но есть ситуации где этого недостаточно. И D однозначно быстрее чем C#. 50% разницы это очень много.

yetanother ★★
()
Ответ на: комментарий от yetanother
  1. 50% разницы - это в попугаях. На реальных задачах она быстро сдуется.

  2. если вы используете любую ОС, кроме Генту или FreeBSD, то отдаёте до 100% и более разницы в производительности попугаев просто так. В среднем, отдаёте процентов 20% попугаев.

  3. Во многих ситуациях быстродействия C# достаточно для решения задач. - Во всех. Именно для решения задач, этого достаточно.

  4. Разница даже в 50%, которой не будет - это разница 40 фпс вы получите или 60, минуту будет считаться задача или полторы, 6 часов или 9 часов: В общем, разница ни о чём.

next_time ★★★★★
()
Ответ на: комментарий от next_time

если вы используете любую ОС, кроме Генту или FreeBSD, то отдаёте до 100% и более разницы в производительности попугаев просто так. В среднем, отдаёте процентов 20% попугаев.

Звучит как враньё Гентушника.

Сравни -O3 и -O3 -march=native

https://imgur.com/a/gDeyvty

https://www.phoronix.com/scan.php?page=article&item=clang-12-opt&num=1

fsb4000 ★★★★★
()
Ответ на: комментарий от yetanother

А, да, даже если у вас генту или фрибсд, всё равно это не гарантия от потери попугаев. Так как помимо сборки из исходнков с -aarch флагом компилеру там есть ещё варианты:

  1. Взять бинарные пакеты с браузером, опен офисом и т.п. Т.е., отказаться от оптимизации самого жирного софта. А то собирается долго, лол.

  2. Криво собрать из исходников.

next_time ★★★★★
()
Ответ на: комментарий от fsb4000

Сравни -O3 и -O3 -march=native

А зачем, когда надо сравнивать -03 и -0fast -march=native -flto ? Или какие-то дистрибутивы собирают с флагом -0fast ? Тут реально могу ошибаться, но ЕМНИП, они обычно с -03 собирают.

Ну ок, сравним -0fast и -0fast -march=native -flto

Получилось аж более 6%. Это может быть и много. Надо смотреть, насколько этот тест «попугайный».

У вас там «geometric mean of all». All чего? Каких тестов?

next_time ★★★★★
()
Ответ на: комментарий от fsb4000

Не враньё, а фанатство. Он видимо сам верит в свой бред. Надо же ему как-то обосновать свой выбор .

Врочем, дискуссия лишена смысла. C# не годится для микроконтроллеров, так как работает в виртуализованной среде. D ограниченно годится но не нужен. Так же, как и упомянутый C++. Который в принципе годится, но практически не применяется для микроконтроллеров. Значит, не нужен.

Partisan ★★★★
()
Ответ на: комментарий от fsb4000

Ок, нашёл. Вот например, флак енкодинг: 27% разница в производительности. Botan decrypt - примерно 20% разница. HMMER search - почти 100% разница. ЧТД.

next_time ★★★★★
()
Ответ на: комментарий от Partisan

Ещё один оголтелый подъехал. https://habr.com/en/post/549012/

Может работать на 32- и 64-разрядных микроконтроллерах ARM, с наличием всего 256 КБ флэш-памяти и 64 КБ ОЗУ.
Работает нативно на чипе, в настоящее время поддерживаются устройства ARM Cortex-M и ESP32.

Ещё, в 150 раз повторяю: у C# НЕТ ВИРТУАЛКИ. Начитаются идиотов, а потом разносят свой бред.

next_time ★★★★★
()
Ответ на: комментарий от next_time

50% разницы - это в попугаях. На реальных задачах она быстро сдуется.

если вы используете любую ОС, кроме Генту или FreeBSD, то отдаёте до 100% и более разницы в производительности попугаев просто так. В среднем, отдаёте процентов 20% попугаев.

Во многих ситуациях быстродействия C# достаточно для решения задач. - Во всех. Именно для решения задач, этого достаточно.

Разница даже в 50%, которой не будет - это разница 40 фпс вы получите или 60, минуту будет считаться задача или полторы, 6 часов или 9 часов: В общем, разница ни о чём.

Я, честно говоря, затрудняюсь это комментировать. Очень толсто. 6 часов vs 9 часов - это разница ни о чём?

yetanother ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.