-Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 15.10.2005
Записей: 679
Комментариев: 2837
Написано: 4929


Очевидное, невероятное... c++, perl, ruby, php, js, java, python: revisited.

Вторник, 30 Марта 2010 г. 17:10 + в цитатник

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

Время работы. Сортировка по средневзвешенной оценке. Именно по этой причине Java - в самом конце, хотя на больших объемах данных начинает работать вполне шустро. JIT.

#101001000100001000001000000
 C++, STL, pcre0,003210,002840,003640,006630,039600,36632
 Perl0,004340,004340,005560,017040,140641,31983
 Ruby 1.80,005960,005760,007990,029670,249022,42525
 PHP0,012890,013160,014360,028020,162881,48665
 Ruby 1.90,011770,011280,013660,038760,266242,58928
 JavaScript, spidermonkey0,003530,003560,007600,049270,457864,47598
 Python0,018830,019190,025410,082410,662496,35694
 C++, STL, boost0,004500,005110,013900,105701,0292710,16208
 Sun Java 60,115110,123840,116030,175860,281480,78790
 JavaScript, rhino0,276910,333400,591081,273282,9192716,64209

 

Максимальный объем выденной памяти:

#101001000100001000001000000
 C++, STL, pcre1441449657 16454 848517 675
 C++, STL, boost6 3316 3317 15213 35161 035523 862
 Perl133 481133 481133 481139 768285 7621 623 683
 Ruby 1.8668 456678 820695 563735 377781 0292 130 300
 PHP1 599 4711 599 4711 599 4711 599 4711 599 4712 369 681
 Ruby 1.92 370 9362 370 6252 470 2982 798 6992 795 5314 060 924
 JavaScript, spidermonkey215 371218 835289 423971 6727 685 49375 059 213
 Sun Java 62 256 3002 256 3023 385 5255 613 9836 816 2017 638 547
 Python2 009 9142 010 0102 035 5782 340 4105 283 93035 508 602
 JavaScript, rhino4 917 6344 950 38023 957 53842 507 63551 072 15742 665 007
И, наконец, самое главное - размер кода:
 C++, STL, pcre806
 Perl274
 Ruby 1.8261
 PHP234
 Ruby 1.9261
 JavaScript, spidermonkey306
 Python342
 C++, STL, boost695
 Sun Java 6850
 JavaScript, rhino306
Собственно, что и требовалось доказать. Очень хотелось сюрприза, но не получилось.


Процитировано 1 раз

eugene20237   обратиться по имени Вторник, 30 Марта 2010 г. 17:20 (ссылка)
А в Java всё делалось через StringBuffer, как положено? )
Ответить С цитатой В цитатник
d0rc   обратиться по имени Вторник, 30 Марта 2010 г. 17:32 (ссылка)
eugene20237, нет, по двум причинам. Во-первых, задача сравнить предлагаемые решения "в лоб", а использование StringBuffer все же не лобовое решение, во-вторых, использование дополнительной прокладки такого рода еще раздуло бы код, код на Java и без того самый длинный. Ну и, говоря по сути, StringBuffer ничего не добавил бы в смысле производительности, т.к. C++ все равно не обогнала бы, и не решился бы основной минус Java - JIT работает только тогда, когда есть что оптимизировать, то есть на "больших дистанциях", на маленьком количестве итераций все равно Java бы проигрывала существенно. [А увеличение кода вообще выбросило бы ее из рейтинга...]
Ответить С цитатой В цитатник
Юрий_Мишенев   обратиться по имени Среда, 31 Марта 2010 г. 10:13 (ссылка)
Гн. d0rc, языков этих всех практически не знаю, как и сути проделанного Вами, посему задам очевидно дурацкое: сами же писали про возможности как угодно реализовать что угодно... где гарантия, что в каждом языке для реализации одних и тех же действий были выбраны эквивалентные средства? или были выбраны наилучшие? И строковые упражнения как показатель- ??
Я конешно не мастак, но кой чего делал.. со строками упражнения никогда не имели какого-то значения.. Численные вычисления с данными разной точности.. динамическая прорисовка каких-то графически представляемых ситуаций...
Ответить С цитатой В цитатник
brahmann   обратиться по имени Среда, 31 Марта 2010 г. 12:03 (ссылка)
а где в статистике всеми обожаемый Си чистый?:)
Ответить С цитатой В цитатник
d0rc   обратиться по имени Среда, 31 Марта 2010 г. 15:16 (ссылка)
brahmann, в чистом С ну совсем нет ассоциативных массивов, я думал сделать с glib, но потом отказался от этой мысли - glib все же не широко распространенный стандарт... чего реально не хватает для полного счастья - это C#
Ответить С цитатой В цитатник
d0rc   обратиться по имени Среда, 31 Марта 2010 г. 15:21 (ссылка)
Юрий_Мишенев, тесты с числами и т.д. были бы актуальны для решения вычислительно-интенсивных задач, а меня интересует прикладное программирование в данном случае... если надо что-то считать очень крупное, то по сути не важно на чем писать, лишь бы интерфейс к CUDA был удобным:)
Ответить С цитатой В цитатник
brahmann   обратиться по имени Среда, 31 Марта 2010 г. 16:07 (ссылка)

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

вот тут не соглашусь, насчет glib - вторая параллельная профессия это программер, и уже лет 8-9 под юниксы и еже с ними - и в окружении линукс/юникс систем - как раз glib это почти стандарт, удобные структуры данных почти под все случаи(от серверных приложений до 3д-игр), а так же в glib как минимум лучше и надежнее(+быстрее) malloc и не только, много переписано и используется почти везде :)
вообщем было бы неплохо с glib) увидеть циферки в разрезе с остальными
Ответить С цитатой В цитатник
d0rc   обратиться по имени Среда, 31 Марта 2010 г. 17:47 (ссылка)
brahmann, ну посмотрим:) если руки дойдут до C#, то и на plain C сделаю...:) не смотря на malloc() ;)
Ответить С цитатой В цитатник
brahmann   обратиться по имени Среда, 31 Марта 2010 г. 17:53 (ссылка)

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

Ответить С цитатой В цитатник
azlk   обратиться по имени Четверг, 01 Апреля 2010 г. 05:24 (ссылка)
Раз уж тут есть руби...а rebol не судьба попасть в твой тест? Интересно было бы увидеть сравнение с вышеописанными языками.
Ответить С цитатой В цитатник
d0rc   обратиться по имени Четверг, 01 Апреля 2010 г. 15:47 (ссылка)
azlk, слушай, ну rebol - это нечто слишком экзотическое...:) вероятно, судьба у него будет лучше, чем у forth, но появится ли для него killer-application..? сомнительно...
Ответить С цитатой В цитатник
Millio   обратиться по имени Сделай контрольный звонок! ))) Четверг, 01 Апреля 2010 г. 15:55 (ссылка)
С 1 Апреля!

Жизнь коротка, надо стараться доставлять друг другу приятное.

Русский человек на пустой желудок думать не может, а на сытый не хочет.

Если девушка дала тебе ключ от сердца, не радуйся! Завтра она может поменять замок.

Подруга спрашивает блондинку:
- Чего грустная?
- В посольстве анкету не приняли для визы.
- Почему?
- В самом конце в графе «Не заполнять» я написала «Хорошо».

(инет)
1218tel (498x362, 54 Kb)
Ответить С цитатой В цитатник
eugene20237   обратиться по имени Четверг, 01 Апреля 2010 г. 20:49 (ссылка)
Вообще для чего нужны быстрые конкатенации строк? По-моему в первую очередь для веба и других не реалтаймовых приложений. А раз так, то разница в скорости менее чем в два раза - это вообще не разница.
Ответить С цитатой В цитатник
d0rc   обратиться по имени Четверг, 01 Апреля 2010 г. 21:18 (ссылка)
eugene20237, для чего вообще нужны скриптовые языки?:) по поводу разницы на 10% - это вопрос конкретики, где-то важно, где-то - нет... it all depends, рассуждать тут бессмыслено - ясно, что 10% не играет роли, если речь идет о нескольких секундах, а если речь идет о сотне тысяч таких секунд? это уже несколько суток...
Вот сегодня общался с одним товарищем - он на perl переваривает описание архитектуры микросхем, один чип в среднем варится по нескольку суток, одновременно, как он говорит "компилируется" несколько сотен таких чипов... на мой вопрос "почему на perl?" толкового ответа не последовало, но оно и ясно - на входе хренова гора текстовых файлов, чем еще их пережевать? Конечно, это крайний случай, но любое такое сравнение обращается к экстремальным случаям....
Ответить С цитатой В цитатник
TimaSoft   обратиться по имени Четверг, 01 Апреля 2010 г. 21:59 (ссылка)
А почему нет Delphi ?
Ответить С цитатой В цитатник
d0rc   обратиться по имени Четверг, 01 Апреля 2010 г. 22:10 (ссылка)
TimaSoft, delphi - как среда не переносима, а pascal свое уже отжил по большому-то счету... по той же причине, по которой нет fortran, который есть подо всеми платформами... одной ногой в прошлом уже...
Ответить С цитатой В цитатник
azlk   обратиться по имени Пятница, 02 Апреля 2010 г. 03:20 (ссылка)

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

да, rebol - довольно экзотический у нас язык, кстати, отчасти, благодаря тому, что он не поддерживал юникод. Но сейчас Carl Sassenrath с своей командой активно развивает R3, следующую версию Rebol-a и они собираются открыть бОльшую часть кода, кроме ядра. Т.е. все желающие смогут писать свои дополнения/расширения/диалекты/библиотеки к Rebol-у. Мне кажется, это очень сильно поднимет интерес разработчиков к этому языку, а там посмотрим.
Меня лично в реболе привлекло его "очеловечивание" - т.е. программа пишется на простом английском языке, так сказать. Наверное тем, кто до этого пользовался и писал на С, perl и т. п. синтаксис языка покажется странным и непривычным, но мне, как человеку, который никогда не писал на С, это как раз более понятно.
Cколько раз уже читал твои восторженные отзывы о perl-e, но до сих пор не могу понять прелести perla, глядя на подобное:
while ($test =~ /\([^\(*.)]+\)/) {
$test=~ s/\([^\(*.)]+\)//g;
}
Как это можно считать легко понятным? Мне это больше напоминает пословицу: "мы не ищем в жизи легких путей"...
Если то же самое написать на реболе, это, по крайней мере, будет читаемым...
P.S. конечно, я наверное, зря затеял эту тему, не будучи спецом ни в перле ни в реболе...
Ответить С цитатой В цитатник
d0rc   обратиться по имени Пятница, 02 Апреля 2010 г. 14:47 (ссылка)
azlk, регулярные выражения сложны для понимания только на первый взгляд, но данный кусочек кода просто удаляет какие-то, видимо, комменты или что-то такое, если таковые есть, и мне трудно представить, как это можно сделать проще? Разве не проверять есть ли такой текст перед удалением... это уже вопрос привычки... как это же можно было бы сделать на rebol?
Ответить С цитатой В цитатник
Zoom   обратиться по имени Воскресенье, 04 Апреля 2010 г. 15:25 (ссылка)
С нетерпением ждемс C# ;)
Ответить С цитатой В цитатник
senbazuru   обратиться по имени Суббота, 01 Мая 2010 г. 12:13 (ссылка)
С праздником Мира, Тепла и Доброты!
d8FCZLg8QScYri4 (450x435, 121 Kb)
Ответить С цитатой В цитатник
serzh-laro   обратиться по имени Воскресенье, 09 Мая 2010 г. 10:20 (ссылка)
Да, было бы интересно увидеть C и C#. Удивлен такой производительностью у Ruby. Писал на нем пару раз, значительно хуже JS получалось. Возможно, дело в малом объеме данных. Спасибо за познавательный пост
Ответить С цитатой В цитатник
Аноним   обратиться по имени Суббота, 25 Февраля 2012 г. 13:40 (ссылка)
Ответить С цитатой В цитатник    |    Не показывать комментарий
Комментировать К дневнику Страницы: [1] [Новые]
 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

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