LINUX.ORG.RU

Проведен анализ результатов тестов производительности языков

 , , ,


0

0

Некий Guillaume Marceau написал статью, в которой предложен интересный метод классификации языков: идеальный (быстрый и краткий), системный (быстрый и многословный), скриптовый (медленный и краткий), устаревший (медленный и многословный). В соответствии с этим методом проведена классификация языков на материале shootout.alioth.debian.org , и рассмотрены некоторые другие вопросы -- например, влияет ли наличие функциональных черт в языке на скорость.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Re: Проведен анализ результатов тестов производительности языков

stalin еще жив?

Dimanc ★★ ()

Re: Прведен анализ результатов тестов производительности языков

> и почему bash на тесты не таскают

Говорят, результаты по времени очень воспроизводимо равны времени для перла, умноженному на 18.

question4 ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> occam, cmucl, regina и stalin

Я даже полез в вики искать.. Сталина не нашел((

f3ex ★★ ()

Re: Проведен анализ результатов тестов производительности языков

Это такой супер-пупер-оптимизирующий транслятор схемы в Си. С блекджеком и шлюхами. Довольно древний проект, прозябающий на задворках цивилизации.

gns ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Ruby -- мусор, а Lua лучше чем Python, причём Luajit вообще почти идеальный вариант для скриптов и ядер ОС. Я давно это подозревал! Но где Neko и HaXe?

vasdi ()

Re: Прведен анализ результатов тестов производительности языков

>ну, на OpenNews дали более адекватное описание, а комментариев меньше.

Для Ъ:

Guillaume Marceau опубликовал наглядный обзор параметров 72 реализаций языков программирования, использовав для этого 19 специальных тестов, подготовленных проектом "The Computer Language Benchmarks Game", в рамках которого производится ежедневный анализ изменения параметров 1368 приложений из состава Debian, после их пересборки или выполнения различными версиями компиляторов и интерпретаторов. Оцениваются такие параметры, как скорость выполнения, потребление памяти и размер исходного кода, необходимый для реализации определенных функций.

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

Karapuz ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Ну вот, шаман поправил текст новости в соответсвии с моим предложением (спасибо) и теперь можно пофлеймить! (а то до этого у меня кроме <неразборчиво> слов других не было).

www_linux_org_ru ★★★★★ ()

Re: Прведен анализ результатов тестов производительности языков

>и почему bash на тесты не таскают, все им пользуются и не тюкают его

А вообще стоило бы его потестить. И в тесты добавить специфично-башевские примеры... Он вполне может пройти в номинации "скриптовый язык", а может и слить.

www_linux_org_ru ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

До конца никто не читал?

"The code to generate these charts runs in PLT Scheme (MzScheme) v4.1.5. You will need the data file from The Game's cvs repository. This file is from 2005, which is the one I used for the charts above. Update: I rerun the generation using the 2009 data. Here are the updated big chart and colored chart."
http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-depandability-200...
http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-depandability-par...

На диаграммах от 2009 неплохо выглядят haskell и ocaml, а вот sbcl улетел в самый верх. Но всё это ничего по-большому счету не значит.

tymmym ()

Re: Проведен анализ результатов тестов производительности языков

И какой победил? Китайский или английский?

Vanuan ()

Re: Проведен анализ результатов тестов производительности языков

Питон же, разве ты не вкурсе? Человек спрашивает что ему выбрать, PHP|Perl, http://www.linux.org.ru/view-message.jsp?msgid=3748832 ему отвечают Python. Общепризнанно, самый лучший язык

Karapuz ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Ну вот. Из этого http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-depandability-par... нетрудно видеть, что C#.mono по всему хуже жабы, и многословнее, и тормознее в работе. Интересно, C#.NET тоже тормознее под Windows?

Karapuz ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

>>Может, всё-таки корректно говорить "компиляторов языков программирования"?

А есть какая-то разница? Как бы ни хотелось, но успех языка программирования во-многом определяется его реализацией. Язык может быть как угодно хорош теоретически, но с практически кривым компилятором/интерпретатором толку от такого языка 0.

deadman ★★ ()

Re: Проведен анализ результатов тестов производительности языков

>Интересно, C#.NET тоже тормознее под Windows?

2 my mind не может он быть тормознее жабы т.к гранулярность контроля в сишарпе повыше что дает больше свободы в оптимизации узких мест, кроме того под виндой он наверняка висит на гораздо толстом слое нативного кода чем это можно себе позволить в JVM.

Absurd ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Таки Питон быстрее Пела. Не ожидал. Думал Питон тормоз.

DNA_Seq ★★☆☆☆ ()

Re: Проведен анализ результатов тестов производительности языков

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

Ну да , 2 слива пистония перлу и одна победа - весьма недурно для "развивающегося непрестанно" средства ... над шустрым перловым трупиком :))

elipse ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Я по shootout.alioth.debian.org смотрел. Неплохо оказывается Пайтон с текстами работает, весьма неплохо.

DNA_Seq ★★☆☆☆ ()

Re: Проведен анализ результатов тестов производительности языков

Скажем здесь http://shootout.alioth.debian.org/u32q/benchmark.php?test=regexdna&lang=all по затраченному процессорному времени даже чуть-чуть обгоняет Си, вот только из-за отсутствия многопоточности проигрывает в четыре раза по чистому времени

DNA_Seq ★★☆☆☆ ()

Re: Проведен анализ результатов тестов производительности языков

а tcl убрали из сравнения:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&...

ну ,чтоб не так горько было "передовым технологиям" :))

elipse ★★★ ()

Re: Прведен анализ результатов тестов производительности языков

> Не привязывайтесь к Шаману. На нем держится 51% привлекательности ЛОРа.

у него-таки контрольный пакет акций лора?)

по сабжу: lua и haskell порадовали...

n01r ★★ ()

Re: Проведен анализ результатов тестов производительности языков

надо будет сделать язык lenin ато stalin есть ну или brezgnev

mio ★★ ()

Re: Проведен анализ результатов тестов производительности языков

Ха-ха-ха-ха...

ХА. ХА. ХА!!!!!!

Всегда знал что Ruby - слив!
JavaScript - и так янсно, что это скрипт...

Но вот Java/javaxx - WTF? Судя по графикам, о тормозах речи не идёт ВООБЩЕ! Что за нафиг!?

xawari ()

Re: Проведен анализ результатов тестов производительности языков

Что такое Java я мала-мала знаю. И что такое "Java client" я тоже знаю. А что это за язычок такой "Javaclient"? И чем от отличается от Java?

Жду очередную порцию бредовых статей от "теоретиков-пиписькомеров".

Bioreactor ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> Интересно, C#.NET тоже тормознее под Windows?

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

"Хорошесть" языка - это его лаконичность, элегантность и сопровождаемость.
По сути, никто из вас ведь не пишет свой ethernet-драйвер! Вы пользуетесь БИБЛИОТЕКОЙ, а вот в ней уже всё можно написать на Си, оптимизируя до такта. И вот с высоты языка, пользуясь быстрыми библиотеками, тот программист продуктивнее, чей язык позволяет более красиво решить задачу.

matumba ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

>а tcl убрали из сравнения:
>http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&...

>ну ,чтоб не так горько было "передовым технологиям" :))


А чего обидного? Один только тест, где Tcl вдвое быстрее. В среднем же у Питона 3-4 кратное преимущество. А если с Psyco ( http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&... ) то в среднем Питон уже в 10 раз быстрее.

KRoN73 ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> В среднем же у Питона 3-4 кратное преимущество.
если , именно "в среднем" - тогда будет 2.45.
Но , ассемблер тоже быстрее питона ,да ? :))
Гениальная простота Tcl не меряется этими корявыми тестами :))

elipse ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

>Но вот Java/javaxx - WTF? Судя по графикам, о тормозах речи не идёт ВООБЩЕ! Что за нафиг!?

Ты только прозрел? На ЛОРе все уже знают, что java не тормозит. Последний остался ты

Karapuz ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

>если , именно "в среднем" - тогда будет 2.45.

Ну, я на глазок оценивал.

>Но , ассемблер тоже быстрее питона ,да ? :))


Я бы сказал, что по вероятности зевнуть ошибку (а именно этот момент определяет скорость написания) Tcl гораздо ближе к ассемблеру, чем Питон :)

Питон - очень строгий язык (для своего класса). Tcl - очень гибкий. На гибких языках же сложно писать что-то большое. Высока вероятность пропустить незамеченную ошибку.

KRoN73 ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> Tcl гораздо ближе к ассемблеру, чем Питон :)
Во глупости какие :)) ну просто жуть :))
и чего только тут не прочитаешь .... офигеть можно
ps: кстати bash не муляет ?


elipse ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> Сокращение от "java -client" надо думать

"The default VM is client." (c) Sun + Капитан Очевидность хором.

Bioreactor ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков

>Во глупости какие :))

Ты ещё скажи, что Tcl менее гибок и более строг, чем Python.

KRoN73 ★★★★★ ()

Re: Проведен анализ результатов тестов производительности языков


> Ты ещё скажи, что Tcl менее гибок и более строг, чем Python.

Tcl достаточно гибок и человекоудобен.
"Отмывать" и подводить идеологию под неудобства питония - смысл ?
Искать сакральный и нрaвоучительный смысл в тесной обуви ? :))

elipse ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

Python самый быстрый ? - нет
Python самый удобный ? - тоже нет
Значит, надо вправить мозги людям и доказать обратное :)))

elipse ★★★ ()

Re: Проведен анализ результатов тестов производительности языков

> "The default VM is client." (c) Sun + Капитан Очевидность хором.
Извини, не знал. В SUN'ом man'e действительно так написано. На, например, цитирую OpenJDK:
Standard Options
-client
Select the Java HotSpot Client VM. A 64-bit capable jdk currently ignores this option and instead uses the Java Hotspot Server VM.
For default VM selection, see Server-Class Machine Detection

-server
Select the Java HotSpot Server VM. On a 64-bit capable jdk only the Java Hotspot Server VM is supported so the -server option is implicit.
For default VM selection, see Server-Class Machine Detection

Ещё раз прошу прощения.

Sova777 ()

Re: Проведен анализ результатов тестов производительности языков

> Но вот Java/javaxx - WTF? Судя по графикам, о тормозах речи не идёт ВООБЩЕ! Что за нафиг!?

Учите матчасть. Многое станет понятнее.

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