Производительность языков. Объектный Фибоначчи :) (5/5) [Форумы Balancer.Ru]

старые » Наука и техника » Компьютерный » Программирование » Производительность языков. Объектный Фибоначчи :): Производительность языков. Объектный Фибоначчи :)

Теги:программирование, компьютеры, техника

Новый опрос Новый фотосет Новая тема Написать сообщение в тему

1 2 3 4 5

Balancer #21.09.2009 21:45 @waveM#21.09.2009 20:24

Balancer

администратор

★★★★★

waveM> Хмм, а почему тогда не рассматривается такой вариант на С++?

Потому что этого теста строго формально ещё нет

На ЛОРе, как раз, ищем слабые места. Уже ясно, что мой вариант не подходит, так как возникает неистребимое желание выкинуть из теста неиспользуемые операции

Вот и в твоём тесте нету обращений к уже имеющимся объектам в value()...

В общем, перепишу тест, чтобы не было желания сэкономить - выложу

grim #08.12.2010 05:25

grim

новичок

C# вариант со структурой. Примерно в 10 раз быстрее класса.

code text

using System;
class Fib
{
public static void Main()
{
Fib1 x = new Fib1(40);
Console.WriteLine(x.value());
}
}
internal struct Fib1
{
private int _value;
public Fib1(int n) { _value = n; }
public int value()
{
if (_value <= 2)
return 1;
Fib1 f1 = new Fib1(_value - 1);
Fib1 f2 = new Fib1(_value - 2);
return f1.value() + f2.value();
}
}

Да, и в java варианте применён хак - увеличение размера начального блока для классов, позволяющий не освобождать память до конца программы. Не знаю это корректно в рамках данного теста или нет. Тестируем ведь работу с объектами: создание/удаление. Или я не прав?

grim #08.12.2010 05:27 @grim#08.12.2010 05:25

grim

новичок

grim> Да, и в java варианте применён хак - увеличение размера начального блока для классов, позволяющий не освобождать память до конца программы. Не знаю это корректно в рамках данного теста или нет. Тестируем ведь работу с объектами: создание/удаление. Или я не прав?

Я имею в виду вариант "Java (server)"

Balancer #08.12.2010 09:25 @grim#08.12.2010 05:25

Balancer

администратор

★★★★★

grim> C# вариант со структурой.

Структуры в C#, разве, могут быть с наследованием?

Luchnik #08.12.2010 09:50 @Balancer#08.12.2010 09:25

Luchnik

аксакал

★☆

Balancer> Структуры в C#, разве, могут быть с наследованием?
Наследоваться от структур и других расширений System.ValueType - нельзя.

Видимо, вариант со структурой быстрее за счёт того, что создание экземпляров идёт в стеке, а не в куче. И за счёт упрощённого в сравнении с классами конструирования экземпляров.

Balancer #08.12.2010 10:02 @Luchnik#08.12.2010 09:50

Balancer

администратор

★★★★★

Luchnik> Наследоваться от структур и других расширений System.ValueType - нельзя.

Тогда вариант не катит

В следующей версии ещё обязательно пару-тройку наследований в глубину сделаю. Это тоже очень важный для оценки скорости параметр. У меня на PHP во фреймворке и то в среднем уровень наследования равен четырём, а часто - пяти

Правда, один уровень исторически сложился и его можно будет снести, но пока - так.

grim #09.12.2010 19:44 @Balancer#08.12.2010 10:02

grim

новичок

Balancer> Тогда вариант не катит

Ну, это не чесно

Применение структуры вместо класса иногда очень помогает ускорить участок программы.

Тогда уж давайте и работу со списками добавим и с дженериками и прочее.

Хотя по моему нужно оставить тест как есть. Он имел когда-то конкретную цель и если структуры её решают, вы предлагаете считать эту цель неправильно и изменить, только для того, чтобы выбить конкретную особенность языка?

Balancer #09.12.2010 19:47 @grim#09.12.2010 19:44

Balancer

администратор

★★★★★

grim> Ну, это не чесно

Так задача такая звучит

Оценить скорость полноценной работы с объектами. И наследование тут сегодня очень важный фактор.

grim> Применение структуры вместо класса иногда очень помогает ускорить участок программы.

Безусловно. Но это уже другая задача

grim> Тогда уж давайте и работу со списками добавим и с дженериками и прочее.

Как вариант. Но это будет уже третья задача.

grim> Хотя по моему нужно оставить тест как есть.

Поэтому его обновление будет идти уже в рамках нового теста

А старый продолжать смысла нет, так как уже нет того железа и ОС, чтобы тестирование шло в равных условиях.

Balancer [28.01.2011 11:18]: Перенос сообщений в Программистский юмор

Balancer #18.10.2013 17:29

Balancer

администратор

★★★★★

Реинкарнация теста в современных условиях

1. Все тесты лежат на GitHub: Balancer/benchmarks-fib-obj · GitHub

2. К каждому тесту прилагается скрипт, с которого получались результаты.

3. Сводная таблица с результатами выкладывается на GitHub Wiki: https://github.com/.../Результат-теста:-i3-2.2ГГц

В процессе пополнения.

За прошедшие годы есть интересные изменения.
— Java и Scala стали быстрее. Уже не в 5 раз медленнее, чем С++ с объектами на стеке, а только вдвое.
— Scala сравнялась по скорости с Java, догнал их и Fantom
— Ruby ещё прибавил в скорости, от C++ с кучей отстаёт не в 13-18 раз, а в 8.
— Ruby уверенно обошёл Python.

Продолжу тесты чуть позже. Также, поскольку оно на GitHub, желающие могут присоединяться

Balancer #19.10.2013 00:39

Balancer

администратор

★★★★★

Добавлены Go, C#/mono, JRuby.

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

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

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

Balancer #19.10.2013 01:03 @Balancer#19.10.2013 00:39

Balancer

администратор

★★★★★

Balancer> Судя по всему, 5 лет назад я бинарник собирал компилятором от MS (msc — это ж оно?)

Т.е. csc, наверное.

В общем, cобрал .net-exe-шник под Windows. Нифига не изменилось. Судя по всему, это у mono такая деградация сильная.

Nikita #19.10.2013 01:37 @Balancer#19.10.2013 00:39

Nikita

аксакал

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

Что csc, что gmcs строят IL-код. Там почти нет оптимизаций, и он тривиален в этом плане. За итоговую компиляцию в машинный код отвечают совсем другие компоненты.

Учитесь читать. 10.0

Balancer #19.10.2013 02:11 @Nikita#19.10.2013 01:37

Balancer

администратор

★★★★★

Значит, как и я подумал, mono так деградировал…

С другой стороны странно, .NET-exe-шник от Boo, работающий на том же mono, работает на треть быстрее. И в сравнении с C++/heap сохраняет примерно ту же скорость, что и раньше.

Balancer #19.10.2013 14:00

Balancer

администратор

★★★★★

Добавлены PyPy (офигенный результат 10.9 сек, на уровне хипового Си++) и C++11 (0.450 сек, между D(stack) и Fantom).

Кстати, что интересно, при явном указании константности, C++11 вычисляет результат ещё на этапе компиляции.

Это сообщение редактировалось 22.11.2013 в 02:48

Balancer #22.11.2013 02:47

Balancer

администратор

★★★★★

Добавлен результат для языка Dart. Получилось между C++ (boost) и D (heap). Тест получен как первый pull-request

Dart: Structured web apps

About 5 minutes Dart is class based and object oriented, without being dogmatic. About 1 hour Write a Dart web app, even if you've never written a web app before. About 1 day Dart has lots of tools, libraries, and documentation, plus a developer community. All modern browsers (both desktop and mobile) can run Dart web apps, thanks to our Dart-to-JavaScript compiler. You can probably already read and even write Dart code. See more samples. Write less. Say more. Add types to your code to help people and tools. // Дальше — www.dartlang.org

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

Тайминги на Ububtu 13.10 (система обновилась) изменились в связи с новыми версиями софта. PyPy стал процентов на 9 медленнее. Perl — на ~7% (результат чуть позже) тормознее. Python и Python3 стали быстрее на 8% и на 6%, соответственно.

Добавил также HipHop PHP. Скорость вышла почти как и у старого PHP5.4 (на 2% быстрее). Новый PHP5.5 ещё не тестировал.

Balancer #25.02.2015 04:16

Balancer

администратор

★★★★★

hhvm 3.5.x получился втрое быстрее, чем 2.x И сильно обошёл чистый PHP, лишь вдвое уступив C#

Пополнил таблицу на

Unicorn! · GitHub

We didn't receive a proper request from your browser. Sorry about that. Please try refreshing and contact us if the problem persists. // github.com

Jameson #01.04.2015 06:10 @Balancer#02.08.2008 22:06

Jameson

опытный

попробуйте еще ABCPascalNET. можно отдельно проверить opemnp.

я был в шоке. похоже фирма embarcadero испортила компилятор с паскаля. или они просто взяли free pascal компилятор. потмоу что елки. ABC паскаль для net может делать не менее а иногда и куда более шустрый код. кхм.

Balancer #28.03.2016 12:02

Balancer

администратор

★★★★★

Давно не обновлял цифры производительности в «Объектном Фибоначчи».

Balancer/benchmarks-fib-obj

benchmarks-fib-obj - Тесты «Объектный Фибоначчи» для разных языков. // github.com

PHP7 обошёл и Ruby, и Python. Но по-прежнему здорово проигрывает HHVM. Есть и другие, хоть и менее заметные перестановки. Думаю, надо выкроить пол-часика, изучить поверхностно Rust и слепить тест для него. На днях попробую пощупать.

Balancer #29.03.2016 09:50

Balancer

администратор

★★★★★

Вчера в голову пришла мысль измерить Rust. Заодно, решил посмотреть, что за язык получился

На знакомство с языком и написание теста ушло 15 минут, так что, возможно, его качество далеко от идеала. Потому тему и завёл, может, где-то грубо ляпнул. Я даже не знаю до сих пор, как дело в Rust со сборкой мусора обстоит и он эквивалент по этой классификации Java/C-хипового или C-стекового.

Вот мой первый вариант: https://github.com/Balancer/benchmarks-fib-obj/.../sources/rust/fib.rs

Получилось 0.603 сек., что почти вдвое хуже стекового Си (0.350) и немного лучше Java (0.685) со сборкой мусора.

Обновлённая таблица с результатами: https://github.com/.../Результат-теста:-i3-2.2ГГц

Balancer #18.01.2017 19:55

Balancer

администратор

★★★★★

Небольшое обновление теста.

Добавил JavaScript. Результат отличный — 2.64 сек. Почти как у Dart'а, лучше, чем у D. Похоже, сегодня это самый быстрый скриптовый язык.

Обновил:

PHP до 7.1.0. Стал чуть-чуть быстрее, 50.6 против 58.0 у t.0.13

HHVM практически не изменился. 24.5 против 25.0

Python до 3.5.2 и 2.7.12. Удивительно, но он стал ещё медленнее — 170 и 153 сек. против прежних 145/129.

alexsolo #22.01.2017 21:42 @Balancer#18.01.2017 19:55

alexsolo

новичок

Balancer> Небольшое обновление теста.

Добавьте моего тормоза.

code text

import time
fibs = {0: 0, 1: 1}
def fib(n):
if n in fibs: return fibs[n]
if n % 2 == 0:
fibs[n] = ((2 * fib((n / 2) - 1)) + fib(n / 2)) * fib(n / 2)
return fibs[n]
else:
fibs[n] = (fib((n - 1) / 2) ** 2) + (fib((n+1) / 2) ** 2)
return fibs[n]
s = time.time()
fib(100000)
print("Time (s): %f" % (time.time() - s))

Balancer #22.01.2017 21:50 @alexsolo#22.01.2017 21:42

Balancer

администратор

★★★★★

alexsolo> Добавьте моего тормоза.

Это другая задача

Производительность языков. Объектный Фибоначчи :) [Balancer#24.11.08 12:09]

… Тогда уже почему бы не считать Фибоначчи итеративно? Или с хвостовой переменной? См. с самого начала для чего предназначен этот тест.// Программирование

Производительность языков. Объектный Фибоначчи :) [Balancer#21.09.09 16:55]

… Потому что это цель теста. Поверь, для простого вычисления чисел Фибоначчи есть куда более подходящие способы … Я тут подобрал более актуальный пример (ближе к реалиям), но тестить буду позже и уже в отдельной теме. Вот, например, вариант на Java: code java class FibObj2 { private int _value ; private FibObj2 _prev1 ; private FibObj2 _prev2 ; private int [ ] _foo = new…// Программирование

Самоцитата с Гитхаба:

Предупреждаю сразу — эти тесты созданы не для того, чтобы считать Фибоначчи. Постоянно появляется очередной Кэп О., глубокомысленно заявляющий, что это неоптимальный метод для вычисления чисел Фибоначчи. Причём, что характерно, в качестве решения чаще предлагают рекурсивный же алгоритм, но без объектов. Господа-товарищи, тест служит не для этого. А если уж хотите менять алгоритм, то используйте не рекурсивный, а итеративный. Или с локальными переменными

alexsolo #22.01.2017 21:56 @Balancer#22.01.2017 21:50

alexsolo

новичок

alexsolo>> Добавьте моего тормоза.
Balancer> Это другая задача

А, увидел. Сорри. Ну, давайте расширим тест - скажем, посчитать 1 000 000 000 Фибоначи, вот это будет цирк когда грамотный алгоритм скриптового языка будет уделывать Си

В случае, если надумаете по скорости сравнить (а вдруг?

) то вот что у меня вышло на java без всяких рекурсий

\jdk1.7.0_79\bin\java" -Xms512m -Xmx4096m -server Fibonacci 1000000000
Number of bits: 694241913
First 10 bytes: 01 62 80 b8 2d 8c be 0e dc 1b
Last 10 bytes : a9 53 2d f4 d2 d2 5b 5d b6 3b
Time (ms): 208597.119691

Это сообщение редактировалось 22.01.2017 в 22:25

Последние действия над темой

Balancer [28.01.2011 11:18]: Перенос сообщений в Программистский юмор
Все действия над темой

1 2 3 4 5

в начало страницы | новое

старые » Наука и техника » Компьютерный » Программирование » Производительность языков. Объектный Фибоначчи :)