Почему интерпретатор медленный?

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

okay :(

Циклы [...] Интерпретатор транслирует на каждой итерации

Да ну.

Кстати, ты же близко знаком с Forth? В треде забыли упомянуть про шитый код (threaded code).

В википедии пишут «However, a program small enough to fit fully in a computer processor's cache may run faster than a larger program that suffers many cache misses»

То есть не все так однозначно

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

То есть, получается, что, если не будет динамической типизации, разницы в скорости вообще не будет?

Посмотри на интерпретацию forth.

То есть, получается, что, если не будет динамической типизации, разницы в скорости вообще не будет?

Посмотри на интерпретацию forth

Можем наоборот, сделай JIT-компилятор для C++ (не байткода LLVM, а именно текста на C++). Сравним скорость. :-) Особенно на программе, использующей boost.

А почему бы не спросить почему все так медленно работает - ведь электроны бегают очень быстро? Ведь в конечном итоге всю работу производят именно они!

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

Но ведь C++ не нужен! Если нужен пруфлинк, то смотреть куда-нибудь в сторону C++FQA.

Google: tccboot.

какие полупроводники? пн-переходы же!

Отличный вброс!

что это за основная особливость команд?
особливость

хзхз, это ты такими терминами оперирируешь

Да ты и русским то толком не владеешь

На фиолога или лингвиста не претендую

А вообще, про «основную особенность» тоже было бы интересно услышать. Жги!

чем компилятор от интерпретатора отличается

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

Да ну.

Ну да.

Кстати, ты же близко знаком с Forth?

А он при чём? В нём режимы компиляция/интерпретация прямо переключаются и циклы (и условия) в режиме интерпретации по стандарту вообще не работают.

То есть не все так однозначно

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

приборы полупроводниковые в виду имелись. как ты украдешь pn-переход, то есть технологию?

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

Так ведь как раз технологии и тырят. Нафиг мне прибор? Он сломается и что я буду делать например? А технология - это штука порядка повыше.

Машкод исполняется. Интерпретатор, грубо говоря, компилирует в машкод и исполняет. При каждом запуске программы. Да, есть JIT, но это не панацея. Так понятнее?

Интерпретатор, грубо говоря, компилирует в машкод и исполняет.

На колу мочало...

Ну блин, если человек не понимает, пока не начинаешь жевать совсем уж сопли...

Ведь если даже у нас интерпретация, expression2, сначала компилируется

иди в школу

Интерпретатор, грубо говоря, компилирует в машкод

Это не так.

Ведь если даже у нас интерпретация, expression2, сначала компилируется,

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

dispatch

Я уж думал это слово никто так и не произнесет, уйдет школоло зотролленым.

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

Большинство интерпретируемых ЯП - динамически типизированы, что тоже вносит немалый вклад в тормоза.

Я это знаю, ты это знаешь. А вот ТС не понимает. Пусть лучше будет так...

А куда он компилирует?

Вы с ним знаете? О_о

a = b;

mov &a, *b;

vs

push &ptr_a push *val_b call some_func_to_mov

Тупорылый страйфорвард жит всегда сливает интерпретатору, кроме случаев, когда тот сам на питоне

Racket доказывает обратное. Ни одного интерпретатора Scheme быстрее Racket (который на JIT) нету.

Ничего он не компилирует. Он уже скомпилирован. И просто перебирает функции, а выражения преобразует (как калькулятор). Поэтому и тупит так. Скажем, в сях напишешь sin(x*x+y*y), gcc единожды это преобразует в вычисление скобок и вызов библиотечной функции синуса, и все будет радостно и весело работать. А интерпретатор каждый раз, натыкаясь на эту строчку, будет не сразу же запускать нужный код, а сначала выполнять анализ внутрискобочного выражения, вычислять его, затем анализировать функцию, вызывать библиотечную sin и т.п. И, понятное дело, если у тебя gcc может кое-что соптимизировать, то в интерпретаторе фиг какой оптимизации!

Тупорылый страйфорвард жит всегда сливает интерпретатору, кроме случаев, когда тот сам на питоне

Racket доказывает обратное

На динамически типизированном языке тупорылый JIT точно не обгонит интерпретатор - накладные расходы собственно интерпретации невелики. Так что... в Racket достаточно умный JIT.

Ты про оптимизацию говоришь. Это тут не при чем