> Сами что-то придумали, сам опровергли – молодца! )Тут было явно более одного анонима и думали они по разному, однако.
> А может быть, вы определитесь – нельзя компилировать или все же генерировать
> "эффективный машинный код"?
От "компиляции" в байткод нету толка - избавляет от неэффективного парсинга строк, но байткод все-равно интерпретируется. В результате выполняемых CPU большинство команд - код интерпретатора. Служебная сущность, вообще не формирует логику программы.
> такое, причем тут интерпретация и каким боком все это относится к "машинному").
Важно вот что: логика программы либо представляется в виде машинных команд, которые напрямую выполняются на CPU, не разбавленные побочными вещами - тогда быстро. Либо это не происходит, со всеми вытекающими.
> А то очень смахивает на попытку объяснить попадание пятой точки в лужу
> желанием принять грязевую ванну. )
Я и не сомневался что у тебя жгло пониже спины, вот и принимаешь грязевые ваны. За километр видно питониста, выгораживающего фетиш.
> http://www.intel.com/content/www/us/en/architecture-and-tech.../
Читать на интеле про процессоры вообще - несколько однобоко. Так что попытка понта не удалась, иди охлаждай пятую точку в воде уже.
> ну, с поправкой на архитектуру. А то боюсь, что с помощью википедии
> вы много не нагенеруете.
Википедия даст общую идею. А конкретику реализации - это уже у производителя разумеется.
> А, классический Отвечатель
Ну ты то вообще классический бугуртовщик, да еще и гонщик к тому же. Пытаешься сосватать байткод как эквивалент машинного кода. Ага, щазззз, дубаков нет.
> Угу, "сторожей" приставляют, чтобы отлавливать все новые типы, присылаемые из
> параллельной вселенной. А так все верно, да!
Тюринг доказал что одна программа (в нашем случае компилятор) не может проанализировать другую программу (в нашем случае то что програмер нагенерил) и вынести определенный вердикт (в нашем случае - о том изменится ли тип). С какими-то оговорками и ограничениями наверное можно попробовать проскочить, но это глюкоопасно, т.к. программер может делать все что угодно в пределах возможностей языка. И предусмотреть вообще все обычно невозможно. Поэтому jit обычно явно проверяет - не меняется ли тип. Это разбавляет код программы кучей проверок. А в машинном коде многие вещи могут быть и как логическая или арифметическая операция напрямую. Есть большая разница: сложить r1 и r2 в которых было 2 и 3 и получить 5 за 1 такт процессора, или потратить еще уйму тактов на проверки какие там типы у кого были и что должно получиться. Поэтому даже лучшие jit легко проигрывают нативному коду в 2.5-5 раз.
> Т.е. до кое-кого так и не дошло, что Just In Time компилятор
> таки все же компилятор? Н-да.
Обычно он компилятор только наполовину, с большими оговорками. Т.е. самые горячие куски перегоняются в машинный код, а остальное интерпретируется. К тому же jit не может тратить столько же ресурсов как компилятор на компиляцию. Одно дело если компилятор будет 2 минуты оптимизировать код в compile time, и совсем другое - если jit встрянет на 2 минуты в run time. И даже так - из-за динамичности производительность оказывается ниже и к тому же не постоянная. Ну то-есть про реальное время, даже самое лажовенькое, можно сразу забыть.
Нормальное ограничениьице: программа не может нормально взаимодействовать с реальным миром и процессами в нем, а так все хорошо. Ну в общем сойдет для лагучей вебни. И все.
> Хорошо наверное быть Отвечателем – взял и придумал себе что-то, а
> потом и ответил, позорно посрамив всех неведомых врагов! )
Да зачем вас срамить? Вы сами гораздо лучше справляетесь.
