Parrot 1.4

>зато "стековость" делает её автоматически медленнее
Труды теоретиков это хорошо, но они писали это лет 30 назад.
А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые.

> Труды теоретиков это хорошо, но они писали это лет 30 назад.

Вообще-то как раз теоретики любят стековые машины. А про то, что для стековых труднее писать JIT, коворят практики уж лет 15.

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

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

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

>Труды теоретиков это хорошо, но они писали это лет 30 назад.

ну хорошо, а что за эти 30 лет изменилось в теории?

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

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

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

На то что быстрее или на то что стековые?

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

>На то что быстрее или на то что стековые?

:))) конечно имелась в виду скорость...

Ну, я заглядывал в книги Хартманиса и Мински, они достаточно долго нудно писали о преимуществах регистровых машин. Стэковые прошли мимо меня.

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

>>А на данный момент наиболее быстрые VM это Java и .Net - обе стэковые.
>пруфлинк, плиз
http://en.wikipedia.org/wiki/Comparison_of_application_virtual_machines

>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, участвующих в тесте.

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

точняк и 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

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

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

> А на данный момент наиболее быстрые 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.

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

ага..

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

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

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

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

В цитате говорилось про байткод. jit-компиляция, это компиляция из байткода (или скрипта) в native, при запуске программы (или скрипта).

у меня в 98 уже двухсотый mmx был :)