Здравствуйте, vbn2007, Вы писали:

V>Здравствуйте, ArtDenis, Вы писали:

AD>>Здравствуйте, vbn2007, Вы писали:

V>>>Компилятор же хитрее: он сначала компилирует тестовую прогпрорамму команд в некий объектный код, а затем уже выполняет уже откомпилированный код
AD>>Э-э... С каких это пор компиляторы выполняют скомпилированный код?

V>А МОЙ — выполняет
V>Если всерьез — Вы правы, конечно же, ели строго.
V>Но я просто передаю управление на начало программы в буфере.
V>Как она завершается — уже не до компиляций

Насчет Основной темы ветки: ну конечно же мне стыдно (:
Еще бы не стыдно — стока многа дней и ночей!

Но перемелется — мука будет
Я думаю, что ОТВЫК ОЧЕНЬ, мотаясь по московским обменникам.

Здравствуйте, VladD2, Вы писали:

DM>>Тогда срочно нужно новое слово для Питона, Руби 1.9, Луа и кучи других. Ибо они сперва компилируют (в байткод), а потом выполняют.

VD>Не не нужно. Это интерпретатор чистой воды. То что интерпретируется не исходный код, а промежуточное представление ничего не меняет.

Там внутри довольно четкое разделение на компиляцию в байткод и исполнение его ВМ. Есть даже разделение — байткод можно сохранить в файл, а потом многократно исполнять.

VD>На будущее. Интерпретация — это исполнение программы другой программой, а не процессором (железякой).

Тогда Java — интерпретатор.

VD>Вот компиляцией можно назвать и преобразование текста в байткод.

Питон, Руби и Луа это делают.

VD>Но если говорят о интерпретирующих и компилирующих ЯП или средах, то под компилятором обычно понимают нечто транслирующее код в нэйти-код процессора.

Тогда Nemerle — не компилятор.

Здравствуйте, VladD2, Вы писали:

VD>Разница между компилятором и интерпретатором в том, что компилятор никогда не выполняет программу, а интерпретатор никогда ее не компилирует .

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

Здравствуйте, vdimas, Вы писали:

V>Вообще-то, в подавляющем большинстве случаев интерпретаторы компилируют программу в некое представление для своей виртуальной исполнительной машины.

Это без разницы. Главное, что они не формируют нечто что может исполняться без интерпретации. Интерпетатор байткода все равно интерпретатор.

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

Здравствуйте, D. Mon, Вы писали:

DM>Там внутри довольно четкое разделение на компиляцию в байткод и исполнение его ВМ. Есть даже разделение — байткод можно сохранить в файл, а потом многократно исполнять.

Это не имеет ровным счетом никакого значения. Это детали реализации интерпретатора. В наше время интерпретировать текст скриптов отваживаются редко.

VD>>На будущее. Интерпретация — это исполнение программы другой программой, а не процессором (железякой).

DM>Тогда Java — интерпретатор.

Ява имеет разные реализации. Есть чисто интерпретирующие VM, а есть VM поддерживающие JIT-компиляцию (т.е. компиляцию кода перед первом его исполнением). Более того JIT-ер от Sun-а может какие-то куски кода интерпретировать (если он посчитает, что они не критичны для производительности или они не выполняются более одного раза), а какие-то компилирует.
Дотнет, как не странно, тоже обладает разными VM. Основная, используемая на ПК, обладает JIT-компилятором который прекомпилирует весь код. Более того большая часть системных сборок прекомпилируется еще при инсталляции дотнета.

VD>>Вот компиляцией можно назвать и преобразование текста в байткод.

DM>Питон, Руби и Луа это делают.

Это делают 90% интерпретаторов.

VD>>Но если говорят о интерпретирующих и компилирующих ЯП или средах, то под компилятором обычно понимают нечто транслирующее код в нэйти-код процессора.

DM>Тогда Nemerle — не компилятор.

Правильно, так как Nemerle — это язык. Но вот его компилятор генерирует байткод, которые перед исполнением компилируется в машинный код с помощью JIT-компилятора дотнета (или прекомпилятора — ngen.exe). Так что в итоге Nemerle — это компилируемый язык. Именно по этому код написанный на нем по скорости мало отличается от кода написанного на С.

VD>Правильно, так как Nemerle — это язык. Но вот его компилятор генерирует байткод, которые перед исполнением компилируется в машинный код с помощью JIT-компилятора дотнета (или прекомпилятора — ngen.exe). Так что в итоге Nemerle — это компилируемый язык. Именно по этому код написанный на нем по скорости мало отличается от кода написанного на С.

Вот, за что я люблю лёгкие наркотики: куча свежих идей.

Здравствуйте, Temoto, Вы писали:

T>Вот, за что я люблю лёгкие наркотики: куча свежих идей.

Рад за тебя. Но какой интерес слушать о твоих приходах на этом форуме?

T>>Вот, за что я люблю лёгкие наркотики: куча свежих идей.

VD>Рад за тебя. Но какой интерес слушать о твоих приходах на этом форуме?

Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

Здравствуйте, Temoto, Вы писали:

T>Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

ОК. Один раз простил. В следующий раз пойдешь в баню на недельку.

T>>Это не мои, это у вас, не сочтите за грубость, суровый приход, коль скоро "по скорости Nemerle мало отличается от Си".

VD>ОК. Один раз простил. В следующий раз пойдешь в баню на недельку.

Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

Здравствуйте, Temoto, Вы писали:

T>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

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

Пойми, никто не хочет разговаривать с каким-то обдолбанным малолеткой.

Здравствуйте, Temoto, Вы писали:

T>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

Вот так действительно пристойно. Остается только определить значение понятия "существенно" и объяснить на чем основан этот скепсис.

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

T>>Хакей, более пристойный вариант: ваш тезис неверен, скорость существенно отличается.

VD>Вот так действительно пристойно. Остается только определить значение понятия "существенно" и объяснить на чем основан этот скепсис.
VD>Вот десятикратное отставание, которое обычно демонстрируют рантаймы скриптовых языков — это (на мой взгляд) существенное отставание. Отрыв в несколько процентов или даже в два раза в некоторых случаях — не существенное.

Действительно, понятие субъективное. А отрывы будут сильно зависеть от решаемой задачи. У вас внизу значок nemerle developer, может быть вам известны примеры кода, где он отстаёт от Си на несколько процентов — было бы очень интересно взглянуть. Честно, я не проводил бенчмарков, но учитывая причины скепсиса (ниже), мне кажется, что "в два раза" это самая-самая оптимистичная оценка.

Относительно требований продукта к производительности — согласен! и в десятки раз несущественно, поэтому скриптовые языки и пользуются такой бешеной популярностью. Безотносительно требований конкретных продуктов, просто так две цифры в бенчмарке: 200% это очень существенно. Я понимаю, что разница разумно обусловлена и полностью оправдана. Но это не делает её меньше.

Скепсис основан на боксинге и ветвлениях в runtime проверке типов. Ну, это если x + y (где x,y: uint32) компилируется в одну машинную инструкцию (без учёта того, что результат куда-то надо положить). А если нет, то ещё дополнительные расходы, ещё повод для скепсиса.

Здравствуйте, VladD2, Вы писали:

DM>>Тогда Java — интерпретатор.

VD>Ява имеет разные реализации. Есть чисто интерпретирующие VM, а есть VM поддерживающие JIT-компиляцию (т.е. компиляцию кода перед первом его исполнением). Более того JIT-ер от Sun-а может какие-то куски кода интерпретировать (если он посчитает, что они не критичны для производительности или они не выполняются более одного раза), а какие-то компилирует.

"Это не имеет ровным счетом никакого значения. Это детали реализации интерпретатора."
У Луа есть LuaJIT, если что.

В общем, мысль твоя ясна, просто формулировки не самые хорошие.

Здравствуйте, D. Mon, Вы писали:


DM>"Это не имеет ровным счетом никакого значения. Это детали реализации интерпретатора."
DM>У Луа есть LuaJIT, если что.

DM>В общем, мысль твоя ясна, просто формулировки не самые хорошие.

Как прикол если код на питоне содержит такую пару строчек:

import psyco

psyco.full()

то он волшебным образом из интерпретатора превращается в компилятор

Здравствуйте, VladD2, Вы писали:


V>>Вообще-то, в подавляющем большинстве случаев интерпретаторы компилируют программу в некое представление для своей виртуальной исполнительной машины.

VD>Это без разницы. Главное, что они не формируют нечто что может исполняться без интерпретации.

Вполне может, например на форт- или джава-процессорах. Да, сами подобные процессоры тоже являются интерпретаторами, впрочем, как и наиболее популярная на сегодня архитектура x86 — классика интепретирования, изначально работающая на микрокоде. Сейчас место микрокода занял автомат, выполняющий аналогичный ф-ии, но суть не поменялась — это интерпретатор чистой воды, который сначала переводит исходный код во внутреннее исполнение, и только потом подает его исполняющей (но уже не виртуальной) машине.


VD>Интерпетатор байткода все равно интерпретатор.

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

Да тут обсуждать-то нечего. Очевидно, что большинство современных интерпретаторов представляют из себя на самом деле пару: компилятор+интерпретатор некоей VM (напр. Лисп и Пролог). Хотя, изначальное твое утверждение предположительно верное, если интерпретаторы рассматривать именно как пару, но резко неверное (и здесь это заметил не только я) ввиду того, интерпретаторы рассматриваются как некий неделимый "черный ящик", где описанная пара — всего лишь подробность реализации.

ИМХО, четкую границу тут не проведешь. С одной стороны, хочется хочется уточнить твое первоначальное утверждение и сказать, что интерпретаторы код выполняют, а компиляторы — нет, но и это тоже неверно для некоторых языков, где код выполняется во время компиляции.

Здравствуйте, vdimas, Вы писали:

V>ИМХО, четкую границу тут не проведешь. С одной стороны, хочется хочется уточнить твое первоначальное утверждение и сказать, что интерпретаторы код выполняют, а компиляторы — нет, но и это тоже неверно для некоторых языков, где код выполняется во время компиляции.

Провести грань тут не могут только псевдо-философы.
На практике грань очевидна. Именно по этому автор темы хочет заменить иетерпретацию на динамическую компиляцию и выполнение скомпилированного кода.

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

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

И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

Здравствуйте, VladD2, Вы писали:

VD>Важно тут только то, что интерпретация программы всегда во много раз медленнее непосредственного исполненя на той же машине.

Форт со своим шитым кодом точно интерпретатор, но интерпретатор настолько простой (часто выливается в пару ассемблерных инструкций)
что на скорости по скорости практически сравним с компиляторами в нативный код.

VD>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

Здравствуйте, Temoto, Вы писали:

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

Скриптовые языки используются только там где вычислительная производительность не важна. Обычно как "клей". Так что задача в основном решается неким нэйтив-кодом (SQL-серверы, библиотеки написанные на нэйтив-языках), а скрипты только вызывают это дело и скрепляют отдельные компоненты между собой. Там где скрипты пытаются использовать для решения задач целиком или для решения вычислительных задач — это обычно заканчивается плачивно.

T> Безотносительно требований конкретных продуктов, просто так две цифры в бенчмарке: 200% это очень существенно.

В два раза — это на 100%, а не на 200. Причем разницу в два раза еще нужно постараться получить. Это или закой-то числодробильный код который резко выигрывает от ручных оптимизаций, или еще что-то, что в гражданском коде встретишь не часто.

T>Я понимаю, что разница разумно обусловлена и полностью оправдана. Но это не делает её меньше.

Двухкратную разницу порой вообще нельзя увидеть не вооруженным взглядом. А там где это критично всегда можно схимичить. Мне вот только еще не разу этим заниматься не пришлось.

Зато код написанный на типобезопасном ФЯ намного проще распараллелить. А это уже может поднять скорость в 4 и более раз (в зависимости от железа и задачи). Так что не все так просто.

T>Скепсис основан на боксинге и ветвлениях в runtime проверке типов. Ну, это если x + y (где x,y: uint32) компилируется в одну машинную инструкцию (без учёта того, что результат куда-то надо положить). А если нет, то ещё дополнительные расходы, ещё повод для скепсиса.

Скепсис основан на твоем не знании и отсутствии опыта.

Откровенно говоря у меня совсем нет желания агитировать за советскую власть. Я говорю о том с чем сам работаю. Я где-то 15 проработал с С/С++ и скоро будет 10 лет как с дотнетом.
Конечно при применеии дотнета есть тонкие вопросы и по неопытности можно получать весьма не эффективный код, но практика показывает, что если писать с умом, то скорость получается более чем приемлемая. Тот же боксинг в моем коде встречается крайне редко и только там где это совершенно не важно с точки зрения производительности (например, при консольном выводе, где скорость вывода на консоль в десятки раз ниже боксинга).

Вот сейчас я занимаюсь переделыванием Word-ового шаблона для верстки статей для RSDN. Раньше он был создан на базе automation-API ворда и нэтив COM-библиотек. Кода на VB6 было не очень много, так как основная работа "поручалась" компонентам написанным на С/С++ — MS XML, Regex-ы и API ворда (все нэйтив и написанное на С/С++). Тормозил старый шаблон просто чудовищно, не смотря на использования в основном нэйти-кода! Даже небольшие статьи обрабатывались десятками секунд. А большие минутами (и это на весьма современном железе).
Новый шаблон работает посредственно с фалом в формате Word XML 2003. Он парсит его с помощью менеджед-библиотеки System.Xml.Linq и обрабатывает (в основном в функциональном стиле). Далее он генерирует ХМЛ в формате RSDN ML и с помощью прекомпилированного в управляемый код XSLT генерирует HTML со статьей (для предварительного просмотра). Так вот даже на документы весьма большого размера обрабатываются в мгновение ОК.

Это рассказ конечно не доказывает, что нэйтив-код медленнее управляемого. Но хорошо демонстрирует, что скорость у управляемых решений очень высокая и в купе с гибкостью которую дает Nemerle и дотнетные библиотеки — это позволяет решать мгогие задачи намного эффективнее чем если бы для этого использовать нэйтив-код. Более того иной раз объем работы настолько велик, что решение задачи на С/С++ становится просто мало реальным, а на дотнете очень даже реальным. Не даром Майрософт переписывает свой компилятор C# на C# с С++ и переписывает все больше частей VS на C#.

Здравствуйте, FR, Вы писали:

FR>Форт со своим шитым кодом точно интерпретатор, но интерпретатор настолько простой (часто выливается в пару ассемблерных инструкций)
FR>что на скорости по скорости практически сравним с компиляторами в нативный код.

Позволю себе усомниться. Чудес все же не бывает.

VD>>И когда кто-то говорит об интерпретаторе, то подразумевает, что рантайм языка не генерирует машинный код ни на какой стадии.

FR>Форт не генерирует. Но добавив небольшой модуль начинает это делать. Питон тоже.

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

То что для питона такой есть — это полнешая чушь. Я так понимаю ты имеешь в виду PyPy. Назвать его "модулем" можно с огромной натяжкой. Это отдельный компилятор. И он несомненно ускоряет код Питона (пусть даже и не всегда). Вот только беда в том, что Питон клинически плохо компилируется в виду своей динамической семантики. Так что эффект от его прекомпиляции не очень значительный. Причем чем более продвинутые возможности используются в программе, тем меньше толку будет от ее компиляции.

Другое дело Nemerle с его выводом типов. Для него сделать эффективный компилятор намного проще. Накладные расходы на GC конечно тоже будет, но они ни в какое сравнение не идут с тем какие накладные расходы получаются в Питоне.

ЗЫ

Тема холивара "Скрипы быстры как ветер" меня не трогает. Развивать я ее не намерен.