А в Java всё делалось через StringBuffer, как положено? )

eugene20237, нет, по двум причинам. Во-первых, задача сравнить предлагаемые решения "в лоб", а использование StringBuffer все же не лобовое решение, во-вторых, использование дополнительной прокладки такого рода еще раздуло бы код, код на Java и без того самый длинный. Ну и, говоря по сути, StringBuffer ничего не добавил бы в смысле производительности, т.к. C++ все равно не обогнала бы, и не решился бы основной минус Java - JIT работает только тогда, когда есть что оптимизировать, то есть на "больших дистанциях", на маленьком количестве итераций все равно Java бы проигрывала существенно. [А увеличение кода вообще выбросило бы ее из рейтинга...]

Гн. d0rc, языков этих всех практически не знаю, как и сути проделанного Вами, посему задам очевидно дурацкое: сами же писали про возможности как угодно реализовать что угодно... где гарантия, что в каждом языке для реализации одних и тех же действий были выбраны эквивалентные средства? или были выбраны наилучшие? И строковые упражнения как показатель- ?? Я конешно не мастак, но кой чего делал.. со строками упражнения никогда не имели какого-то значения.. Численные вычисления с данными разной точности.. динамическая прорисовка каких-то графически представляемых ситуаций...

а где в статистике всеми обожаемый Си чистый?:)

brahmann, в чистом С ну совсем нет ассоциативных массивов, я думал сделать с glib, но потом отказался от этой мысли - glib все же не широко распространенный стандарт... чего реально не хватает для полного счастья - это C#

Юрий_Мишенев, тесты с числами и т.д. были бы актуальны для решения вычислительно-интенсивных задач, а меня интересует прикладное программирование в данном случае... если надо что-то считать очень крупное, то по сути не важно на чем писать, лишь бы интерфейс к CUDA был удобным:)

Ответ на комментарий d0rc # вот тут не соглашусь, насчет glib - вторая параллельная профессия это программер, и уже лет 8-9 под юниксы и еже с ними - и в окружении линукс/юникс систем - как раз glib это почти стандарт, удобные структуры данных почти под все случаи(от серверных приложений до 3д-игр), а так же в glib как минимум лучше и надежнее(+быстрее) malloc и не только, много переписано и используется почти везде :) вообщем было бы неплохо с glib) увидеть циферки в разрезе с остальными

brahmann, ну посмотрим:) если руки дойдут до C#, то и на plain C сделаю...:) не смотря на malloc() ;)

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

Раз уж тут есть руби...а rebol не судьба попасть в твой тест? Интересно было бы увидеть сравнение с вышеописанными языками.

azlk, слушай, ну rebol - это нечто слишком экзотическое...:) вероятно, судьба у него будет лучше, чем у forth, но появится ли для него killer-application..? сомнительно...

С 1 Апреля! Жизнь коротка, надо стараться доставлять друг другу приятное. Русский человек на пустой желудок думать не может, а на сытый не хочет. Если девушка дала тебе ключ от сердца, не радуйся! Завтра она может поменять замок. Подруга спрашивает блондинку: - Чего грустная? - В посольстве анкету не приняли для визы. - Почему? - В самом конце в графе «Не заполнять» я написала «Хорошо». (инет) [498x362]

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

eugene20237, для чего вообще нужны скриптовые языки?:) по поводу разницы на 10% - это вопрос конкретики, где-то важно, где-то - нет... it all depends, рассуждать тут бессмыслено - ясно, что 10% не играет роли, если речь идет о нескольких секундах, а если речь идет о сотне тысяч таких секунд? это уже несколько суток... Вот сегодня общался с одним товарищем - он на perl переваривает описание архитектуры микросхем, один чип в среднем варится по нескольку суток, одновременно, как он говорит "компилируется" несколько сотен таких чипов... на мой вопрос "почему на perl?" толкового ответа не последовало, но оно и ясно - на входе хренова гора текстовых файлов, чем еще их пережевать? Конечно, это крайний случай, но любое такое сравнение обращается к экстремальным случаям....

А почему нет Delphi ?

TimaSoft, delphi - как среда не переносима, а pascal свое уже отжил по большому-то счету... по той же причине, по которой нет fortran, который есть подо всеми платформами... одной ногой в прошлом уже...

Ответ на комментарий azlk # да, rebol - довольно экзотический у нас язык, кстати, отчасти, благодаря тому, что он не поддерживал юникод. Но сейчас Carl Sassenrath с своей командой активно развивает R3, следующую версию Rebol-a и они собираются открыть бОльшую часть кода, кроме ядра. Т.е. все желающие смогут писать свои дополнения/расширения/диалекты/библиотеки к Rebol-у. Мне кажется, это очень сильно поднимет интерес разработчиков к этому языку, а там посмотрим. Меня лично в реболе привлекло его "очеловечивание" - т.е. программа пишется на простом английском языке, так сказать. Наверное тем, кто до этого пользовался и писал на С, perl и т. п. синтаксис языка покажется странным и непривычным, но мне, как человеку, который никогда не писал на С, это как раз более понятно. Cколько раз уже читал твои восторженные отзывы о perl-e, но до сих пор не могу понять прелести perla, глядя на подобное: while ($test =~ /\([^\(*.)]+\)/) { $test=~ s/\([^\(*.)]+\)//g; } Как это можно считать легко понятным? Мне это больше напоминает пословицу: "мы не ищем в жизи легких путей"... Если то же самое написать на реболе, это, по крайней мере, будет читаемым... P.S. конечно, я наверное, зря затеял эту тему, не будучи спецом ни в перле ни в реболе...

azlk, регулярные выражения сложны для понимания только на первый взгляд, но данный кусочек кода просто удаляет какие-то, видимо, комменты или что-то такое, если таковые есть, и мне трудно представить, как это можно сделать проще? Разве не проверять есть ли такой текст перед удалением... это уже вопрос привычки... как это же можно было бы сделать на rebol?

С нетерпением ждемс C# ;)

С праздником Мира, Тепла и Доброты! [450x435]

Да, было бы интересно увидеть C и C#. Удивлен такой производительностью у Ruby. Писал на нем пару раз, значительно хуже JS получалось. Возможно, дело в малом объеме данных. Спасибо за познавательный пост

[показать]