По предварительным тестам (http://macournoyer.wordpress.com/2008/09/02/ruby-on-v8/), JavaScript реализации языка Ruby (HotRuby (http://hotruby.yukoba.jp/)), запущенная внутри виртуальной машины Google V8 (http://code.google.com/apis/v8/), выполнила тестовое задание в 10 раз быстрее (операция заняла 0.987 сек.), чем при выполнении в стандартном Ruby 1.8.6 и 1.9.0 (тест был выполнен за 9.565 и 9.669 сек).
Более того, аналогичный тестовый код написанный на Си, был выполнен за 3.322 сек. После оптимизации Си кода тест был выполнен за 0.017 сек., но это лишний раз доказывает, то что написанный на скорую руку Си код часто выполняется медленнее, чем код написанный на интерпретируемом языке.V8 (http://code.google.com/apis/v8/) - написанная с нуля виртуальная JavaScript машина, открытой вчера компанией Google. Проект HotRuby (http://hotruby.yukoba.jp/) позволяет выполнять в браузере Ruby приложения, преобразованные в байткод, используя для компиляции YARV (Yet Another Ruby VM) из с...
URL: http://macournoyer.wordpress.com/2008/09/02/ruby-on-v8/
Новость: http://www.opennet.me/opennews/art.shtml?num=17703
>>Более того, аналогичный тестовый код написанный на Си, был выполнен за 3.322 сек.
>
>По-любому индусы писали.Вообще-то такое бывает. Бывало и в некоторых тестах Java vs C, например. И не из-за индусов вовсе, а потому, что при JIT-компиляции возможны некоторые дополнительные оптимизации, которые нельзя выполнить при AOT.
Но это был явно не тот случай.
>Вообще-то такое бывает. Бывало и в некоторых тестах Java vs C, например.Угу, только это случай когда исключения только подтверждают правило :).На тяжелых задачах, где скорость как раз и важна - у жабы и дотнета наблюдается традиционный слив в 2-3-4 раза сям.Вон например бенчи: http://quicklz.com/ - одно и то же сжатие на одной и той же машине (даже нескольких) забенчено в сишной, жабистой и дотнетовой версии.Результат заметен и предсказуем.
>но это лишний раз доказывает, то что написанный на скорую руку Си код часто выполняется медленнее,Задача сферическая. Ясное дело, что чуда не будет и конец строки будет каждый раз вычисляться поиском завершающего '\0'. Пофиксили и стало в раз в 40 быстрее v8.
>часто выполняется медленнее, чем код написанный на интерпретируемом языке.
И как один пример согласуется со словом "часто"? Интерпретируемый язык - только для скриптов.
>V8 - написанная с нуля виртуальная JavaScript машина, открытой вчера компанией Google.
Правильно, теперь веб и его т.н. браузеры - среда для бесконтрольного выполнения вредоносного ПО и дрм модулей.
Web - R.I.P.
> ...написанная с нуля виртуальная JavaScript машина, открытой вчера компанией Google.Можно перевести эту формулировку в нормальный общедоступный вид?
А то хочется сказать прямо как в известном mp3 "Слово из трёх букв" - "Я %%% чего понял..." xD
> Ясное дело, что чуда не будет и конец строки будет каждый раз вычисляться поиском завершающего '\0'.В некоторых языках программирования (например, BBC-basic) конец строкИ обозначается не нулевым символом, а записанной в определённом месте длиной строкИ (т.е. строка - это не массив, а более сложная структура). В частности, это позволяет включать в строку нулевой символ; ну и ускоряет некоторые операции, а также на операциях изменения строкИ нагружает дополнительной работой процессор (т.е. замедляет работу); и ещё позволяет контролировать выход за границу массива.
да ну, вы наверное врете все :)
>В некоторых языках программирования (например, BBC-basic) конец строкИ обозначается не нулевым символомРечь, вероятно, была про стандартные функции C, которым передаётся один указатель.
> а записанной в определённом месте длиной строкИ (т.е. строка - это не массив, а более сложная структура)
Это и сделали по ссылке, только на С.
Результат сомнительный.
В комментах:> The ruby version is slow code.
> By replacing += with <<, it becomes faster tens of times.
> And HotRuby is optimized for String += String.
Всё указывает на то, что JavaScript станет основным языком для web разработчиков.
>Всё указывает на то, что JavaScript станет основным языком для web разработчиков.У него на самом деле только 1 проблема :) он не стал популярным на server side.А так - JS вроде всегда и был одним из таковых средств.
>>Всё указывает на то, что JavaScript станет основным языком для web разработчиков.
>
>У него на самом деле только 1 проблема :) он не стал
>популярным на server side.А так - JS вроде всегда и был
>одним из таковых средств.Ну не совсем. flash, ActiveX, Java . JavaScript из-за тормознутости использовался как сервисный язык, для обработки больших объёмов данных его использовать до сих пор не получается.
>для обработки больших объёмов данных его использовать до сих
>пор не получается.А ему обычно и не надо большие объемы данных лопатить.Для черной работы есть например, БД, писанные отнюдь не на JS.Вот они перелопатить большой объем данных могут.Для того и созданы.Хотя тормозные скрипты все-равно никому не нужны - это верно.Но если уж Ruby слегка юзают местами некоторые, а его реализация на JS обгоняет обычный вариант - саму эту реализацию JS, очевидно, тоже можно заюзать ничуть не хуже тогда.Как минимум она будет не медленее :)))
>А ему обычно и не надо большие объемы данных лопатить.Для черной работыВот мне надо вывести на страницу 6000 строк из базы. JSON код JavaScript парсит 10-15 секунд, eval() за две управляется, но не секурно. На таких задачах проблемы со скоростью хорошо видны.
>Всё указывает на то, что JavaScript станет основным языком для web разработчиков.Не смешите меня. Поробуйте проверить являится ли в JS строка числом, да чтобы это работало во всех браузерах... Это до того неудобно решается в JS, что говорить о "основном" ЯП просто преждевременно... Что это за ЯП такой, что элементарные операции то работают, то не работают?
>>Всё указывает на то, что JavaScript станет основным языком для web разработчиков.
>
>Не смешите меня. Поробуйте проверить являится ли в JS строка числом, да
>чтобы это работало во всех браузерах... Это до того неудобно решается
>в JS, что говорить о "основном" ЯП просто преждевременно... Что это
>за ЯП такой, что элементарные операции то работают, то не работают?
>А Вы не пробовали ParseInt запустить, ParseFloat ? Или регулярное выражение? Где-то тут проблемы обнаружились?
>>>Всё указывает на то, что JavaScript станет основным языком для web разработчиков.
>>
>>Не смешите меня. Поробуйте проверить являится ли в JS строка числом, да
>>чтобы это работало во всех браузерах... Это до того неудобно решается
>>в JS, что говорить о "основном" ЯП просто преждевременно... Что это
>>за ЯП такой, что элементарные операции то работают, то не работают?
>>
>
>А Вы не пробовали ParseInt запустить, ParseFloat ? Или регулярное выражение? Где-то
>тут проблемы обнаружились?parseInt('1x11',10); что выдаст?
-----
function isNumber(src){
var res = '';
var re = /[0-9]+/g;
var arr = '';
var arr = re.exec(src);
if (arr != null) {
if (arr.size() == src.length) {
return true;
}
}
return false;
}
что выдаст если два раза подряд к одним и тем же данным вызвать?(в форме ОК два раза нажимаем к примеру)
>parseInt('1x11',10); что выдаст?ничего интересного не выдаст, как и масса случайных функций. А вот
function isInteger(a){
var b = parseInt(a,10);
if( a==b) return true;
return false;
}
выдаст. точно так же, как и выражение /^\-?\d+$/
>[оверквотинг удален]
> var arr = re.exec(src);
> if (arr != null) {
> if (arr.size() == src.length) {
> return true;
> }
> }
> return false;
>}
>что выдаст если два раза подряд к одним и тем же данным
>вызвать?(в форме ОК два раза нажимаем к примеру)Опять какая-то каша, замысел функции непонятен, что она вообще должна была делать? arr.size никакого отношения к src.length не имеет (и вообще что это за size()), arr.length тоже.
Я конечно извиняюсь, но делать такие далеко идущие выводы по тесту из 2 строчек - это надо постараться.
Мудрец по одной капле воды может заключить о существовании океана
> Мудрец по одной капле воды может заключить о существовании океанаА глупец примит одну каплю за океан.
То что JavaScript ускорили - молодца!Но вот сравнивать с Ruby - нечестно! Ряба - абсолюнтый тормоз, если ты можешь перекинуть байтик в секунду - ты уже еЯ быстрее :)
Было бы интересно получить JavaScript компилятор. В нативщину. От наличия такого тулса могло бы произойти много любопытного .... :)
>РябаЖесткий термин. Спасибо поржал (c)
>Было бы интересно получить JavaScript компилятор.
Черт, так и чешутся руки написать свой велос^W язык программирования. С но без совместимости с С, с поддержкой классов с жесткой типизацией и вообще без сборки мусора /механизма выделения ресурсов. Все это жестко завязать на драйвер режима яра, который будет разруливать (на уровне страниц) любые операции с памятью.
>это лишний раз доказывает, то что написанный на скорую руку Си код часто выполняется медленнее, чем код написанный на интерпретируемом языке.Это лишний раз доказывает, что современные программисты плевали на математику, разработку алгоритмов и оптимизацию. А зачем, если можно поставить более мощный процессор, добавить памяти. Да и зачем использовать языки программирования, которые требуют дополнительной внимательности от программиста, если можно писать на языках "высокого уровня".
респект. есть такое