Бенчмарк объектный Фибоначчи. Часть 3-я.

sqrt(Ъ)

Корень квадратный от Ъ? Что-то новенькое :)

весёлым пятничным взглядом подиагонали - тесты несовсем корректны. В некоторых случаях (без gc, тот-же с++ сливший d) в измерения входили пообъектные деструкторы/финализеры, в некоторых нет.

Честные правила будут или как в прошлом тесте - неудобные варианты не принимаются?

https://github.com/Balancer/benchmarks-fib-obj
При чём

face palm

Объекты не нужны, только ФП, только хас хардкор.

Это тест на скорость создания новых объектов или на скорость расчёта фибоначчи?

Если второе, то, например, в окамле (другие тесты пока не смотрел) используется вспомогательная функция-аккумулятор для хвостовой рекурсии. Иначе не дожидаясь результата можно сказать, что будет тормозить :)

А; ясно, прочитал-таки ридми; вопрос снимается :)

а где fantom на .NET и JS? и вообще ни C# ни JavaScript нет в тестах, непорядок.

KRoN73, тут товарищ просит добавить тестик для Go.

http://paste.ubuntu.com/6258900/
Только тестить надо на Go 1.1.2
Не ниже

Добавь еще тест для случая C++ heap tcmalloc.

g++ -O3 heap.cpp -l tcmalloc_minimal

У меня получилась на этой задаче разница в 25%.

или как в прошлом тесте - неудобные варианты не принимаются?

Это какие? Я помню только пару случаев, когда предлагался не объектный тест.

а где fantom на .NET и JS?

Не смог найти, как запустить тест под ними.

версия руби старая
ruby 1.9.3 - 1m54s
ruby 2.0.0 - 1m35s

JS

node.js ли мб это http://phantomjs.org/

тут товарищ просит добавить тестик для Go

Добавил. Вышло 0.888 (при чём очень стабильно).

Только тестить надо на Go 1.1.2

Нашёл PPA только максимум с 1.1.1 (а «родной» под Raring, вообще 1.0.x), но результат корректный получился.

g++ -O3 heap.cpp -l tcmalloc_minimal
У меня получилась на этой задаче разница в 25%.

Поставил libtcmalloc-minimal4

Но G++ почему-то собирать отказывается:

/usr/bin/ld: cannot find -ltcmalloc_minimal
collect2: ошибка: выполнение ld завершилось с кодом возврата 1

версия руби старая

Зато основная :) Пока ломать систему версией 2.0 не хочется, тем более, что результат, судя по всему, сильно не изменится и на общую расстановку никак не повлияет.

Или он под Ubuntu есть в виде отдельного пакета, не ломающего остальные зависимости?

Если второе, то, например, в окамле (другие тесты пока не смотрел) используется вспомогательная функция-аккумулятор для хвостовой рекурсии.

Можно ещё быстрее, за логарифмическое время.

node.js ли мб это http://phantomjs.org/

А, я так понял, что вопрос именно о Fan под .NET/JS.

Если речь о платформах, то C# добавил.

Но какая-то ерунда как со временем работы (вышло медленнее, чем на тесте 5-летней давности на куда более тормозной машине, так и со временем вычисления — оно в колеблется около 15.5..17.0 сек, в то же время, как были выбросы в 14 и 12.3 сек.

Судя по всему, 5 лет назад я бинарник собирал компилятором от MS (msc — это ж оно?) и, видимо, он много эффективнее, чем gmcs. Или я не допёр, что там кроме --optimize+ можно указать.

Надо будет попробовать под Windows тест собрать.

Можно ещё быстрее, за логарифмическое время.

Можно за фиксированное время — через гамма-функцию :)

(каждый раз эта тема поднимается…)

Да, кстати (копипаст с форуме).

За прошедшие годы есть интересные изменения.

— Java и Scala стали быстрее. Уже не в 5 раз медленнее, чем С++ с объектами на стеке, а только вдвое.

— Scala сравнялась по скорости с Java, догнал их и Fantom

— Ruby ещё прибавил в скорости, от C++ с кучей отстаёт не в 13-18 раз, а в 8.

— Ruby уверенно обошёл Python.

Можно за фиксированное время — через гамма-функцию :)

Каким образом, простите?

Каким образом, простите?

По формуле Бине. Правда, пардон, фиксированного времени там не будет. Всё равно возведение в степень считать придётся. Так что для больших N, наверное, логарифмическое время и получится.

JRuby сделал офигенный скачок. Он теперь работает быстрее оригинального Ruby (даже с прогнозом для 2.0.0 на моей машине). А раньше был неимоверным тормозом, уступающим только PHP.

По формуле Бине. Правда, пардон, фиксированного времени там не будет.

Угу, только там и гамма-функция ровно так же не причём.

face palm

Fixed

Угу, только там и гамма-функция ровно так же не причём.

Да, точно. 90° — это прямой угол. Там золотое сечение фигурирует :) А у меня в голове оно причудливо отложилось в вычисление гамма-функции.

Надо будет попробовать под Windows тест собрать.

Собрал. Нифига не изменилось. Судя по всему, это у mono такая деградация сильная.

эмм ....
http://ru.wikipedia.org/wiki/Числа_Фибоначчи

http://oeis.org/A000045

Fibonacci numbers: F(n) = F(n-1) + F(n-2)
и это просто закодировано в лобешник как целые числа номеров мест, а не их значения ...
мало того, на представление чисел:
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368, 75025, 121393, 196418, 317811, 514229, 832040, 1346269, 2178309, 3524578, 5702887, 9227465, 14930352, 24157817, 39088169
отводится int
...
no comment ...

fpc (free pascal compiler) не хватает

PyPy бы затестить...

А где pypy?

xdebug

*facepalm*

И «голого» Mono/C#

C++11:

~$ cat 1.cpp
#include <stdio.h>

class Fib
{
     int _value;

  public:
    constexpr Fib(int n) : _value( n ) {}

    constexpr int value() const
    {
        return _value <= 2 ?
            1 :
            Fib(_value - 1).value() + Fib(_value - 2).value();
    }
};

int main()
{
    for(int i=0; i<10; i++)
    {
        constexpr int value = Fib(40).value();

        printf("n=%d\n", value);
    }
}
~$ g++ -std=c++11 -Ofast 1.cpp
~$ time ./a.out 
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155
n=102334155

real	0m0.001s
user	0m0.000s
sys	0m0.001s

ну и даже те варианты, что есть, стоит пересобрать с -Ofast, а не -O3

и для полной картины не хватает CL с CLOS

А CLOS тебе тут зачем?

«Бенчмарк объектный»

да какие это числа Фибоначчи ? ))
хрень какую-то считают ...
«полная картина» )

на моём q6600 на 1600Mhz

c++ stack - 0m5.730s
c++ boost - 0m14.544s
c++ heap  - 0m31.013s
perl(5.18) Can't return outside a subroutine at fib_perl.pm line 31.
python3  - 6m30.552s
и внимание: C++11: - 0m0.003s

меряют производительность ОП, задача хоть и не самая удачная выбрана, но зато под нее есть уже решения на разных ЯП, лучше чем ничего

хм ...
нет понятухи в постановке алгоритмов
и размерности промежуточных значений, но зато, вах, какой ооп ... и все что- считают не в зуб ногой в смысле всего действа ...
смешно же ))

ну смейся в сторонке, никто не запрещает

и все что- считают

--> и все что-то там считают себе ...

~$ time g++ -std=c++11 -Ofast 1.cpp

real	0m0.040s
user	0m0.039s
sys	0m0.002s
~$ time gdc -Ofast a.d

real	0m0.981s
user	0m0.932s
sys	0m0.047s

LOL, а Александреску распинался, как у него программы на D быстро собираются, и да - в варианте на С++ еще и все посчиталось в compile time, а в варианте на D - нет :(, хотя опять же - тут на ЛОР распинались какой D умный, умеет сам CTE, без всяких хинтов

~$ time g++ -std=c++11 -O0 1.cpp

real	0m0.044s
user	0m0.028s
sys	0m0.017s
~$ time gdc -O0 a.d

real	0m0.398s
user	0m0.359s
sys	0m0.039s

без оптимизации, если кому надо

fpc (free pascal compiler) не хватает

Пример давайте. А то я на Паскале никогда с объектами не работал. И, вообще, последнюю программу на нём писал 22 года назад.

PyPy бы затестить...

Добавил. Офигенно :)

xdebug
*facepalm*

Жесть. А раньше он при выключенном профилировании на скорость не влиял. Обновил результаты теста.

И «голого» Mono/C#

Этот ещё ночью добавлял. Только результаты странные. Походу, mono за прошедшие 5 лет сильно деградировал по скорости.