LINUX.ORG.RU

Parrot 1.4

 , ,


0

0

Вышла версия 1.4 платформы для динамических языков. Она включает в себя средства для создания и проверки грамматики языка PGE, средства для создания компилятора PCT, виртуальную машину PIR и библиотеки. Благодаря простоте разработки языков программирования, для платформы уже существуют реализации десятков языков программирования в том числе Python, Ruby, Lua, Sheme, Javascript, NQP (Not Quite Perl 6), Brainfuck. Также есть компиляторы из байткодов Java и .Net в PIR. Некоторые изменения:

  • добавлен экспериментальный «Infinite Memory» GC
  • усовершенствования в pbc_to_exe и Win64
  • книга о PIR сдана в печать
  • начата работа над библиотекой OpenGL::Math

Тем временем Rakudo (компилятор Perl 6) выходит на финишную прямую. Осталось около 200 тестов, которые нужно перевести на платформу Parrot (для сравнения, более 17000 уже перенесено и около 15000 проходят успешно).

>>> Parrot 1.4.0 "Mundo Cani" Released!

Ответ на: комментарий от ixrws

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от theos

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

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

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

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."

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

shty ★★★★★
()
Ответ на: комментарий от thevery

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

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

я не нашёл...

shty ★★★★★
()
Ответ на: комментарий от grim

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

bobrik
()
Ответ на: комментарий от Elverion

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

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

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

shty ★★★★★
()
Ответ на: комментарий от bobrik

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

>В них обеих ведь жыд-компиляция в 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 уже не катит

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

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

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

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

thevery ★★★★
()
Ответ на: комментарий от grim

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от shty

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

shty ★★★★★
()
Ответ на: комментарий от shty

> "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] обсуждение архитектуры физических машин; у виртуальных преимущества в доступе к "регистрам" нет - их "регистры" тоже будут в памяти.

ZV
()
Ответ на: комментарий от thevery

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

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

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

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

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

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от ZV

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от ZV

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от shty

>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_о
тесты и методика, кстати, свободно доступны - напишите быстрее...

thevery ★★★★
()
Ответ на: комментарий от thevery

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

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

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

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

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

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

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

один хрен.

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


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

r ★★★★★
()
Ответ на: комментарий от r

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

r ★★★★★
()
Ответ на: комментарий от shty

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

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

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


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

thevery ★★★★
()

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

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

yk4ever
()
Ответ на: комментарий от phasma

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

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

yk4ever
()
Ответ на: комментарий от tailgunner

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

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

yk4ever
()
Ответ на: комментарий от grim

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

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

yk4ever
()
Ответ на: комментарий от grim

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

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

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

Burbaka ★★
()
Ответ на: комментарий от thevery

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

eugene2k
()
Ответ на: комментарий от thevery

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Burbaka

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

shty ★★★★★
()
Ответ на: комментарий от Burbaka

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

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

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от Burbaka

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от shty

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от grim

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

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

shty ★★★★★
()
Ответ на: комментарий от grim

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

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от grim

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

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от shty

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

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

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

ZV
()
Ответ на: комментарий от ZV

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

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

shty ★★★★★
()
Ответ на: комментарий от grim

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

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

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

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

shty ★★★★★
()
Ответ на: комментарий от grim

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

grim ★★☆☆
() автор топика
Ответ на: комментарий от bobrik

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

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


ага..

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

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

mkfifo
()

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

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

MaratIK
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.