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

Я первый спросил.

Ну ладно вам, ради бога

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

Да, читать ходил конечно, освежить знания никогда не вредно. Но забалтывать точно не буду.

Давайте методом от обратного - если AOT позволяет C# быть наравне с нативно компилируемыми языками, тогда зачем нужна виртуальная машина .net? На всякий случай - ВМ в .Net и ВМ в LLVM - это совершенно разные ВМ.

тогда зачем нужна виртуальная машина .net?

я уже 15 раз сказал, что её там нет, точнее она не обязательна и даже по-умолчанию не используется

Да, читать ходил конечно, освежить знания никогда не вредно. Давайте методом от обратного - если AOT позволяет C# быть наравне с нативно компилируемыми языками

Вы так на мой вопрос и не ответили. Так всё-таки, что такое АОТ?

я уже 15 раз сказал, что её там нет, точнее она не обязательна и даже по-умолчанию не используется

Ну как же ее нет-то? Если все вокруг нее построено?

Вы так на мой вопрос и не ответили. Так всё-таки, что такое АОТ?

Да это обычная компиляция в нативном языке. Придумали для языков на основе ВМ, т.е. с байт-кодом, чтобы попытаться догнать нативные языки. Термин ввели отдельный, потому что уже была JIT компиляция. JIT компиляция выполняется во время выполнения, отсюда «in time», а AOT выполняется до запуска программы, отсюда «ahead of time».

Book revision:2021-02-2

Да ещё и весьма свежая. Ну тогда может всё и нормально, в этом плане.

Совершенно верно. Но куцый рантайм просто означает куцую стандартную библиотеку, >это значит, что то, что у ПО других языков лежит в рантайме, у С++ и у D лежит в >велосипедах. И каждый из этих велосипедов при одновременном использовании жрёт >память, в то время как у других языков переиспользуется рантайм.

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

а зачем тогда нужен CLI затем же, для чего промежуточный язык llvm, CLI - полный аналог

конечно, нет. ключевое здесь: «управляемость кода» Неужели все об этом забыли?!

На сайте D есть ссылка на бесплатную книгу, которая должна должна быть достаточно актуальной:

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

НО готовые решения сделаны на Питоне

Ошибка номер три: готовые решения сделаны на C/C++, на питоне их предпочитают не >писать, а только использовать.

Да ладно. Что, мало полностью нативного питоновского кода? Не всё сводится к числодробилкам.

Они вообще ничего не понимают в технологиях программирования, им скорми что >угодно — они схавают. Просто, сейчас кормят питоном — вот они и жрут питон. Потому >тезис

Они и не должны. Но инструмент либо удобен, либо нет. Тот же Матлаб сильно совершеннее Юпитера, но специалисты часто предпочитают для сравнимых задач Юпитер, просто из удобства.

некорректен, потому что у ЦА нет мнения.

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

а на чём ещё его можно было реализовывать на/для персоналках/ок в начале 90-ых?

Да хотя бы CMUCL/CLisp. Это было бы еще и весьма просто, потому что CL с питоном >очень близки.

Ой, ёёё. Реализовывать интерпретатор на интерпретаторе…

Ну, в бытность мою школьником и студентом, в году этак 1983 – 90, нас учили Паскалю в дисплейном классе ЕС7960 (? не помню…) Замечательная штука. Терминал представлял собой моноблок, внутри которого жил 8-и разрядный 580ВМ80 (это не отменяло стойку с канальным процессором или чем-то наподобие, точно не знаю, на весь класс). Эх, нажатием кнопки можно было внезапно переслать экран ничего не подозревающему приятелю, ностальгия… Так вот, транслятор Паскаля жил внутри терминала, будучи написан на Форте. И транслировал паскаль в шитый код Форта. И выполнял внутри форт – системы. Памяти на пару экранов текста вполне хватало… И даже скорость была приемлима… только вот с настоящим, тогда компилирующим даже не в двоичный, а в пи-код, Паскалем, лучше бы не сравнивать.

К чему это я ? С ужасом представляю Питон, написанный на Лиспе и выполняющийся внутри лисп – машины.

компилятор ldc (ldc2) можно заставить выдавать результат в llvm

«заставить» нельзя.

Можно.

Все компиляторы с кучей фронтендов всегда компилируют через промежуточный язык.

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

ldc2 –help | grep -i llvm OVERVIEW: LDC - the LLVM D compiler –flto-binary= - Set the linker LTO plugin library file (e.g. LLVMgold.so (Unixes) or libLTO.dylib (Darwin)) –fprofile-generate= - Generate instrumented code to collect a runtime profile into default.profraw (overriden by ‘=’ or LLVM_PROFILE_FILE env var) –fprofile-instr-generate= - Generate instrumented code to collect a runtime profile into default.profraw (overriden by ‘=’ or LLVM_PROFILE_FILE env var) –fsave-optimization-record= - Generate a YAML optimization record file of optimizations performed by LLVM

–output-bc - Write LLVM bitcode –output-ll - Write LLVM IR

«Не читайте перед обедом советских газет»

Да ладно.

Runtimes typically just-in-time compile CIL instructions into native code.

CLI-compatible execution environments also come with the option to do an Ahead-of-time >compilation (AOT)

При чём тут это?! Всё затевалось для выполнения программы в «управляемой среде». Это значит, что в любой точке исполнения управляющая среда может приостановить исполнение и сделать с выполняемым кодом всё, что угодно. От JIT компиляции очередной порции, до…

А это и означает, что программа, по сути, интерпретируется (даже, если выполняется очередная скомпилированная в машинный код) или, если угодно, немного погрешив против строгости, но для простоты можно сказать, что запускается внутри некоторой виртуальной машины.

Да ладно. Что, мало полностью нативного питоновского кода? Не всё сводится к числодробилкам

Да, мало родного питоньего кода. К числодробилкам это не имеет отношения, потому что это даже какие-нибудь collections. Ну и, естественно, всё машинное обучение написано на C/C++. Дай сообществу волю — оно всю стандартную библиотеку под чистую на Си перепишет. И хз потом как это поддерживать.

Тот же Матлаб сильно совершеннее Юпитера, но специалисты часто предпочитают для сравнимых задач Юпитер, просто из удобства.

$1000 за годовую лицензию матлаба не хотел? Юпитер в корыто бесплатно кидают — вот его и жрут.

Специалист в статистике может быть слабым или вообще никаким программистом и не интересоваться последними веяниями в э… лямбдастроении. Но удобство инструмента оценить способен. Удобство здесь и сейчас, а не абстрактную идеальность

Каким образом он это сделает? В идеале ему нужно решить одну задачу в двух инструментах, а потом сравнить, насколько это было быстро и удобно. Но даже в таких раскладах может оказаться, что удобно в одном из инструментов было только потому, что по нему было больше ответов на stackoverflow — но другим инструментом на самом деле можно пользоваться намного продуктивнее, если потратить время на его освоение.

Реализовывать интерпретатор на интерпретаторе

Wronk. Ты не поверишь, но у CMUCL был компилятор в машинный код, который назывался Python. Собственно, Common Lisp прошел долгий путь развития, прошел через стадию интерпретации в рантайме, и потому имел вполне четкое разделение на время разработки и время выполнения, позволяющую эффективно генерировать машинные коды для выполнения. В отличие от CPython, который повторил все ошибки с нуля.

А это и означает, что программа, по сути, интерпретируется (даже, если выполняется очередная скомпилированная в машинный код) или, если угодно, немного погрешив против строгости, но для простоты можно сказать, что запускается внутри некоторой виртуальной машины

На самом деле нет никакой серьезной разницы между интерпретацией и выполнением машинного кода. Намного большую разницу дает природа этого машинного кода и этого интерпретируемого байткода. Например, JVM в начале своего «развития» (до HotSpot) по производительности была сравнима с каким-нибудь современным JavaScript без JIT-оптимизации. Собственно, с появлением JIT-компиляции в JVM и V8 оба языка снова стали подобными по производительности — при этом V8 умудряется даже выигрывать у JVM по потреблению памяти. Можно байткод JVM скомпилировать AOT в машинные коды — но работать быстрее прогармма от этого не станет. Потому разницу между интерпретатором и компилятором в данном контексте советую считать незначительной.

На самом деле нет никакой серьезной разницы между интерпретацией и выполнением машинного кода.

Если разницы нет, то зачем тогда два разных термина?

Можно байткод JVM скомпилировать AOT в машинные коды — но работать быстрее прогармма от этого не станет.

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

Потому разницу между интерпретатором и компилятором в данном контексте советую считать незначительной.

Разница заметная, у каждого подхода свои плюсы и минусы, как всегда.

$1000 за годовую лицензию матлаба не хотел?

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

Пока я встречал небольшие различия в использовании символов, те что syms x, ну и проблемы с дополнительными пакетами для матлаба, для octave их, вроде как, нет.

P.S. Все это я говорю в том контексте, где нужен именно матлаб без simulink. Если нужен Simulink, то тут уже не выкрутится.

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

Время запуска уменьшится, производительность нет. Для всяких микросервисов придумали, которые мало времени работают, и часто перезапускаются. Для долгоработающих программ лучше JIT чем AOT…

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html

Время запуска уменьшится, производительность нет. Для всяких микросервисов придумали, которые мало времени работают, и часто перезапускаются. Для долгоработающих программ лучше JIT чем AOT…

Быстродействие зависит от огромного количества факторов, поэтому фактически каждый случай нужно рассматривать индивидуально. Где-то лучше один вариант, а где-то другой. Я просто против категоричного ответа в таких случаях - где-то JIT будет лучше за счет того, что будет компилировать код для конкретных случаев, а где-то AOT будет лучше, потому что все конкретные случаи охвачены еще во время компиляции. В общем, зависит от задачи.

иначе зачем все это придумали?

Вспомнил ещё одну причину. В маркете iOS запрещен JIT, так что для компиляции Xamarin под iOS нужен AOT, без вариантов…

В маркете iOS запрещен JIT, так что для компиляции Xamarin под iOS нужен AOT, без вариантов…

Ну я сомневаюсь, что именно это стало причиной появления AOT, это просто частный случай. JIT запрещен в целях безопасности или какие-то другие причины?

На самом деле нет никакой серьезной разницы между интерпретацией и выполнением машинного кода

Если разницы нет, то зачем тогда два разных термина?

Пардон, не уточнил, что «в плане производительности».

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

Время запуска с отключенной JIT-компиляцией у жавы тоже довольно шустрое. Просто, никто в этом режиме жаву не эксплуатирует, потому что слишком уж медленная она получается. В V8 и некоторых реализациях JVM (как то GraalVM) есть возможность сохранить соптимизированный образ для последующего запуска. И тогда получается, что компиляция у программы происходит после ее выполнения, а не до.

JIT запрещен в целях безопасности

Да. Только у собственных приложений разрешён. Так что в их браузере Javascript с JIT.

Можно

Нет, нельзя. Он всегда так работает, хотите вы этого, или нет.

можно попросить не сгенерировать исполняемый машинный код из промежуточного представления, что по умолчанию и происходит, а записать в выходной файл как раз промежуточный код, не выполняя шаг превращения его в машинный.

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

Всё затевалось для выполнения программы в «управляемой среде»

мало ли для чего оно затевалось, на выходе AOT компилятора нет управляемого кода, обычный машинный код, есть даже OS Singularity, написанная целиком на C#

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

как и программу на любом языке, например, С

и сделать с выполняемым кодом всё, что угодно.

нет, нельзя, особенно после AOT

ну что, что не обязательно? С# тащит стандартные либы в рантайм, потому рантайм у него и жирный

а если какой-то язык не тащит, то это плохо в большинстве случаев

Если все вокруг нее построено?

что именно вокруг неё построено? и почему оно не может быть построено без неё?

Да это обычная компиляция в нативном языке.

В точку. И как тогда понимать ваши слова: «CIL это как раз то, что поставляется в сборках, и при запуске должна запуститься ВМ или JIT/AOT компилятор, которые будут выполнять этот код/преобразуют его в машинный.»

Если АОТ-компилятор в принципе предполагает компиляцию в машинный код заранее? И как бы подразумевает отсутствие виртуальной машины?

есть даже OS Singularity, написанная целиком на C#

А википедия говорит другое:

Written in Assembly language, C, C++, C#, Sing#

Наиболее интересен тут Sing#:

Sing# is a superset of Spec#. Microsoft Research developed Spec#, and later extended it into Sing# in order to develop the Singularity operating system. Sing# augments the capabilities of Spec# with support for channels and low-level programming language constructs, which are necessary for implementing system software.

Чего ж до конца-то не процитировал: Sing# (an extended version of Spec#, itself an extension of C#) and runs in unprotected mode. During installation, Common Intermediate Language (CIL) opcodes are compiled into x86 opcodes using the Bartok compiler

Там обычные машинные коды. Написанные на C#, да.

Как по мне, это сути не меняет: совсем не похоже на «целиком на C#».

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

впрочем, проще сравнить по факту:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html

С# в среднем отстаёт от С++ gcc в среднем в 1,5 раза. На многих задачах разница процентов 10%. Т.е. вполне сопоставимая c D производительность.

Да ладно. Что, мало полностью нативного питоновского кода? Не всё сводится к числодробилкам

Да, мало родного питоньего кода.

OK. Ну вот на моей системе, /usr/lib /python2.7 330744K /python3 682934K

из них в python3 пакетов: 531,

при этом в /usr/lib64/python3.9/lib-dynload файлов: 75 и в /usr/lib64/python3/site-packages/… упоминается 70 пакетов

точно из rpm доставать, сколько со-шек каким питоновским пакетам принадлежит, лень, порядок величин и так понятен.

Так что, не надо преувеличивать.

$1000 за годовую лицензию матлаба не хотел? Юпитер в корыто бесплатно кидают — вот его и жрут.

Есть Октава, есть Сайлэб. Но, большинство из сообществ используют Юпитер, соответственно, стандарт де-факто.

что по нему было больше ответов на stackoverflow — но другим инструментом на самом деле

просто к слову. пользователи в научном сообществе не пользуются стэковерфлоу. во всяком случае, абсолютное большинство, даже и не в курсе.

Ты не поверишь, но у CMUCL был компилятор в машинный код, который назывался Python.

с учётом моего (да, чисто школярского) представления о лисп системе, как системы с расширяемым образом (словарём), в котором программы должны исполнять программы, которые пишут другие программы, поверю с некоторым трудом.

имел вполне четкое разделение на время разработки и время выполнения,

ой-ой. Питон, как интерактивная интерпретируемая система, НЕ ДОЛЖНА иметь отдельной обязательной стадии разработки. Иначе вся идея уходит в гудок.

На самом деле нет никакой серьезной разницы между интерпретацией и выполнением машинного кода.

Есть. Первое принципиально не может отдать процессор полностью коду, иначе будет невозможна интерпретация. Скорость и требования к ресурсам, это уже вторично. Может, оно и неплохо, при таком контроле над выполняемым кодом можно повысить безопасность (а можно и понизить :) ), изящно сделать асинхронность и доставку сигналов (в смысле модели Qt), но всегда ли это применимо к задачам?

P.S. Все это я говорю в том контексте, где нужен именно матлаб без simulink. Если нужен Simulink, то тут уже не выкрутится.

Scilab + XCos ?

Я бы обратил внимание на чудесный бенчмарк https://github.com/kostya/benchmarks

Кроме времени исполнения и затрат памяти, автор попытался ещё посмотреть затраченную энергию. К коду есть вопросы, но в первом приближении весьма занимательные цифры.

Можно Нет, нельзя. Он всегда так работает, хотите вы этого, или нет.

можно попросить не сгенерировать исполняемый машинный код из промежуточного представления, что по умолчанию и происходит, а записать в выходной файл как раз промежуточный код, не выполняя шаг превращения его в машинный.

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

Вы придираетесь на ровном месте. ОБычный запуск компилятора (с явным или неявным запуском линкера) приводит к получению исполняемого файла. Точка. Что происходит внутри, извините, юзера не волнует.

А вот знание, что указание соотв. опции позволяет заставить компилятор вместо объетных/исполняемых файлов, выдать байткод llvm или webassembly, волнует.

Всё затевалось для выполнения программы в «управляемой среде»

мало ли для чего оно затевалось, на выходе AOT компилятора нет управляемого кода, >обычный машинный код, есть даже OS Singularity, написанная целиком на C#

Вот здесь очень хотелось бы послушать человека, который действительно разбирался в потрохах .net/core. Навскидку утверждение кажется весьма сомнительным. Как минимум, реализация /async…/ в первом и втором случае должна быть принципиально различна. Вряд ли на такое дублирование функционала кто бы то ни было пошёл бы.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html

С# в среднем отстаёт от С++ gcc в среднем в 1,5 раза. На многих задачах разница >процентов 10%. Т.е. вполне сопоставимая c D производительность.

между тем даже на этих тестах видно

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

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

ну вот и ответ, не всё в мире оценивается чистой производительностью.

Про SciLab я слышал, но не пробывал (да и, если честно, пока с Simulink не приходилось работать), поэтому не могу оценить. В моей ситуации, я в первую очередь оцениваю совместимость с теми инструментами, которые я заменяю. То есть, смогу ли я сделать работу в SciLab+XCos и отправить ее преподавателю, который использует Simulink, как в ситуации с Octave/Matlab?

Я пользуюсь Octave потому что он хорошо совместим с тяжелым Matlab.

Вот можешь почитать: https://docs.microsoft.com/en-us/dotnet/core/deploying/ready-to-run

Я не разбираюсь в потрохах .net, но я могу проверить.

Создаётся один бинарник в 21 мегабайт. И он работает на Linux. Mono его не понимает.

Для Windows кстати создаётся бинарник и пара dll, но общий размер тоже ~20 мегабайт

https://imgur.com/a/oOARzLV

Если изменить self-contained с true на false

<SelfContained>false</SelfContained>

То тогда размер helloworld только 130 кб для Jit и 131 кб для ReadyToRun, но требуется установленный .NET

https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file#publish-a-single-file-app---sample-project-file

Ну вот на моей системе, /usr/lib /python2.7 330744K /python3 682934K
из них в python3 пакетов: 531,
при этом в /usr/lib64/python3.9/lib-dynload файлов: 75 и в /usr/lib64/python3/site-packages/… упоминается 70 пакетов

Я считал по сорцам стандартной библиотеки CPython — примерно пополам соотношение. При том, что многие сишные либы имеют дополнительные обертки на питоне.

Есть Октава, есть Сайлэб. Но, большинство из сообществ используют Юпитер, соответственно, стандарт де-факто

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

просто к слову. пользователи в научном сообществе не пользуются стэковерфлоу. во всяком случае, абсолютное большинство, даже и не в курсе

А, то есть, изучают программирование по книжками 15-летней давности. С чем я их и поздравляю.

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

Поищи лиспотреды или подожди новых — тут был пример с короткой функцией на лиспе, которая компилироваласьь SBCL в примерно то же, что сгенерировал бы компилятор Си для аналогичной программы. Хотя, там все-таки функция была довольно примитивной.

Питон, как интерактивная интерпретируемая система, НЕ ДОЛЖНА иметь отдельной обязательной стадии разработки. Иначе вся идея уходит в гудок

Ты подменяешь «нет никакой возможности реализовать» на «не должна иметь». Когда ты от тыкания наугад переходишь к пакетной обработке бигдаты по накатанной дороге, то тебе уже никакой интерактивности не нужно в обработке миллиардов сущностей. И вот тут-то питон отправляется в мусорник, потому что быстро выполняться он не умеет. В TensorFlow даже сделали систему чтения файлов с кэшем на C/C++, который через питон можно только конфигурировать, но вся работа происходит через чистый C/C++ — только для того, чтобы полностью исключить питон из цепи обработки данных. Эта вся проблема бы не существовала, если бы у питона существовало понятие «время выполнения программы».

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

Может. Виртуальные машины делают предварительную трансляцию команд, отдают процессор на растерзание сгенерированным командам, которые потом гарантировано возвращают управление обратно в интерпретатор. Граница между компиляторами и интерпретаторами уже давно стерта.

Я бы обратил внимание на чудесный бенчмарк https://github.com/kostya/benchmarks

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

что именно вокруг неё построено? и почему оно не может быть построено без неё?

Вся парадигма (парадигма виртуальной машины), вокруг которой построен C# в корне отличается от нативных языков. Поэтому С# не может быть таким же как нативный язык, потому что он изначально построен отличным от них способом. В этом и суть появления С#. Наличие виртуальной машины позволяет решать задачи на другом уровне. Естественно за это нужно платить. Ряд фич C# обусловлены использованием ВМ.

Если АОТ-компилятор в принципе предполагает компиляцию в машинный код заранее? И как бы подразумевает отсутствие виртуальной машины?

Компиляция в машинный код не является гарантией чего либо. ВМ запросто может быть скомпилирована в машинный код и запущена в составе вашего приложения. Нужно смотреть на сам код. Ряд вещей, эффективно решаемых с помощью ВМ не очень хорошо решаются в случае нативных языков и обратно. Именно поэтому вы не можете взять язык на базе ВМ и скомпилировав его получить результат аналогичный использованию нативного языка и наоборот. В принципе этого не может быть - если говорить в общем, в каких-то частных случая это возможно. Просто потому, что если вы выкините ВМ из C# это уже будет не С# и если добавить ВМ в приложение с++ - оно тоже получить все достоинства и недостатки языка с ВМ.

С# в среднем отстаёт от С++ gcc в среднем в 1,5 раза. На многих задачах разница процентов 10%. Т.е. вполне сопоставимая c D производительность.

А, так вот оно что. А почему вы решили, что D среднем отстает от С++ в 1.5 раза? D не уступает С++, если брать ldc или gdc. На D вы можете выжать из ЦПУ все тоже что и на с++.