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

> Потому что там цель теста — выяснение скорости работы именно с объектами.

Дошло... :)

Не с первого раза - сначала только табличку посмотрел. Точно мне пора глаза и мозги чинить - там и в заголовке, и в превью, и после таблички всё расписано - надо было только повнимательнее посмотреть. :)

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

А за эту ссылочку отдельное спасибо. Учту.

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

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

Ты никогда не думал, что для всех этих разных моделей языков программирования, нужны разные рантаймы, которые проводят разную оптимизацию, и оперируют совершенно разными объектами

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

весь основной «удар» по расхлёбыванию заморочек с синтаксисом конкретного языка на себя принимает front-end, а back-end, который runtime, имеет дело с аппаратными заморочками

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

вспомни, ты же сам обкладываешь лисповый код «подпорками», когда хочешь эффективного исполнения на платформе x86

собственно вот, если бы не повымерли в своей массе железячные lisp-машины, конечно ничего оптимальнее голого лиспа, для них не было бы, и это был бы идеальный аппаратный рантайм

но мы говорим про jvm, и про платформу x86 (или около того), не думаю что jvm в данном разрезе отличается кардинально от любой другой среды исполнения

и создать одну оптимальную для всех них платформу - невозможно

это, как минимум, зависит от критерия оптимальности

Кстати, кто-нибудь знает, почему там до сих пор торчит закопанный, эксгумированный и снова закопанный Mozart/Pz, а MLton, SML/NJ и Gforth куда-то испарились?

Про то, что лиспов там полторы штуки (среди которых ни одной нормальной схемы) я молчу.

концепция «всё — строка» оставлена только внешне, внутри же всё перестроено для увеличения производительности

всё верно. но моего комментария это не отменяет. бета Tcl 8.6 выглядит в этом смысле многообещающе, но бета - это всего лишь бета

Не на Celeron, конечно, да и питон был PyPy с jit =)

Я это к тому, что толку от всех этих тестов нету никакого. Ты же все равно не будешь веб-приложение переписывать на плюсах, потому, что они быстрые. Выбор языка зависит от его мощности для конкретной задачи. Есть ли нужные библиотеки и т.д. А так, да, для сферических тестов в вакууме можно померяться пиписьками, тут PyPy зарулит все динамические языки. Еще б он поддерживал нормально C-шные расширения.

> PyPy зарулит все динамические языки.

Это неправда, потому что динамические /= скриптовые.

Я и не утверждал, что динамические == скриптовые. Но согласен, с объявлением PyPy победителем поспешил - нужно еще пару годков подождать.

>Ты же все равно не будешь веб-приложение переписывать на плюсах, потому, что они быстрые

Нет. Но я могу выбирать для новых проектов между Python vs Ruby или Groovy vs Jython :)

если тебе нужно не простой микроменчмарк, а более серьезный тест - http://lionet.livejournal.com/68807.html

>не простой микроменчмарк, а более серьезный тест

Хы, там написано что на реальных задачах Java опережает C/C++ в 3(!) раза. Тупо за щет JIT-а