Parrot 1.4

>И желательно, чтобы компилятор питона + паррот показывали лучшую производительность среди прочих реализаций питона.
Если они сделают 100% совместимый перл компилятор, то как минимум перловские библиотеки будут доступны в P6, и обратно, что должно помочь с популяризацией платформы.

>>зато "стековость" делает её автоматически медленнее

>Стековость её не делает ни-ка-кой. Стековая машина отлично транслирует в региструвую. Стековое выражение тривиально реверсинжинерится обратно в исходный код - с чего собственно становится медленнее, аналитик ты наш?

чёт Вы всё в кучу навалили, исполнение, трансляцию... вот, специально для Вас нашёл, читайте:

http://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf

и вот Вам цитаты из главы "STACK VERSUS REGISTERS":

>"The cost of executing a VM instruction in an interpreter consists of three components: Dispatching the instruction, Accessing the operands, Performing the computation"

>"Instruction dispatch involves fetching the next VM instruction from memory, and jumping to the corresponding segment of interpreter code that implements the VM instruction. A given task can often be expressed using fewer register machine instructions than stack ones. For example, the local variable assignment a = b + cmight be translated to stack JVM code as ILOAD c, ILOAD b, IADD, ISTORE a. In a virtual register machine, the same code would be a single instruction IADD a, b, c. Thus, virtual register machines have the potential to significantly reduce the number of instruction dispatches."

>"The second cost component of executing a VM instruction is accessing the operands. The location of the operands must appear explicitly in register code, whereas in stack code operands are found relative to the stack pointer. Thus, the average register instruction is longer than the corresponding stack instruction; register code is larger than stack code; and register code requires more memory fetches to execute. Small code size, and small number of memory fetches are the main reasons why stack architectures are so popular for VMs."

>"The final cost component of executing a VM instruction is performing the computation. Given that most VM instructions perform a simple computation, such as an add or load, this is usually the smallest part of the cost. The basic computation has to be performed, regardless of the format of the intermediate representation. However, eliminating invariant and common expressions is much easier on a register machine."

перевод нужен?

>shootout'а вам недостаточно?

там есть данные которые могут обосновать или опровергнуть следующее утверждение: "на данный момент наиболее быстрые VM это Java и .Net"?

я не нашёл...

>>>А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые.

>>пруфлинк, плиз

>http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines

к сожалению не нашёл по указанной ссылке сравнения быстродействия виртуальных машин, однако пройдя по следующей ссылке:

http://en.wikipedia.org/wiki/Stack_machine

нашёл такие фразы:

"Conventional references say[1] that stack machines are slow because the stacks are in memory, and therefore slower to access than registers."

"When stacks are in memory, a register machine runs about 26.5% faster than a stack machine[...]"

никак не вижу каким образом это может подтвердить фразу: "А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые"

В них обеих ведь жыд-компиляция в x86-код, а он регистровый.

> никак не вижу каким образом это может подтвердить фразу: "А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые"

хреново сделанное регистровое может быть медленнее хорошо сделанного стекового.

>В них обеих ведь жыд-компиляция в x86-код, а он регистровый.

меня что-то смущает надо погуглить... :)

тем не менее, бенчмарки-то где?

>>никак не вижу каким образом это может подтвердить фразу: "А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые"

>хреново сделанное регистровое может быть медленнее хорошо сделанного стекового.

может даже и не заработать... :) и тем не менее

>В них обеих ведь жыд-компиляция в x86-код, а он регистровый.

ну точно смущает:

http://www.interface.ru/fset.asp?Url=/microsoft/arx.htm

>"Когда файлы с исходными текстами готовы, вы запускаете компилятор и получаете EXE или DLL. Эти EXE или DLL файлы очень похожи на PE (Portable Executable – портируемые выполняемые) файлы, по сути дела они и есть PE файлы с некоторыми отличиями."

>"Первое отличие заключается в том, что код в управляемых PE файлах не является командами процессора x86 или другим машинным кодом. Вместо этого компилятор создает код на Промежуточном Языке Microsoft (Microsoft intermediate language - MSIL). PE файл, содержащий MSIL может выполняться на платформе любого процессора, если операционная система, предоставляет .NET CLR. "

так что для .net уже не катит

>"на данный момент наиболее быстрые VM это Java и .Net"?

берём, например, этот тест:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all&...

и видим, что java проиграла только некоторым плюсах (которые, очевидно, не являются VM), а, следовательно, выиграла у всех остальных VM, участвующих в тесте.

опровержения?

> как минимум перловские библиотеки будут доступны в P6, и обратно

Во-первых, вряд ли интероперабельность чего-нибудь нетривиального проверена; во-вторых, Питону не нужны перловые либы :) (обратное тоже верно); в-третьих, Питон сильно завязан на Си-расширения (хотя PyPy может отчасти помочь).

точняк и java стековая:

http://en.wikipedia.org/wiki/Java_Virtual_Machine

A Java Virtual Machine (JVM) is a set of computer software programs and data structures that use a virtual machine model for the execution of other computer programs and scripts. The model used by a JVM accepts a form of computer intermediate language commonly referred to as Java bytecode. This language conceptually represents the instruction set of a stack-oriented, capability architecture. As of 2006[update], there are an estimated four billion JVM-enabled devices worldwide.

> "Conventional references say[1] that stack machines are slow because the stacks are in memory, and therefore slower to access than registers."

> "When stacks are in memory, a register machine runs about 26.5% faster than a stack machine[...]"

> никак не вижу каким образом это может подтвердить фразу: "А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые"

равно как и опровергнуть. По ссылке [1] обсуждение архитектуры физических машин; у виртуальных преимущества в доступе к "регистрам" нет - их "регистры" тоже будут в памяти.

> если операционная система, предоставляет .NET CLR.

убивать, за такое, надо

>>"на данный момент наиболее быстрые VM это Java и .Net"?

>берём, например, этот тест:

>и видим, что java проиграла только некоторым плюсах (которые, очевидно, не являются VM), а, следовательно, выиграла у всех остальных VM, участвующих в тесте.

>опровержения?

да вроде нет, но (!)...

1) clr (.net) отсутствует (про mono речь не шла)

2) llvm (к примеру) отсутствует

т.е. репрезентативность выборки не очень большая

3) меня смущает, что c++ и java работают с одинаковой скоростью, кагбэ сильно смущает - есть мнение, что дело в том что тесты не очень корректно написаны

>По ссылке [1] обсуждение архитектуры физических машин;

по ссылке [2] тоже?

>у виртуальных преимущества в доступе к "регистрам" нет - их "регистры" тоже будут в памяти.

Вы не понимаете концепцию регистровых/стековых виртуальных машин, читайте ссылку [2].

> виртуальных преимущества в доступе к "регистрам" нет - их "регистры" тоже будут в памяти.

Это при тупой реализации интерпретатором. JIT сильно усложнит дело.

>1) clr (.net) отсутствует (про mono речь не шла)

о скорости clr ничего сказать и не могу. но она не принципиально отличается от java, насколько мне известно.

>2) llvm (к примеру) отсутствует
почему нет LLVM - не знаю. А чего потенциально быстрого ещё нет?

кстати о LLVM:
http://leonardo-m.livejournal.com/73732.html

GCC V. 4.2.1-dw2 (mingw32-2)
nbody, (c) n=10_000_000: 5.92 s

LLVM-gcc V. 2.4
nbody, (c) n=10_000_000: 16.63 s

Java 1.6.0_06
nbody.java, N=10_000_000: 5.48 s

и пара слов о Java (I was able to find the asm code produced by the JavaVM for the nbody benchmark. It essentially uses only the SSE registers, and no floating point stack. It contains three inlines calls to the sqrt (but the program contains only two of them). At a first look, that asm doesn't look much different frm the asm produced by LLVM-gcc (but LLVM-gcc doesn't inline the call to the sqrt).
I have seen that the last C++ version of the nbody (you can find it too inside the zip) compiled with LLVM-gcc is able to run in 4.98 s, but it uses lot of intrinsics like __builtin_ia32_haddpd(), that will not be the best for future CPUs (while the Java code is perfectly general), in practice it's partially asm already.)

>3) меня смущает, что c++ и java работают с одинаковой скоростью, кагбэ сильно смущает - есть мнение, что дело в том что тесты не очень корректно написаны

а что вас в этом удивляет? 0_о
тесты и методика, кстати, свободно доступны - напишите быстрее...

>почему нет LLVM - не знаю. А чего потенциально быстрого ещё нет?

вроде всё остальное есть...

>и пара слов о Java

таки доставляет... и объясняет :)

>>3) меня смущает, что c++ и java работают с одинаковой скоростью,

>а что вас в этом удивляет? 0_о

ну, в своё время был опыт (правда то было лет 10-12 назад), который оставил у меня определённые ощущения... видимо это мои тараканы :)

>тесты и методика, кстати, свободно доступны - напишите быстрее...

надо будет глянуть повнимательнее... позапускать

в итоге что получается, лучший llvm - это jvm?

>так что для .net уже не катит

О боже. Небось писал какой-то индус работающий в микрософт?

>1) clr (.net) отсутствует (про mono речь не шла)

один хрен.

>3) меня смущает, что c++ и java работают с одинаковой скоростью, кагбэ сильно смущает - есть мнение, что дело в том что тесты не очень корректно написаны

Гого - перепиши.

>>так что для .net уже не катит

>О боже. Небось писал какой-то индус работающий в микрософт?

гыгы... :) это да...

>в итоге что получается, лучший llvm - это jvm?

Скорость на числодробильнях - не единственное все.

>ну, в своё время был опыт (правда то было лет 10-12 назад), который оставил у меня определённые ощущения... видимо это мои тараканы :)

ну 10-12 лет назад Java действительно была сильно медленнее

>в итоге что получается, лучший llvm - это jvm?

JVM - как минимум одна из самых быстрых VM

> книга о PIR отравлена для публикации

Да! Отравлена. Точнее не скажешь.

> Я смотрю в будущее. Когда начнет загнивать .Net все же перейдут на JS

Аналитикам ЛОРа завезли траву нового урожая. Эхехей!

> Только вот Sun обанкротился, делая Яву быстрой :-P

Сан, как замечал ещё джоэль, попросту феерические балбесы.

> Эти языки в сумме востребованных вакансий в разы меньше Perl, не вспоминая Javascript.

Кобол-эффект. На перле есть кучи говнокода, которые надо поддерживать. На новых проектах он почти никому не нужен. Новая версия никому не нужна.

> А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые.

При использовании JIT разница между стековой и регистровой системой команд VM уходит на второй план. На первый выходит семантика самих команд и возможности оптимизации. Если есть JIT то впринципе пофигу регистровая машина или стековая.

Сравнивать LLVM и parrot неправильно. Первый гораздо более низкоуровневый. В него удобно компилировать статические языки типа Си и Паскаля. Parrot более наворечен и заточен под динамические языки. В нем есть поддержка полиморфизма аля Smalltalk на уровне системы команд, CPS, GC и много-много других вкусностей.

Есть предположение, что ни один тест не сможет дать объективную оценку тому что быстрее: регистровая или стековая ВМ. Единственное что можно точно утверждать - это что байткод для стековой ВМ будет больше чем байткод для регистровой ВМ. Еще можно точно сказать, что при прямой трансляции инструкций байткода регистровая ВМ будет быстрее. А вот при реализации через JIT, все может кардинально поменяться и уже не известно что будет быстрее.

>ну 10-12 лет назад Java действительно была сильно медленнее

Там всё веселее было. Мало того, что Java была «помедленнее» (эдак, на порядок, наверное, если не на два), так и компы тоже были не сильно быстрее нынешних! :D В 1997-м году P100 был ещё нормой и считался вполне быстрым процессором! :)

> Если есть JIT то впринципе пофигу регистровая машина или стековая.

Если не учитывать затраты на написание самого JIT.

>В 1997-м году P100 был ещё нормой и считался вполне быстрым процессором! :)

дык! у меня 486dx80 был :)

>>А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые.

>При использовании JIT разница между стековой и регистровой системой команд VM уходит на второй план. На первый выходит семантика самих команд и возможности оптимизации.

точняк! спасибо уважаемый, Вы довольно точно выразили то о чём я думал, но так и не смог сформулировать :)

>Сравнивать LLVM и parrot неправильно. Первый гораздо более низкоуровневый. В него удобно компилировать статические языки типа Си и Паскаля. Parrot более наворечен и заточен под динамические языки.

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

Появляется ощущение, что вот и приходит будущее. Внезапно. :)

>>ервое отличие заключается в том, что код в управляемых PE файлах не является командами процессора x86 или другим машинным кодом. Вместо этого компилятор создает код на Промежуточном Языке Microsoft (Microsoft intermediate language - MSIL).
>так что для .net уже не катит
Что вам не катит в MSIL/CLR?

>Что вам не катит в MSIL/CLR?

всё катит, кроме кроссплатформенности... а что?

>При использовании JIT разница между стековой и регистровой системой команд VM уходит на второй план.
В регистровй машине реализованной по 20 летней давности идеям должна быть указание на паралелизм, что позволит их распаралеливать на уровне ядер, что должно в свою очередь дать прирост на многоядерных системах.

>всё катит, кроме кроссплатформенности... а что?
a mono запустить религия не позволяет?
Я делаю проект он работает и под обеими платформами.

>a mono запустить религия не позволяет? Я делаю проект он работает и под обеими платформами.

позволяет... меня смутило microsoft intermediate language :)

и да, напомню о чём разговор был

>>В них обеих ведь жыд-компиляция в x86-код, а он регистровый.

>"Первое отличие заключается в том, что код в управляемых PE файлах не является командами процессора x86 или другим машинным кодом. Вместо этого компилятор создает код на Промежуточном Языке Microsoft (Microsoft intermediate language - MSIL). PE файл, содержащий MSIL может выполняться на платформе любого процессора, если операционная система, предоставляет .NET CLR. "

>так что для .net уже не катит

говорилось о том что при т.н. "жыд-компиляции" не генерируется x86 код

>>так что для .net уже не катит

>Что вам не катит в MSIL/CLR?

и раз уж такая пьянка пошла как .net незаметно трансмутировал в msil/clr?

при JIT как раз и генерирутся код целевого процессора и он уже исполняется.
При этом может компилировться не вся программа а только критические участки.

Это аналог PIR для Parrot.

> Вы не понимаете концепцию регистровых/стековых виртуальных машин, читайте ссылку [2].

Да как угодно; я скорее не понимаю Вашу систему аргументации, когда для для подтверждения некоторой мысли (возможно - верной) используется не имеющая отношения к теме цитата :(

Жалко только что python-на-parrot скорее мёртв чем жив. Кстати, CPython использует стековую виртуальную машину. И как мне показалось код генерирует совершенно бесхитростный. Что в общем-то и правильно - когда не знаешь что делает операция "+" - складывает целые числа, выводит что-то на экран или запускает ракету оптимизировать особо нечего.

>я скорее не понимаю Вашу систему аргументации, когда для для подтверждения некоторой мысли (возможно - верной) используется не имеющая отношения к теме цитата :(

не грустите ;) возможно эта ссылка попала туда случайно, т.к. документ не выложен я не имел чести с ним детально ознакомиться... так прокатит? :)

>при JIT как раз и генерирутся код целевого процессора и он уже исполняется.

мы говорим об одном и том же, или я чего то не понимаю? есть мнение что фраза "целевого процессора" является лишней

была ж цитата:

> "код в управляемых PE файлах не является командами процессора x86 или другим машинным кодом. Вместо этого компилятор создает код на Промежуточном Языке Microsoft"

>Это аналог PIR для Parrot.

а ну извините тогда, не уловил что мы в этом срезе говорили...

Всё правильно.
Java тоже компилирется в байткод который затем JVM по мере необходимости транслирует в код целевого процессора, например x86.

mono при этом умеет делать AOT(ahead of time) и сохранять, чтобы при следующем запуске не нужно было компилировать снова.

>> если операционная система, предоставляет .NET CLR.

> убивать, за такое, надо

ага..

..напоминает:

"Покупатель может выбрать автомобиль любого цвета при условии, что он будет черным"

> книга о PIR отравлена для публикации

Черт, я траванулся книгой о PIR.