О байт-коде

Портируемость.

Excelsior JET и забудем об этом, ок?

Потому что их компилируют в байт-код.

Грамотно (без грязных хаков) написанная программа, не использующая либы, гвоздями прибитые к какой-то одной ОС, сравнительно без проблем компилируется под любую архитектуру.

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

есть шансы на более широкое внедрение llvm - что куда ближе в нативности.

Видать потому что это более сложно и не всем под силу.

для этого есть llvm

Если ты такой умный, то почему ты задаешь вопрос вместо того, что бы погуглить?

внятного ответа в гугле не нашлось

К слову, для сисярпа компиляция в нативный код тоже есть емнип.

Компилируют. man JIT compilation.

компилируют в нативные команды? Быстрее же будет.

Вот тут противоречие.

Что? Хочешь сказать, интерпретация выходит быстрее работы нативного когда?

Грамотно (без грязных хаков) написанная программа

и много ты знаешь примеров таких программ?

Ну я например так пишу.

Да, конечно. В огромном числе случаев интерпретация кода ест меньше ресурсов чем его компиляция + выполнение.

Ну приведи пример, мне так просто как-то не верится.

интерпретация кода ест меньше ресурсов чем его компиляция + выполнение.

компиляция делается 1 раз

потому что это сложная задача

Архитектур много, а байткод один.

+1 Так и надо писать. Хотя не всегда возможно, т.к. если можно грязным хаком «выбить» 2х быстродействие, то имхо это оправдано часто

Быстрее же будет

что именно будет быстрее?

Код, который требует частого изменения. Там собственно всякие скриптоязыки и правят бал.

компиляция делается 1 раз

И? А потом, когда будет подправлен код — ещё раз.

Почему языки, компилируемые в байткод, не компилируют в нативные команды?

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

Архитектур много, а байткод один.

Не всегда. У стандартной реализации Lua, например, байткод платформенно-зависим (у LuaJIT нет такого недостатка)

интерпретация выходит быстрее работы нативного кода?

так быть не может, но интерпретация иногда может быть быстрее, чем JIT

А если внезапно понадобится eval или хотя бы интроспекция?

что именно будет быстрее?

работать быстрее

И? А потом, когда будет подправлен код — ещё раз.

Не по 10 же раз на день перекомпилируешь уже отлаженную программу?

компиляция делается 1 раз

а если программа будет запущена один раз? ;)

работать быстрее

что будет работать быстрее? JIT компилирует байткод в нативные коды непосредственно во время запуска, единственное на что он таким образом влияет - скорость подъёма рантайма. ну так и сколько-нибудь серьёзное приложение на C или C++ потянет за собой неплохой рантайм

вопрос аналитегам: а есть какие нибудь альтернативы байт-коду с подобной же переносимостью? и являются ли подобной альтернативой скриптовые ЯП ?

JIT компилирует байткод в нативные коды непосредственно во время запуска

Я где то предлагал JIT?

Байткод — гораздо более высокоуровневая штука, чем код процессора.

Я где то предлагал JIT?

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

Да хоть там 10 раз JIT, если я скомпилирую зараннее 1 раз и буду запускать потом полученный бинарник, работать он будет быстрее, чем если байткод будет обрабатываться интерпретатором.

покажи мне современный язык, компилируемый в байткод, и при этом без JIT

Python. Думаю, что Ruby и Perl.

в какой-нибудь из реализаций

Реализации с JIT никем не используются.

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

если

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

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

В чём разница — потратить N тактов на интерпретирование M единиц байткода или скомпилировать эти же M единиц в те же самые N тактов?

В том, что в первом случае не N, а больше.

Для приближенных к железу языков вроде С оно верно. С питоном уже такой фокус не проходит.

Почему языки, компилируемые в байткод, не компилируют в нативные команды?

Простота реализаци

Быстрее же будет.

Очень, очень сомнительно. В байт-код обычно компилируются динамически типизированные языки (да, Ява - исключение). Для таких языков «тупой» перевод в машинный код не дает выигрыша, а «умный» перевод стал практически применимым только сегодня (да, спасибо галерке за напоминание о Strongtalk).

если байткод будет обрабатываться интерпретатором

ты, кажется, вообще не представляешь себе что такое JIT

если я скомпилирую зараннее 1 раз и буду запускать потом полученный бинарник

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

Реализации с JIT никем не используются.

а зря :(

Портабельность. И он таки часто компилируется в нативный - man JIT.

А программа, распространяемая в байт-коде, не требует для этого перекомпиляции :)

На то есть веские причины. PyPy не поддерживает Си-расширения CPython, Perl5 с JIT просто не существует, Ruby... он просто не нужен %)