не найдёшь
инфа 100%
гуру одного языка != гуру другого языка
потому тесты некорректны сами по себе
а с скриптовых ещё и куча делитантов/ламо - тут даже среднестатистический не показатель
успокойся

http://shootout.alioth.debian.org/

Не вижу там tcl

они _все_ ортогональны производительности

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

о_О

ты себе и девушку выбираешь по массе мышц, цвету диплома или сколько литров пива она может выпить за 5 минут?

они все одинаково тормозные. серьезно.

Какая разница в 1100 раз что-то медленее сишечки работает или в 1200?

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

Все что в произвольно взятом скриптовом языке есть, там тоже есть(я имею ввиду, обычно какую-то конкретную скриптоту берут ради какого-либо определенного фреймворка, ну типа рабби для рельсов и т.п., но тебе походу все равно какой брать, так что проблемы нет). Базовый минимум библиотек берется в quicklisp'е, дополнительное - ну модули на си и прочем можно писать, как и в скриптовых языках. Встраивать тоже можно, по идее(я недавно ECL собрал - все ништяк работает, встраивается очень легко).

lovesan

зато всё остальное есть

по идее groovy из-за того что транслируется в байт-код jvm должен рвать их всех по производительности, так что в приведенной во втором комменте ссылке цифры для явы относятся и к груви

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

А что, давно это плюсцы автоматически означают высокопроизводительный код?

Я тебя уверяю, я видел на плюсах проекты, которые работали быстрее после переписывания не то что на Java, так на тот самый Python.

ну....как писать
привет миры в разы быстрей овер конвертор
а если выхлоп ещё и перелопатить...

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

JVM такая штука, что заточена под один конкретный язык, угадай какой. И соответственно, более-менее быстро на JVM работает только он. Серьезно, жабовая виртуальная машина была спроектирована, да и сейчас дорабатывается, так, чтобы на ней именно и только Java и работала быстро. Это даже в названии у нее указано, прикиньте.

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

Другие JVM-языки, и особенно те, которые на Java нисколько не похожи, и особенно с динамической типизацией(типа IronPython etc. - зацените кто-нибудь на досуге), на JVM тормозят так, что их реализации и аналоги вне JVM кажутся просто каким-то адовым космолетом на термоядерном топливе.

lovesan

ппц логика

По теме может кто-нибудь сказать? Без обсуждения — зачем это надо. И без рекламы лиспа и си. Я специально тему создавал не в Talks.

Учитывая, что в быстром темпе жизни все читают только начальные и конечные слова поста, закончу повтором:

обязательны: perl, ruby, python, tcl

Сначала скажи, зачем тебе это.

Хливких шорьков напикать.

Теперь по плану реклама Лиспа.

сделай сам )

> обязательны: perl, ruby, python, tcl

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

ппц как тут трудно добиться прямого ответа на вопрос. Позовёте меня, когда будете рецепт яичницы с помидорами обсуждать?

Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками.

Возможности Groovy (отличающие его от Java):
— Статическая и динамическая типизация
— Встроенный синтаксис для списков, ассоциативных массивов, массивов и регулярных выражений
— Замыкания
— Перегрузка операций

Более того, почти всегда java-код — это валидный groovy-код.

http://shootout.alioth.debian.org/

отличный тест, СИшка почти на одном уровне с питоном идёт.

лучше озвучь свою задачу

JVM такая штука, что заточена под один конкретный язык, ugoday какой.

// qfix

JVM такая штука, что заточена под один конкретный язык, угадай какой. И соответственно, более-менее быстро на JVM работает только он. Серьезно, жабовая виртуальная машина была спроектирована, да и сейчас дорабатывается, так, чтобы на ней именно и только Java и работала быстро. Это даже в названии у нее указано, прикиньте.

синтепончик, ты вот адекватный чувак, но пока не вылезаешь за Lisp-domain, ну вот зачем ты это сказал, чтобы с тебя пруф попросили?

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

какой вопрос задал, такие и ответы получи

Позовёте меня, когда будете рецепт яичницы с помидорами обсуждать?

говорящие помидоры!!!111

Другие JVM-языки, и особенно те, которые на Java нисколько не похожи, и особенно с динамической типизацией(типа IronPython [..]

«IronPython is an implementation of the Python programming language running under .NET/Mono and Silverlight/Moonlight.» (c)

JVM - мать-героиня, и своих детей кучу вынашивает, и чужих не чурается

Блять, ну перепутал, вот придрался, а.

Jython имелся ввиду, да.

это лавсан то адекватный?!?!?!

Давай прежде чем делать умный всёзнающий вид, оговоришь, какие именно пункты и тезисы вызывают сомнения?

Хотя, сначала попробую угадать. Я так понимаю, тебя смущает тезис о том, что рантайм JVM является субоптимальным для динамических языков, для функциональщины, а также языков с объектной моделью, отличной от жабовой(т.е. с прототипным ООП, с мультиметодами и т.п.)?

Ты никогда не думал, что для всех этих разных моделей языков программирования, нужны разные рантаймы, которые проводят разную оптимизацию, и оперируют совершенно разными объектами, и создать одну оптимальную для всех них платформу - невозможно(даже, допустим, x86е процессоры под такую не подходят, и заточены они фактически только под си-подобные языки(которые суть статическая типизация плюс единая линейная неуправляемая виртуальная память); но хрен с ними с процессорами, раз уж мы про VM работающие поверх них)? Не думал?

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

lovesan

Тебя не должно это волновать.

выдыхай, бобёр, если ты про C INT - то это интерпретатор

смотри внимательнее, C GCC

>они все одинаково тормозные. серьезно.

Если для тебя разница в два порядка — это «одинаково», то… :D

>отличный тест

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

>По теме может кто-нибудь сказать?

http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

Сильно устарело, местами (скажем, у Ruby) подвижки заметные, но ориентироваться можно.

Крон, а почему на pure C теста нет? :)

Интересно стало, на какое место С втиснется...

Тестов не дам, то видимо perl, lua, nodejs - самые быстрые

У питона тоже подвижки были: твое фибоначи посчиталось за 4.4s

Скриптовый язык — на то и скриптовый, что его производительность не важна.

Python быстрее )

Помню писал когда-то бота и решил переписать на разных языках (скриптовых) программирования. В конце остались руби и питон. Руби обгонял питон. Пришлось оптимизировать питон-бота. Теперь, питон уже обгонял руби. Начал оптимизировать руби-бота. Снова руби рвал питон. Оптимизировал питон, оптимизировал руби. Питон, руби, питон, руби. Про%;бался неделю. В конечно итоге остался на питоне. Разницы никакой между ними нету, бери то, что тебе легче даётся, приятней и интуитивно понятней.

Не вижу там tcl

у Tcl медленное всё. кроме, пожалуй, FFI - вызовы в/из C очень дешёвые

это лавсан то адекватный?!?!?!

судя по пунктуации - всяко адекватней тебя :)

>Крон, а почему на pure C теста нет? :)

Потому что там цель теста — выяснение скорости работы именно с объектами. К сожалению, так руки не дошли потом сделать ещё вариант с наследованием — на нём тоже оверхед заметный бывает.

А чисто числодробильные тесты — для этого и shootout.alioth.debian.org есть :)

>У питона тоже подвижки были: твое фибоначи посчиталось за 4.4s

Тут же важно, какое железо. Вряд ли ты тест на Celeron-1860 делал :)

Свежак еп

http://onlyjob.blogspot.com/2011/03/perl5-python-ruby-php-c-c-lua-tcl.html

у Tcl медленное всё

Многократно читал, что этим страдают только старые версии tcl. В новых версиях уже байткод, а концепция «всё — строка» оставлена только внешне, внутри же всё перестроено для увеличения производительности (см. напр. md5).

Всем perl5, пацаны!

сделай сам как https://www.linux.org.ru/wiki/en/LOR-contest

Ява радует зато :)

:D