История изменений

Исправление uin, 20.02.20 19:22 (текущая версия) :

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

Когда не понимал как все работает представить было трудно, да. А теперь я немножко разбираться стал и представляю себе довольно ясно.

Твой код который ты напишешь скомпилируется в точно такую же (с логической точки зрения) последовательность комманд которые будут выполнять те же самые действия, код программы не меняется от исполнения, изменяются данные которые могут конечно приводить к ветвлениям, но ветвления это не какой то динамический код. Ну а данные для процессора вообще не существующая еденица, он что то из кэша подтянул в регистры положил, регистры сложил это что то обратно записал он знать не знает что там да и вообще есть ли там что то. Вот так это работает.

Что касается джаваскрипта в браузере, то все абсолютно тоже самое - скрипты так или иначе компилятся в статичные куски программного кода, потом могут перекомпилироваться получше что то выкидывать например, оптимизоваться для работы с одним типом данных итд итп. Это для эльбруса даже было бы лучше в каком то смысле еслиб не одно НО (даже два) - архитектура современных джитов и интерпритаторов динамических и vm языков сделана тупо в парадигме x86/risk. То есть там или макароны из байткода push int8 getVal setVal call push int32 которые можно конечно в ШК объеденять, но так, локально - что рядом стояло то и впихнул. Либо (как вот в джаваскрипте) получают AST и превращают его в неоптимизированный код в котором будет куча проверок на типы на то на се, и потом уже попроцедурно оптимизовать какие то часто вызываемые функции например. Для VLIW (и эльбруса в часности), после получения AST надо всю программу растеребить на графы и расфасовать по ШК. Потом уже так же после нескольких прогонов и получения профиля исполнения бинарий выкинуть перекомпилять код или какие то отдельные части/функции частоиспользуемые с агрессивными оптимизациями. Вот так вливу динамические языки зайдут хорошо, весь вопрос только в том кто это будет писать и потом поддерживать этот отдельный jit и стоит ли вообще заморачиваться с этим, если будет хватать простого портирования того что сейчас у всех работает, так как скриптовые языки не используются для чего то такого серьезного и требовательного.

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

Исходная версия uin, 20.02.20 19:22:

Для бенчмарков и разных тестов да. Там где на этапе компиляции это можно сделать и все оптимизировать. В реальных приложения как именно ты себе это представляешь? Когда не понимал как все работает представить было трудно, да. А теперь я немножко разбираться стал и представляю себе довольно ясно. Твой код который ты напишешь скомпилируется в точно такую же (с логической точки зрения) последовательность комманд которые будут выполнять те же самые действия, код программы не меняется от исполнения, изменяются данные которые могут конечно приводить к ветвлениям, но ветвления это не какой то динамический код. Ну а данные для процессора вообще не существующая еденица, он что то из кэша подтянул в регистры положил, регистры сложил это что то обратно записал он знать не знает что там да и вообще есть ли там что то. Вот так это работает.