Комментарии 156
НЛО прилетело и опубликовало эту надпись здесь
А Вы меня удивили (и наверное не только меня :) - так как обычно считается что быстрота и простота разработки на Ruby компенсируется медленной работой интерпретатора ( что, как видно из данных теста - уже не так)
НЛО прилетело и опубликовало эту надпись здесь
PHP интерпретатор написанный на .NET быстрее, чем PHP интерпретатор написанный на C++? 0_о
НЛО прилетело и опубликовало эту надпись здесь
возможно так получается потому что в итоге код PHP не интерпретируется, а прекомпилируется в MSIL/CIL и выполняется уже как обычное .NET приложение?
в тестах нигде не сказано про тестирование с PHP-акселераторами...
З.Ы.: забавный проект, надо бы присмотреться :)
в тестах нигде не сказано про тестирование с PHP-акселераторами...
З.Ы.: забавный проект, надо бы присмотреться :)
это порт языка на платформу .NET
соответсвенно все транслируется CLI, который выполняется CLR уж точно быстрее чем PHP интерпретатором.
другой вопрос, что для .NET есть нормальные языки программирования и смысл PHP под ним, заключается только в том, чтобы безболезненно перенести существующий код под .NET
соответсвенно все транслируется CLI, который выполняется CLR уж точно быстрее чем PHP интерпретатором.
другой вопрос, что для .NET есть нормальные языки программирования и смысл PHP под ним, заключается только в том, чтобы безболезненно перенести существующий код под .NET
Но вообще реализация для NET есть не только для PHP :)
Есть и IronPython и IronRuby - компиляторы для .NET
Есть и IronPython и IronRuby - компиляторы для .NET
Для дотнета есть языки получше, чем PHP. Зачем такие извращения? Или, "на пхп уже есть готовый проект"? Тогда непонятно, зачем съезжать с линукса. Впрочем, пхп, дотнет, винда порождают больше вопросов, чем дают ответов, что с них взять...
НЛО прилетело и опубликовало эту надпись здесь
Если смотреть с этой стороны тогда Вас должен заинтересовать
Roadsend PHP Compiler - кроссплатформенный компилятор в машинный код
Roadsend PHP Compiler - кроссплатформенный компилятор в машинный код
У руби версии до 3-й точки перечислены. А пых какой? 3-й? php-fi 2?
Какие тесты? Покажите коды.
PHP как модуль? Какие расширения? Какой сервер? Какая операционка?
Что это за стандартный набор тестов по которому можно сравнить C и JS?
Какие тесты? Покажите коды.
PHP как модуль? Какие расширения? Какой сервер? Какая операционка?
Что это за стандартный набор тестов по которому можно сравнить C и JS?
А походить по ссылкам, которые в статье - это против Ваших правил?
PHP 5.2.2-pl1-gentoo
Тест с исходным кодом на PHP 1
Тест с исходным кодом на PHP 2
Тест с исходным кодом на PHP 3
и так далее
PHP 5.2.2-pl1-gentoo
Тест с исходным кодом на PHP 1
Тест с исходным кодом на PHP 2
Тест с исходным кодом на PHP 3
и так далее
Господи, что за код!
Да одна замена:
for($i=0; $i<$n; $i++) $perm[$i] = $perm1[$i];
на
$perm = $perm1
дает 15% прироста. С остальным поковыряться, вполне возможно и до 50 дойдет.
Это вне разговора о том, что обход бинарных деревьев не то, на чем нужно тестировать языки для веб-программирования.
Да одна замена:
for($i=0; $i<$n; $i++) $perm[$i] = $perm1[$i];
на
$perm = $perm1
дает 15% прироста. С остальным поковыряться, вполне возможно и до 50 дойдет.
Это вне разговора о том, что обход бинарных деревьев не то, на чем нужно тестировать языки для веб-программирования.
Господи, что за код!
Да одна замена:
for($i=0; $i
Я аж подавился. Давайте выкинем цикл и 2 массива, и заменим их на присвоение значения одной переменной другой.
Хорошо Вы алгоритм оптимизирует - может вообще вместо всего теста $perm = $perm1 написать и все?
Прошу прощения, по вашему от этого изменится результат?
изменится суть/идея теста.
Не могли бы пояснить эту суть?
Ну и где там суть?
Ладно, суть мне не рассказывают, а только минусики ставят. Попробую высказаться сам.
В тесте сравнивается быстродействие Ruby и PHP на преобразованиях массивов. Очень странный выбор для области применения данных языков, но черт с ним.
В процессе решения данной задачи, возникает подзадача — копирование массива.
Лично я делаю это так: $array1 = $array2; Большинство трезвомыслящих людей делают это аналогично. Поэтому у нас PHP работает на соответствующей скорости.
Граждане тестеры решили сделать по другому — циклическим присвоением значений, написанном на интерпретируемом языке. В качестве цикла был выбран for (даже foreach в данном случае был бы
намного быстрее).
На основании временных замеров они делают вывод, что PHP по скорости примерно равен Ruby. Вообще, равен. Не на данном идиотском примере, а вообще. И большинство людей, прочитавших это
сообщение сделает тот же вывод.
Давайте пойдем дальше — напишем тоже самое на ассемблере. Потом создадим php-сценарий, в котором определим класс CPU, с полями AX, BX, CX... Создадим большой массив Memory и функции по
доступу к нему. Напишем функции MOV, ADD и т.д. И реализуем дословно ассемблерный алгоритм. А потом будем строить графики и кормить ими неокрепшие мозги веб-программистов.
Ладно, суть мне не рассказывают, а только минусики ставят. Попробую высказаться сам.
В тесте сравнивается быстродействие Ruby и PHP на преобразованиях массивов. Очень странный выбор для области применения данных языков, но черт с ним.
В процессе решения данной задачи, возникает подзадача — копирование массива.
Лично я делаю это так: $array1 = $array2; Большинство трезвомыслящих людей делают это аналогично. Поэтому у нас PHP работает на соответствующей скорости.
Граждане тестеры решили сделать по другому — циклическим присвоением значений, написанном на интерпретируемом языке. В качестве цикла был выбран for (даже foreach в данном случае был бы
намного быстрее).
На основании временных замеров они делают вывод, что PHP по скорости примерно равен Ruby. Вообще, равен. Не на данном идиотском примере, а вообще. И большинство людей, прочитавших это
сообщение сделает тот же вывод.
Давайте пойдем дальше — напишем тоже самое на ассемблере. Потом создадим php-сценарий, в котором определим класс CPU, с полями AX, BX, CX... Создадим большой массив Memory и функции по
доступу к нему. Напишем функции MOV, ADD и т.д. И реализуем дословно ассемблерный алгоритм. А потом будем строить графики и кормить ими неокрепшие мозги веб-программистов.
А давайте в праведном гневе не переигрывать - а то понимаешь ли международный заговор против PHP разоблачили :)
Сравниваются по скорости очень много языков - на тестах, которые реализуют определенную функциональность - в ссылке которую я привел постом выше указано - какую именно. И если допустим та же строчка в тестах для С допустим выглядит как
for( i=1 ; i<n ; ++i ) {
perm[i] = perm1[i];
}
В тестах для Java
for (int i = 0; i < n; i++) perm[i] = perm1[i];
То почему она в тестах для PHP она должна быть специально так написана, что бы у PHP преимущество было?
Ниже уже написал - Если Вы считаете что приведенный в тесте код не достаточно оптимально реализует требования теста- напишите свой и отправьте тестировщикам.
Сравниваются по скорости очень много языков - на тестах, которые реализуют определенную функциональность - в ссылке которую я привел постом выше указано - какую именно. И если допустим та же строчка в тестах для С допустим выглядит как
for( i=1 ; i<n ; ++i ) {
perm[i] = perm1[i];
}
В тестах для Java
for (int i = 0; i < n; i++) perm[i] = perm1[i];
То почему она в тестах для PHP она должна быть специально так написана, что бы у PHP преимущество было?
Ниже уже написал - Если Вы считаете что приведенный в тесте код не достаточно оптимально реализует требования теста- напишите свой и отправьте тестировщикам.
Это тест, показывающий скорость языка по поэлементному копированию массива в цикле for. Если задача тестов была в этом, то хорошо. Возможно, да, Ruby в данном случае равен PHP по скорости.
Однако, название статьи "Ruby медленнее PHP? Уже нет!" и её посыл в том, что Ruby сравнялся с PHP в их предметной области.
К сожалению, большинство сделает выводы именно по самому тексту статьи и не будет вникать в суть тестов.
Я же считаю, что эти тесты ничего не показывают, кроме скорости все того же for-перебора и подобного.
Если бы была просто задача - "получить все возможны комбинации заданного числа цифр", то можно было бы сравнивать языки, но только написав для каждого из них свой алгоритм, подходящий для особенностей данного языка. Просто же переносить Сишный с его особенностями и заточкой под Си, смысла нет никакого.
Однако, название статьи "Ruby медленнее PHP? Уже нет!" и её посыл в том, что Ruby сравнялся с PHP в их предметной области.
К сожалению, большинство сделает выводы именно по самому тексту статьи и не будет вникать в суть тестов.
Я же считаю, что эти тесты ничего не показывают, кроме скорости все того же for-перебора и подобного.
Если бы была просто задача - "получить все возможны комбинации заданного числа цифр", то можно было бы сравнивать языки, но только написав для каждого из них свой алгоритм, подходящий для особенностей данного языка. Просто же переносить Сишный с его особенностями и заточкой под Си, смысла нет никакого.
А вот тут давайте не будем.
Тесты реализуют типовые задачи - именно на этом и нужно сравнивать производительность языков. Почти в любой задачи используются типовые элементы -массивы, циклы, рекурсивные функции и т.д. Вот именно скорость/потребление памяти при работе с этими элементами и изучается.
А что по Вашему должно сравниваться - (особенно раз Вы упомянули некую "предметную область") - скорость подключения к БД что ли? Так это зависит от БД.
Посмотрите тесты дальше - реализуются разные алгоритмы. Причем именно - скорость работы одного и того же алгоритма но написанного на разных языках – мы же языки сравниваем по скорости, а не алгоритмы – разве не так?
Тесты реализуют типовые задачи - именно на этом и нужно сравнивать производительность языков. Почти в любой задачи используются типовые элементы -массивы, циклы, рекурсивные функции и т.д. Вот именно скорость/потребление памяти при работе с этими элементами и изучается.
А что по Вашему должно сравниваться - (особенно раз Вы упомянули некую "предметную область") - скорость подключения к БД что ли? Так это зависит от БД.
Посмотрите тесты дальше - реализуются разные алгоритмы. Причем именно - скорость работы одного и того же алгоритма но написанного на разных языках – мы же языки сравниваем по скорости, а не алгоритмы – разве не так?
Что мы сравниваем по скорости? Смысл существования различных языков не в том, что на них решаются одни и те же задачи, одними и теми же алгоритмами, только с разной скоростью. Тогда бы право на существования имел только один язык - самый быстрый.
Смысл же их существования в том, что задачи решаются по разному, разными алгоритмами. Поэтому, одни языки подходят для одного круга задач, а другие для другого.
Взять С-код и изменить в нем "int i = 0" на "$i = 0", а потом что-то сравнивать бессмысленно. Если так, ни PHP, ни Ruby не нужны. Есть C и он быстрее.
Нужны же они именно потому что там не нужно копировать массивы так как это делается в Ц.
Смысл же их существования в том, что задачи решаются по разному, разными алгоритмами. Поэтому, одни языки подходят для одного круга задач, а другие для другого.
Взять С-код и изменить в нем "int i = 0" на "$i = 0", а потом что-то сравнивать бессмысленно. Если так, ни PHP, ни Ruby не нужны. Есть C и он быстрее.
Нужны же они именно потому что там не нужно копировать массивы так как это делается в Ц.
Еще раз - есть условия задачи/действия (как пример - перечисленные ниже) - их нужно реализовать на конкретном языке. Я уже говорил - если реализовано не правильно - предложите вариант где те же действия будут реализованы более удачно.
Ну а требовать, что бы тест, общий для всех языков, специально для PHP как то особенным образом корректировался - это уже черезчур.
Ну а требовать, что бы тест, общий для всех языков, специально для PHP как то особенным образом корректировался - это уже черезчур.
Еще раз. Если бы тест был "перебрать все возможные варианты заданного набора цифр", то это одно. Сама задача не сказать, что хорошая, но да ладно. Вот её в качестве тестов можно было порешать. Решать для каждого языка своим алгоритмом, подходящим для данного языка. Чтобы алгоритм (не тест) корректировался для PHP и для всех остальных.
Здесь же взяли C-решение и воспроизвели его алгоритм на других языках только с изменением синтаксиса.
Здесь же взяли C-решение и воспроизвели его алгоритм на других языках только с изменением синтаксиса.
Так ведь сравнивают скорость работы массивов/циклов - а не то, какие в каком языке есть хитрые хаки - именно для этого там и должны они быть, а не что то другое.
Вы серьезно не понимаете в чем вообше смысл тестирования или специально претворяетесь? :(
Вы серьезно не понимаете в чем вообше смысл тестирования или специально претворяетесь? :(
Это не хитрые хаки. Это элементарные основы языка. Вывод вашей статьи:
Какой к чорту производительности? Если решать на PHP задачи методами Си, никакой производительности не будет.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
Вывод – по производительности PHP и Ruby Core 1.9.0 примерно равны
Какой к чорту производительности? Если решать на PHP задачи методами Си, никакой производительности не будет.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
"Скорость работы массивов/циклов" в предметной области PHP имеет не главенствующее значение.
Скорость работы массивов/циклов/регулярных выражений/рекурсии – имеет не главенствующее значение – а что тогда имеет? Скорость работы операторов print и echo?
Мы же все таки языки программирования сравниваем, а не шаблонные движки.
вообщето тест сводится к измерениям
>Indexed-access to tiny integer-sequence N=11
на примере какой именно задачи не важно.
именно поэтому for($i=0; $i и никаких each, foreach и прочего
>Indexed-access to tiny integer-sequence N=11
на примере какой именно задачи не важно.
именно поэтому for($i=0; $i и никаких each, foreach и прочего
НЛО прилетело и опубликовало эту надпись здесь
Да не в том дело. Тут товарищ Вам говорит, как я понимаю, чтобы тестировать язык комплексно, в реальных, боевых условиях - формирование страниц из шаблонов, функции доступа к данным, обработки XML и т.д., а не синтетические тесты на скорость присвоения.
0_о
for($i=0; $i<$n; $i++) $perm[$i] = $perm1[$i];
а Вы предлагаете написать $perm = $perm1
А если элементов в массиве больше чем $n?
for($i=0; $i<$n; $i++) $perm[$i] = $perm1[$i];
а Вы предлагаете написать $perm = $perm1
А если элементов в массиве больше чем $n?
Их не больше. $perm1 создается чуть выше с размерностью $n.
А $perm ? Ниже по коду посмотрите
А какая разница, что ниже по коду? К моменту копирования perm1 имеет размер N, perm не определен.
Результат в обоих случаях получается одинаковый, можете проверить.
Результат в обоих случаях получается одинаковый, можете проверить.
Гм. Вы читали требования к тесту? - что он должен делать - (ссылку чуть выше давал)
Если Вы считаете что приведенный в тесте код не достаточно оптимально реализует эти требования - напишите свой и отправьте тестировщикам. Всем будет только на пользу, если тестирование будет правильным и корректным для каждого языка.
(Повысил карму :)
Each program should
* "Take a permutation of {1,...,n}, for example: {4,2,1,5,3}.
* Take the first element, here 4, and reverse the order of the first 4 elements: {5,1,2,4,3}.
* Repeat this until the first element is a 1, so flipping won't change anything more: {3,4,2,1,5}, {2,4,3,1,5}, {4,2,3,1,5}, {1,3,2,4,5}.
* Count the number of flips, here 5.
* Do this for all n! permutations, and record the maximum number of flips needed for any permutation.
* Write the first 30 permutations and the number of flips.Если Вы считаете что приведенный в тесте код не достаточно оптимально реализует эти требования - напишите свой и отправьте тестировщикам. Всем будет только на пользу, если тестирование будет правильным и корректным для каждого языка.
(Повысил карму :)
"обход бинарных деревьев не то, на чем нужно тестировать языки для веб-программирования."
Согласен на 100%. А вот если сравнивать гибкость написания Си-экстеншенов для пхп и руби, то первый просасывает по всем статьям.
Тем не менее, я был бы очень даже не против, если на динамическом языке можно будет писать обход бинарных деревьев, без приклеивания Си.
Согласен на 100%. А вот если сравнивать гибкость написания Си-экстеншенов для пхп и руби, то первый просасывает по всем статьям.
Тем не менее, я был бы очень даже не против, если на динамическом языке можно будет писать обход бинарных деревьев, без приклеивания Си.
Почему так все негативно относятся именно к тесту по обходу бинарных деревьев? :)
Интересная задача - не самая распространенная конечно, но иногда очень нужная.
И показательная - как в плане вычислительной мощности языка, так и в плане демонстрации синтаксиса.
Интересная задача - не самая распространенная конечно, но иногда очень нужная.
И показательная - как в плане вычислительной мощности языка, так и в плане демонстрации синтаксиса.
Если оба языка не годятся для определенной задачи (обход Б-дерева, например), но один делает ее чуть быстрее — это не показатель. Показателей, вообще-то, два. Первый: один из языков можно использовать для задачи Икс, а второй - нельзя. Тут относительные отличия не так важны. Второй показатель: оба языка годятся для задачи Игрек и тут важны относительные значения.
Сравнивать руби и пхп имеет смысл, например, на пересечении/объединении массивов. Т.к. на больших нагрузках на сайт (когда серверов БД 5 штук, а бекендов с монгрелами/апачами - 100) иногда имеет смысл часть операций над данными вынести из БД в бекенды. Скажем, не делать LEFT JOIN, а двумя запросами получить списки айдишников и пересечь их в скрипте. Потому что бекендов в 20 раз больше, чем БД. А вот бинарные деревья пока БД обходит быстрее (в тех случаях, когда они нужны), так что скриптам такой тест не нужен.
Сравнивать руби и пхп имеет смысл, например, на пересечении/объединении массивов. Т.к. на больших нагрузках на сайт (когда серверов БД 5 штук, а бекендов с монгрелами/апачами - 100) иногда имеет смысл часть операций над данными вынести из БД в бекенды. Скажем, не делать LEFT JOIN, а двумя запросами получить списки айдишников и пересечь их в скрипте. Потому что бекендов в 20 раз больше, чем БД. А вот бинарные деревья пока БД обходит быстрее (в тех случаях, когда они нужны), так что скриптам такой тест не нужен.
Если оба языка не годятся для определенной задачи (обход Б-дерева, например), но один делает ее чуть быстрее — это не показатель. Показателей, вообще-то, два. Первый: один из языков можно использовать для задачи Икс, а второй - нельзя. Тут относительные отличия не так важны. Второй показатель: оба языка годятся для задачи Игрек и тут важны относительные значения.
А у нас ситуация какая - на Ваш взляд? :) Вы же сами знаете - с деревьями руби работает без проблем - REXML как пример (ну то есть конечно не совсем без проблем - но работает)
На счет тестов на пересечение/объединение массивов - полностью согласен - они в наборе тестов есть.
> ну то есть конечно не совсем без проблем - но работает
Я ни за что бы не стал пользоваться xml-парсером на чистом руби, если его элементарно можно прикрутить на Си без ущерба удобству разработки и деплоя. Если бы речь шла о ПХП, куда что-то кустомное прикрутить - нужно компилятор пересобирать, то я бы еще пять раз подумал.
Отсюда вывод: Руби на MRI - это не просто руби, а руби+Си, что существенно изменяет мое мнение о тестах. Возможности рубина отличаются от пхп в большей степени качественно, а не количественно, поэтому объективные численные тесты провести будет очень тяжело. Да и нужно ли? У нас например, те, кто любят пхп пишет на пхп, а кто любит руби - пишет на руби. Конечный результат все равно доставляет удовольствие всей команде и юзерам. А как к нему прийти - у каждого свой подход.
Я ни за что бы не стал пользоваться xml-парсером на чистом руби, если его элементарно можно прикрутить на Си без ущерба удобству разработки и деплоя. Если бы речь шла о ПХП, куда что-то кустомное прикрутить - нужно компилятор пересобирать, то я бы еще пять раз подумал.
Отсюда вывод: Руби на MRI - это не просто руби, а руби+Си, что существенно изменяет мое мнение о тестах. Возможности рубина отличаются от пхп в большей степени качественно, а не количественно, поэтому объективные численные тесты провести будет очень тяжело. Да и нужно ли? У нас например, те, кто любят пхп пишет на пхп, а кто любит руби - пишет на руби. Конечный результат все равно доставляет удовольствие всей команде и юзерам. А как к нему прийти - у каждого свой подход.
Я ни за что бы не стал пользоваться xml-парсером на чистом руби, если его элементарно можно прикрутить на Си без ущерба удобству разработки и деплоя.
Ну у нас с Вам разные идеологические подходы к разработке :) Мне больше нравиться возможность все реализовывать на Руби, а только потом, если есть проблемы думать чем это можно заменить.
(тот же REXML - несмотря на его репутацию, что он медленный и глючный - в прицепе работает вполне нормально - хотя конечно для генерации/разбора XML в промышленном масштабе не подойдет)
Отсюда вывод: Руби на MRI - это не просто руби, а руби+Си, что существенно изменяет мое мнение о тестах.
Конечно - но согласитесь использование С в Руби - не такая уж сильно распространенная практика (то есть - пользуются - но не сказать что бы все подряд, во всех случаях)
В данных тестах как раз и сравниваются языки как они есть - в чистом виде так сказать.
И я не говорю что эти тесты - это какая то бесконечная великая истина. Но кое что они показываю.
Я допустим уверен - сколько раз Вам приходилось сталкиваться с вещами типа "Да Руби интересный - но медленный, ужасно медленный - поэтому для практического применения непригоден".
Но ведь это не правда - этими тестами я и хотел это показать. А выбрал для сравнения PHP - потому что все "по умолчанию" сравнивают с PHP - как с самым распространенным языком web разработки (и кстати ничего против PHP лично не имею).
1) У меня есть код, который нужно было написать с нуля и который совершенно точно на руби пишется за 10 минут в 50 строк, а на Си - несколько часов и и длинно. Я его написал на руби чтобы было с чем работать до поры до времени, да и скорость не криминально низкая для тестов. Но парсер XML я писать руками не буду. И если выбирать между тем, какую либу прикручивать, я лучше потрачу 10 минут на то, чтоб написать минимально необходимый интерфейс к сишной либе, чем брать чисто руби-реализацию. Потому что тормоза буду чувствовать уже на тестах.
2) На распространенность мне вообще-то наплевать =) Совета спросить есть у кого, а сама связка вполне работоспособна. Зачем мне коммунити, если и так классно работает?
3) Про тесты это вы хорошо мысль разъяснили. Согласен с такой мотивацией, хотя это уже не чисто инженерная проблема (но тоже важная).
2) На распространенность мне вообще-то наплевать =) Совета спросить есть у кого, а сама связка вполне работоспособна. Зачем мне коммунити, если и так классно работает?
3) Про тесты это вы хорошо мысль разъяснили. Согласен с такой мотивацией, хотя это уже не чисто инженерная проблема (но тоже важная).
По-поводу скорости: надо кэшировать :-) И даже сильные тормоза часто перестают быть важны.
Если есть закэшированная HTML-строка, ее проще достать, чем генить заново, а C++, Ruby, PHP, Parser3, C# или .NET уже, как правило, все равно.
Если есть закэшированная HTML-строка, ее проще достать, чем генить заново, а C++, Ruby, PHP, Parser3, C# или .NET уже, как правило, все равно.
1) Я и говорю - разные идеологические подходы :) Вы большее внимание уделяете производительности, я сейчас - легкости изменения алгоритмов. Кстати вполне возможно что при решении другого типа задач я как раз буду придерживаться Вашего подхода. А Вы - моего :)
2) Я имел ввиду - для сравнения более правильно брать самые распространенные варианты - то есть чистый Руби и чистый PHP
3) Ага - это не чисто инженерная проблема - это больше проблема PR. И вот мне допустим коммюнити (см п.2) именно русскоязычного - не хватает :(
2) Я имел ввиду - для сравнения более правильно брать самые распространенные варианты - то есть чистый Руби и чистый PHP
3) Ага - это не чисто инженерная проблема - это больше проблема PR. И вот мне допустим коммюнити (см п.2) именно русскоязычного - не хватает :(
Всего лишь 15% ? А что так ма? :)
В руби замена цикла на perm = perm1.dup даёт примерно стократный прирост. Сколько это в процентах? :)
Да, кстати, пхп - это такой сильно ущербный веб-фреймворк. А руби, вроде бы, просто язык программирования. Хотя пхп-фанатики и про пхп говорят, что это типа "язык программирования". Ну. вот им на потеху и сравнение :)
В руби замена цикла на perm = perm1.dup даёт примерно стократный прирост. Сколько это в процентах? :)
Да, кстати, пхп - это такой сильно ущербный веб-фреймворк. А руби, вроде бы, просто язык программирования. Хотя пхп-фанатики и про пхп говорят, что это типа "язык программирования". Ну. вот им на потеху и сравнение :)
В чём ущербный, можно поинтересоваться?
Это язык программирования, "заточенный" под онлайн приложения.
Это язык программирования, "заточенный" под онлайн приложения.
Нет, конечно. Это "интерпретатор форм" персональных страничек. Шаблонизатор. Ущербный фреймворк. Ущербный, поскольку в настоящее время под фреймворком обычно подразумевают более высокоуровневые системы. Ну, низкоуровневый фреймворк, если угодно.
Язык программирования? Ну, на нём можно реализовывать некие алгоритмы. Да, в этом смысле язык программирования. Нелогичный, с отсутствующей концепцией. Язык программирования экстенсивного развития. Примерно как бейсик. Да, за 10 лет "бурного развития" пхп стал похож на язык программирования. В него упихали (довольно криво приспособив) огромную кучу где хороших, где не очень, "особенностей" из других языков.
"Язык программирования" предназначеный для разметки веб страничек, по-моему, называется веб-фреймворком. А поскольку до нормального современного фреймворка он не дотягивает, значит ущ.. низкоуровневый :).
Язык программирования? Ну, на нём можно реализовывать некие алгоритмы. Да, в этом смысле язык программирования. Нелогичный, с отсутствующей концепцией. Язык программирования экстенсивного развития. Примерно как бейсик. Да, за 10 лет "бурного развития" пхп стал похож на язык программирования. В него упихали (довольно криво приспособив) огромную кучу где хороших, где не очень, "особенностей" из других языков.
"Язык программирования" предназначеный для разметки веб страничек, по-моему, называется веб-фреймворком. А поскольку до нормального современного фреймворка он не дотягивает, значит ущ.. низкоуровневый :).
Для разметок веб-страничек использут HTML.
Может быть вам ознакомиться для начала с предметной областью, прежде чем высказывать свое компетентное мнение?
Может быть вам ознакомиться для начала с предметной областью, прежде чем высказывать свое компетентное мнение?
Интерпретатор форм персональных веб страничек. Что неясно? Потом постфикс -fi таки убрали :), но суть от этого не изменилась. Да это и по синтаксису видно - "программа" на пхп - это веб-страничка с включённым в неё скриптом. И ни как не иначе. Вот, скажем, JSP - это язык программирования? Вы, конечно, можете попробовать оформить пхп-файл как программу, она даже запустится, но работает оно всё при этом очень неочевидным образом :) - вы попробуйте, мы тут уже этим развлекались :)
ЗЫ. Да, я в курсе, что есть какие-то извращенцы, которые пытаются слабать пакет-менеджер для какой-то там сборки линукса на пхп. Но это ж извращенцы :). Цель их деятельности по-моему только в том, чтобы доказать, что пхп "не только" интерпретатор форм, но ещё и "язык программирования" на котором можно написать "даже" пакет менеджер. Ну, можно. Я слышал, что во времена оны на JCL(!) писали программы, игравшие мелодии на АЦПУ. Вот это были истинные самураи :)
ЗЫ. Да, я в курсе, что есть какие-то извращенцы, которые пытаются слабать пакет-менеджер для какой-то там сборки линукса на пхп. Но это ж извращенцы :). Цель их деятельности по-моему только в том, чтобы доказать, что пхп "не только" интерпретатор форм, но ещё и "язык программирования" на котором можно написать "даже" пакет менеджер. Ну, можно. Я слышал, что во времена оны на JCL(!) писали программы, игравшие мелодии на АЦПУ. Вот это были истинные самураи :)
Запустить нагрузочное тестирование RoR и Syfmony(к примеру) в стандартных конфигурациях и тогда уже можно что-то говорить. А так получается сравнение чей сферический конь сферичнее.
Я не понимаю, зачем вы стараетесь оптимизировать алгоритм теста?
А если к руби рельсы прицепить, тогда каков результат будет? Все-таки сайтов, написанных на "чистом" пхп достаточно, а из того, что я видел на руби — 90% рельсы.
Если к руби рельсы прицепить тогда нужно будет сравнивать Ruby + Rails vs PHP + Symphony (допустим - тоже не быстрый фреимворк)
Рельсы вообще сами по себе - вещь не самая быстрая и очень требовательная к ресурсам - тут скрывать нечего.
Но вот то что сайтов на руби без рельсов нет - есть, не так много, но есть - и достаточно известные.
К тому же для руби и других фреимворков достаточно -и к ним сейчас наблюдается подъем интереса - они в большинства своем значительно быстрее рельс.
Рельсы вообще сами по себе - вещь не самая быстрая и очень требовательная к ресурсам - тут скрывать нечего.
Но вот то что сайтов на руби без рельсов нет - есть, не так много, но есть - и достаточно известные.
К тому же для руби и других фреимворков достаточно -и к ним сейчас наблюдается подъем интереса - они в большинства своем значительно быстрее рельс.
А я и не говорю, что руби без рельс не бывает, а на пхп все без фреймворков пишут. Просто, как мне видится, средний_сайт_на_пхп существенно быстрее среднего_сайта_на_руби как раз из-за фреймворков.
За всех говорить не надо. Почти любой крупный сайт это фреймворк. Не всегда мвцшный не всегда известный, но фреймворк.
Смотря что считать средним сайтом :)
Сайт с 10-15 страничками с текстом и новостями, берущимися из БД и формой отправки на мыло - написанный на чистом PHP будет значительно быстрее чем такой же - но написанный на Ruby on Rails (да и вообще применять рельсы, а не чистый руби, в этом случае - глупость).
А вот допустим большой интернет магазин написанный на Bitrix (еще и с какими ни будь самописными модулями :) - будет ли быстрее такого же магазина, но написанного на Rails? Скорее всего нет - сильно зависит от обстоятельст.
Сайт с 10-15 страничками с текстом и новостями, берущимися из БД и формой отправки на мыло - написанный на чистом PHP будет значительно быстрее чем такой же - но написанный на Ruby on Rails (да и вообще применять рельсы, а не чистый руби, в этом случае - глупость).
А вот допустим большой интернет магазин написанный на Bitrix (еще и с какими ни будь самописными модулями :) - будет ли быстрее такого же магазина, но написанного на Rails? Скорее всего нет - сильно зависит от обстоятельст.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Есть еще Merb, альтернатива rails actionpack, который в базовом варианте работает на 20-30% быстрее рельсы, а в связке с evented mongrel и в многопоточном режиме может дать прирост и о 100% (многое зависит от логики приложения, нагруженности базы и стратегии кеширования).
НЛО прилетело и опубликовало эту надпись здесь
И в принципе, там особо не разгуляешься, так что разница в производительности интерпретаторов PHP & Ruby всегда будет минимальна и никак это не поменяется.
И тем не мение - разница в производительности между PHP/Perl/Python/Ruby все же многими учитывается при выборе языка разработки.
Вообще да - когда выйдет Ruby 2.0 с компиляцией в байткод - будет уже совсем другая ситуация :)
Но вот на счет этого -
Но за динамическую структуру всё же приходится платить и тяжёлые вещи переписывать на той же Java
тяжелые вещи при работе с руби уже сейчас переписвают на С - и замечательно работают (и без Scala :)
НЛО прилетело и опубликовало эту надпись здесь
У Scala есть интересная вешь - встроенная Акторная модель.
Все остальное есть и в Руби :)
И для руби можно писать все на руби - но пока есть проблемы с производительностью. просмотрим - во 2 версии вполне возможно у руби будет все так же хорошо как у Java ^_^
Все остальное есть и в Руби :)
И для руби можно писать все на руби - но пока есть проблемы с производительностью. просмотрим - во 2 версии вполне возможно у руби будет все так же хорошо как у Java ^_^
НЛО прилетело и опубликовало эту надпись здесь
performance - о.к. понятно
а с tools что?
а с tools что?
НЛО прилетело и опубликовало эту надпись здесь
Стоп стоп стоп :)
Это например какой анализ кода можно провести только в стат. тип. языках, а в динам. тип. нельзя?
Это например какой анализ кода можно провести только в стат. тип. языках, а в динам. тип. нельзя?
НЛО прилетело и опубликовало эту надпись здесь
А давайте не путать две разные вещи - то, что пока не реализовано, и то что не может быть реализовано в принципе.
Code Inspections в IDEA реализован для Java а не для Scala - разве нет (несмотря на ее стат. тип)?
Code Inspections в IDEA реализован для Java а не для Scala - разве нет (несмотря на ее стат. тип)?
НЛО прилетело и опубликовало эту надпись здесь
Я с IDEA не работал - не могли бы Вы хотя бы в общих чертах перечислить - что же там такого в анализе кода невозможного для реализации?
Встречный вопрос - NetBeans IDE 6.0 Ruby Pack пробовали? Там и анализ кода (в некотором виде )есть и рефакторинг (тоже в некотором виде :)
Встречный вопрос - NetBeans IDE 6.0 Ruby Pack пробовали? Там и анализ кода (в некотором виде )есть и рефакторинг (тоже в некотором виде :)
НЛО прилетело и опубликовало эту надпись здесь
Ну и большая часть из того что есть у IDEA уже есть и у NetBeans - только докрутить надо.
Не надо сомневаться - первая бета NetBeans 6 где то всего месяц назад вышла - почему они вдруг развитие прекратят? Я регулярно обновляюсь до новых релизов - и новые функции постоянно добавляются.
И это если говорить о NetBeans. А вот вышал недели две назад 3rdRail - так там уже и остальные функции IDEA реализованы - например Analyzing Code Dependencies. Так что никаких проблем с tools у руби скоро вообще не будет.
но я как-то сомневаюсь, что будет что-то ещё.
Не надо сомневаться - первая бета NetBeans 6 где то всего месяц назад вышла - почему они вдруг развитие прекратят? Я регулярно обновляюсь до новых релизов - и новые функции постоянно добавляются.
И это если говорить о NetBeans. А вот вышал недели две назад 3rdRail - так там уже и остальные функции IDEA реализованы - например Analyzing Code Dependencies. Так что никаких проблем с tools у руби скоро вообще не будет.
НЛО прилетело и опубликовало эту надпись здесь
Ну на счет IDE для работы с Java я конечно советовать не возьмусь :)- но вот на счет Руби многие многие требования NetBeans замечательно закрывает.
А на счет того, что тулы будут поскромнее - так при том, то Java сейчас практически стандарт пром програмирования, и поддерживается монстрами софт разработки, тулы для всех языков будут еше долго "немного поскромнее".
Только на Scala это не распространяется - возвращаясь к теме :)
А на счет того, что тулы будут поскромнее - так при том, то Java сейчас практически стандарт пром програмирования, и поддерживается монстрами софт разработки, тулы для всех языков будут еше долго "немного поскромнее".
Только на Scala это не распространяется - возвращаясь к теме :)
Возможно, вы не в курсе, но автоматизированный рефакторинг пришёл из Smalltalk, который очень даже динамически типизированный. Причём он там очень даже навороченный, хотя кое в чём и отличающийся от инструментов для той же Java - просто в силу того, что для динамически типизированных языков вообще отличаются некоторые базовые рефакторинги, и не важно, автоматизированный рефакторинг или ручной.
НЛО прилетело и опубликовало эту надпись здесь
Как мне нравятся эти разговоры про "статическая типизация" => "features" =) Эта стрелочка существует лишь из-за того, что кому-то лень чуть-чуть больше подумать и сделать такую же для динамического языка. Потому что есть, как минимум, соглашения, согласно которым 99% кода анализируются машиной без проблем.
Во-вторых, все крутые штуки, какие придуманы в IDEA, — это жуткая rocket science, отвлеченная от существа решаемой задачи. Я программировал на Си, плюсах, джаве, руби в простом текстовом редакторе SciTE с подсветкой лексики (сейчас - TextMate). Рефакторинг делал руками и лишь иногда нужно было сделать автозамену по нескольким файлам с регэкспами. Но необходимости в дотошных пунктах типа replace && with || никогда не было.
Не говоря уже о том, что в рубийном приложении кода меньше на порядок, что этот самый ручной рефакторинг существенно облегчает.
Disclaimer: идеальный интерфейс к структурированному текстовому процессору по моему мнению — Wolfram Mathematica, а не Latex-системы, MS Word, Apple Pages, MatLab или Mathcad. Если вы считаете по-другому, то можно и не спорить: это дело личной гигиены, чем себе мозги забивать =)
Во-вторых, все крутые штуки, какие придуманы в IDEA, — это жуткая rocket science, отвлеченная от существа решаемой задачи. Я программировал на Си, плюсах, джаве, руби в простом текстовом редакторе SciTE с подсветкой лексики (сейчас - TextMate). Рефакторинг делал руками и лишь иногда нужно было сделать автозамену по нескольким файлам с регэкспами. Но необходимости в дотошных пунктах типа replace && with || никогда не было.
Не говоря уже о том, что в рубийном приложении кода меньше на порядок, что этот самый ручной рефакторинг существенно облегчает.
Disclaimer: идеальный интерфейс к структурированному текстовому процессору по моему мнению — Wolfram Mathematica, а не Latex-системы, MS Word, Apple Pages, MatLab или Mathcad. Если вы считаете по-другому, то можно и не спорить: это дело личной гигиены, чем себе мозги забивать =)
Слишком радикально - это джава. Когда у вас платформа - Линукс, nginx, mongrel, memcached, гораздо веселее работать с Си или плюсами, без всяких параллельных вселенных типа Джавы.
Уточню: для меня Джава-платформа вместо Си — это как винда вместо линукса на сервере. Т.е. что-то работающее и популярное, но со своими правилами, отклоняющимися от классических и повсеместно признанных. Понятно, что те, кто работает с Джавой много и долго, таких проблем не испытывает. Но если это не так, то выпрыгивание из ПХП/Руби в Си, на мой взгляд, более перспективно, чем в Джаву (в плане гибкости).
Про AST все правильно. Далеко не уедешь. Про JVM тоже все правильно. Некоторые считают, что Си++ более медленный, чем Си. Что за бред? Не используйте виртуальные методы и скорость будет как и в Си.
А про Си vs. Асм вообще смешно бывает. Некоторые не в курсе, что Си, грубо говоря, — макросы для Асма: любой си-код можно в уме перевести в машинные коды и убедиться, что на асме в 99% случаев вы написали бы те же самые команды.
А про Си vs. Асм вообще смешно бывает. Некоторые не в курсе, что Си, грубо говоря, — макросы для Асма: любой си-код можно в уме перевести в машинные коды и убедиться, что на асме в 99% случаев вы написали бы те же самые команды.
Хех. Командочки-то там будут заметно другие. Причём переводить запись на C в ассемблер "влёт", то результат будет хуже, чем то что порождает компилятор - а "вылизывать" миллионы строк кода до последнего такта не будешь (к моменту когда всё будет вылизано процессор, под который всё затачивалось, уже будет недоступен, так что придётся начинать всё сначала).
То же самое - с C++: шаблоны позволяют написать такой код, который ты на C писать просто НЕ БУДЕШЬ - и тоже зачастую выиграть время. Что же касается виртуальных функций - то если они таки реально нужны, то вызовы будут в C'шной версии идти через таблицу - и скорость будет та же!
Единственная проблема с C++ - это то, что его любители зачастую пишут "сильно объектный" код, который любители C никогда в жизни не породят - но это не проблема языка...
То же самое - с C++: шаблоны позволяют написать такой код, который ты на C писать просто НЕ БУДЕШЬ - и тоже зачастую выиграть время. Что же касается виртуальных функций - то если они таки реально нужны, то вызовы будут в C'шной версии идти через таблицу - и скорость будет та же!
Единственная проблема с C++ - это то, что его любители зачастую пишут "сильно объектный" код, который любители C никогда в жизни не породят - но это не проблема языка...
НЛО прилетело и опубликовало эту надпись здесь
Что за люди. Новость хорошая, думал какие-нибудь подробности в коментах почитаю.
А тут программисты пишущие на разных языках в друг друга какашками кидаются. :(
А тут программисты пишущие на разных языках в друг друга какашками кидаются. :(
Предлагаю чисто для интереса сравнить с Python и впасть в депресняк)
Ну и вообще, как заметил кто-то, на то они и разные языки программирования, что имеют свои фишки, а когда в тестах построчно (аки тупо) перетаскивают код из одного языка в другой... глупо кароче.
Ну и вообще, как заметил кто-то, на то они и разные языки программирования, что имеют свои фишки, а когда в тестах построчно (аки тупо) перетаскивают код из одного языка в другой... глупо кароче.
Продолжение
А тот тест, про который мы говорим - он не на перебор цифр? Я же говорю - оптимизируйте и отправьте тестировщикам - все только рады будут.
А вот тест на рекурсию допустим - то же что то не то с ним? То же не подходит? :)
А тот тест, про который мы говорим - он не на перебор цифр? Я же говорю - оптимизируйте и отправьте тестировщикам - все только рады будут.
А вот тест на рекурсию допустим - то же что то не то с ним? То же не подходит? :)
Подходят, подходят )
Они подходят для того, чтобы оценить скорость доступа к элементам массива в цикле for. Ну или рекурсивного вызова. Но не подходят для оценки общей производительности языка в его предметной области.
Для того же перебора цифр, можно даже не просто копирование заменить, а использовать встроенные функции работы с массивами.
Это главный недостаток подобных языков - они не могут сколько-нибудь далеко уйти от набора встроенных функций, без значительной потери эффективности.
И эффективность языка во многом определяется именно набором этих самых функций и то, на сколько правильно он ложится на предметную область. Спорить об абстрактном удобстве синтаксиса и абстрактном быстродействии базовых конструкций в отрыве от набора предопределенных средств здесь не совсем корректно.
Вообще в большинстве случаев большинство времени едят запросы к базам и увеличение скорости цикла for, здесь вряд ли поможет.
Они подходят для того, чтобы оценить скорость доступа к элементам массива в цикле for. Ну или рекурсивного вызова. Но не подходят для оценки общей производительности языка в его предметной области.
Для того же перебора цифр, можно даже не просто копирование заменить, а использовать встроенные функции работы с массивами.
Это главный недостаток подобных языков - они не могут сколько-нибудь далеко уйти от набора встроенных функций, без значительной потери эффективности.
И эффективность языка во многом определяется именно набором этих самых функций и то, на сколько правильно он ложится на предметную область. Спорить об абстрактном удобстве синтаксиса и абстрактном быстродействии базовых конструкций в отрыве от набора предопределенных средств здесь не совсем корректно.
Вообще в большинстве случаев большинство времени едят запросы к базам и увеличение скорости цикла for, здесь вряд ли поможет.
Они подходят для того, чтобы оценить скорость доступа к элементам массива в цикле for. Ну или рекурсивного вызова. Но не подходят для оценки общей производительности языка в его предметной области.
Так что же это за предметная область такая - уже который раз пытаюсь выяснить - где скорость работы циклов/массивов/рекурсий не имеет значение? А что тогда имеет значение? С учетом того, что скорость доступа к БД определяется в большинстве случаев особенностями самой БД и драйверов к ней.
Это главный недостаток подобных языков - они не могут сколько-нибудь далеко уйти от набора встроенных функций, без значительной потери эффективности.И эффективность языка во многом определяется именно набором этих самых функций и то, на сколько правильно он ложится на предметную область. Спорить об абстрактном удобстве синтаксиса и абстрактном быстродействии базовых конструкций в отрыве от набора предопределенных средств здесь не совсем корректно.
А вот Вам кстати и отличее Руби от PHP (или допустим перла)
Часть интерпретатора Руби написана на самом Руби - все классы в Руби открытые - то есть добавить в класс массивов свой метод вообще и составляет проблем - и на производительности это не скажется (так как часть базовых классов уже изначально на руби и написана )
А PHP закрытый чтоли? :)
С учетом того, что скорость доступа к БД определяется в большинстве случаев особенностями самой БД и драйверов к ней.
Да, поэтому разница в скоростях м/у подобными языками уже не несет той остроты, которая была, например, м/у C и паскалем. Гораздо важнее удобство и т.п.
Так что же это за предметная область такая - уже который раз пытаюсь выяснить - где скорость работы циклов/массивов/рекурсий не имеет значение?
Имеет, но не главенствующее. Повторяю, опреации с массивами в PHP в большинстве случаев делаются с помощью встроенных функций работы с массивами. Если в интерпретируемом языке нужна сложная обработка структур, для которой нет набора встроенных средств и её нужно делать вручную на уровне базовых конструкций языка, то такой язык вряд ли подойдет для данной задачи. Так что в данных языках важен набор этих самых встроенных средств и его соответствие задачам решаемым в области данного языка.
Да, поэтому разница в скоростях м/у подобными языками уже не несет той остроты, которая была, например, м/у C и паскалем. Гораздо важнее удобство и т.п.
Согласен.
Так что в данных языках важен набор этих самых встроенных средств и его соответствие задачам решаемым в области данного языка.
То есть Вы имеете ввиду - нужно сравнивать удобство языка для решения какой либо задачи? Конечно - но только как сравнивать? Это уже все переходить в область вкусов и привычек разработчика - что то ему нравиться что то нет - а кому то наоборот. Сам предмет сравнения исчезает.
Для решения круга задач. И одного/двух тестов здесь не придумать.
Вот взять сайт среднего уровня написанный на PHP (нормальный сайт, а не Nuke какой-нибудь) и примерно такой же на Ruby, тогда можно сравнивать скорость работы и скорость разработки.
Вот взять сайт среднего уровня написанный на PHP (нормальный сайт, а не Nuke какой-нибудь) и примерно такой же на Ruby, тогда можно сравнивать скорость работы и скорость разработки.
Для решения круга задач. И одного/двух тестов здесь не придумать.
Вот взять сайт среднего уровня написанный на PHP (нормальный сайт, а не Nuke какой-нибудь) и примерно такой же на Ruby, тогда можно сравнивать скорость работы и скорость разработки.
Сделать одинаковым по функциональности можно - а как исключить фактор влияния хороших/плохих способностей разработчика?
Часть интерпретатора Руби написана на самом Руби - все классы в Руби открытые
И как это сказывается на производительности?
все классы в Руби открытые - то есть добавить в класс массивов свой метод вообще и составляет проблем
Да, эта фишка достаточно распространена в последнее время во многих языках. К сожалению, нужно признать, в PHP в полной мере её нет.
И как это сказывается на производительности?
Тесты я привел :))) (То есть - конечно - если бы весь интерпретатор Руби был написан на С и скомпилирован - Руби бы работал быстрее - но лишился бы некоторых важных вещей)
Да, эта фишка достаточно распространена в последнее время во многих языках. К сожалению, нужно признать, в PHP в полной мере её нет.
В такой мере как это есть в Руби, это было только в Smalltalk (если брать достаточно распространенные языки)
Я не слишком хорошо знаком с руби, но дополнять и изменять функциональность существующих типов можно JS (хотя там не совсем типы) и, насколько знаю, в Питоне.
В JS, кстати, сами нативные функции изначально сишные, но можно дополнять своими, написанными, на JS.
В JS, кстати, сами нативные функции изначально сишные, но можно дополнять своими, написанными, на JS.
Ну, Javascript (точнее, ECMAScript) - вообще очень интересный язык. Полностью объектный, прототипный, расширяемый - конфетка.
В Питоне на сколько я знаю не возможности изменять встроенные классы - строки, числа, списки и т.д.(и это один из тех факторов из за которых он быстрее Руби)
JS вообще другая объектная модель - он в этом вообще отличается от ООП языков.
JS вообще другая объектная модель - он в этом вообще отличается от ООП языков.
НЛО прилетело и опубликовало эту надпись здесь
Ну прямо на все 100% ? :) Ядро интерпретатора написано на С (но только ядро)- а вот все стандартные библиотеки написаны на самом Руби - и достаточно важные причем: класс CGI весь написан на Руби, ERB - весь написан на Руби, NET/HTTP, NET/FTP - тут можно многое чего перечислить (даже блин матрицы, комплексные и рациональные числа - и те на руби реализованы :(
И если уйти от тестов к реальной жизни - на сколько много производительности от RoR отнимает именно такая (на самом руби) реализация CGI и ERB?
И конечно - скорость работы связанно не сколько с открытостью классов (хотя нельзя отрицать, что допустим Питон из за того, что встроенные классы не позволяет расширять получает некое преимущество в скорости) - а с особенность реализации стандартных библиотек. И я уверен - если бы весь интерпретатор переписать на С - заменив ВСЕ что есть на руби - скорость была бы на много больше.
И если уйти от тестов к реальной жизни - на сколько много производительности от RoR отнимает именно такая (на самом руби) реализация CGI и ERB?
И конечно - скорость работы связанно не сколько с открытостью классов (хотя нельзя отрицать, что допустим Питон из за того, что встроенные классы не позволяет расширять получает некое преимущество в скорости) - а с особенность реализации стандартных библиотек. И я уверен - если бы весь интерпретатор переписать на С - заменив ВСЕ что есть на руби - скорость была бы на много больше.
не говоря даже о PHP (где весь интерпретатор скомпилирован в один файл - посмотрел бы я какая бы скорость у PHP бы была если бы половина стандартных функций шла дополнительной библиотекой на типа PEAR), даже Питон все что может в байт код компилирует - и только потом использует
Я себе слабо представляю как можно сравнивать языки в предметной области.
Предметная область - часть реального мира, рассматриваемая в пределах данного контекста. А теперь представте себе контекст тривиальной задачи на создание веб сайта.
Мы имеем такую совокупность разнообразных внутренних переменных среды, а также независимых от этой среды внешних параметров, что становится понятно - определить "предметную область" для приемлимо объективного сравнения языков невозможно. Просто невозможно возпроизвести окружение.
Все-равно что сравнивать ТТХ мига, бабочки и боинга, в полете на высоте 10 км, при куче неизвестных - есть ли у бабочки твердотопливные ускорители, а у боинга система навигации.
Любое сравнение языков носит поверхностный характер - те насколько язык быстро справляется с типовыми операциями, которые наиболее часто используются. Объективно в "предметной области" можно сравнивать только скорость разных компиляторов одного языка, которые практически соответствуют стандарту какого-либо языка.
Предметная область - часть реального мира, рассматриваемая в пределах данного контекста. А теперь представте себе контекст тривиальной задачи на создание веб сайта.
Мы имеем такую совокупность разнообразных внутренних переменных среды, а также независимых от этой среды внешних параметров, что становится понятно - определить "предметную область" для приемлимо объективного сравнения языков невозможно. Просто невозможно возпроизвести окружение.
Все-равно что сравнивать ТТХ мига, бабочки и боинга, в полете на высоте 10 км, при куче неизвестных - есть ли у бабочки твердотопливные ускорители, а у боинга система навигации.
Любое сравнение языков носит поверхностный характер - те насколько язык быстро справляется с типовыми операциями, которые наиболее часто используются. Объективно в "предметной области" можно сравнивать только скорость разных компиляторов одного языка, которые практически соответствуют стандарту какого-либо языка.
До питона далекоооо.
хм... все это лирика...
вот что главное!
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=fbasic
вот что главное!
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=yarv&lang2=fbasic
Тесты забавные, но есть один ньюанс. В тестах реализовывается определённые задачи с каким-то алгоритмом, не оптимизированным под конкретный язык. Меня мучает вопрос: а зачем такое делать? Каждый язык имеет свой функционал и свои узкие места. Если уже делать тесты, то решать задачи, поставленные в них с полной/частичной оптимизацией алгоритма.
Другими словами, медленный алгоритм можно написать на чём угодно, а затем сравнивать его работу. А смысл тогда в чём?
Другими словами, медленный алгоритм можно написать на чём угодно, а затем сравнивать его работу. А смысл тогда в чём?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ruby медленнее PHP? Уже нет!