[Benchmark]:updated - Split на C++,D,C#,Nemerle,Boo,Java,Sca - Философия программирования

Здравствуйте, Андрей Хропов, Вы писали:

АХ>1) DMD — 0.775 сек
АХ>2) GDC — 0.905 сек
АХ>3) С#/Nemerle — 1.1 сек
АХ>4) Python — 3.48 сек
АХ>5) Python+Psyco — 4.12 (не ускорил!)
АХ>6) GCC + Boost — 22.5 сек
АХ>7) MS VC++ + Boost — 35 сек

ну пусть будет еще tcl до кучи, раз пошла такая пьянка

#!/bin/sh
# restart using tclsh \
exec tclsh "$0" "$@"

set _len 0
set x [time {
    for {set x 0} {$x<1000000} {incr x} {
        incr _len [llength [split "123 345 asdf 23453 asdfas"]]
    }
}]
puts $x
puts $_len
puts "done"

3944175 microseconds per iteration
5000000
done

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 9
cpu MHz : 2800.960
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5605.23

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, cattus, Вы писали:

C>Все вопросы к реализации MinGW. И вообще, тестировать надо под нормальными операционками, а не под тормозами от дяди Билла. Попробуй другие компиляторы. Я собирал gcc-4.1.1 и gcc-3.3 - в обоих случаях результаты одинаковые, в первом случае линковалось с libstdc++.so.6, во втором - с libstdc++.so.5.

Другие еще сильнее тормозят

А буст у тебя какой версии?
Вообще не верится что от стандартной библиотеки так зависит, я пробовал с boost::pool_allocator не помогло.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, cattus, Вы писали:

C>>Вот еще одно подтверждение изначальной ущербности теста. Прошу сильно не пинать за код -- я очень долго ничего не писал на Haskell'е.

FR>Тест конечно ущербный, но это уже чистый мухлежь :)
FR>Просто нужно переписать не с миллионом повторов, а с миллион раз размноженной строкой:

Ну почему же мухлеж. Ведь мы не знаем ;)), как работает оптимизатор в С++, в D или где-то еще. Данный код на хаскеле полностью соответствует задаче поставленной в тесте и структурно, в основных своих частях, похож на код тестов реализованных на других языках. Никто не запрещает другим компиляторам или интерпретаторам оптимизировать код, зачем запрещать делать это ghc или SBCL'ю.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, cattus, Вы писали:

C>>Все вопросы к реализации MinGW. И вообще, тестировать надо под нормальными операционками, а не под тормозами от дяди Билла. Попробуй другие компиляторы. Я собирал gcc-4.1.1 и gcc-3.3 - в обоих случаях результаты одинаковые, в первом случае линковалось с libstdc++.so.6, во втором - с libstdc++.so.5.

FR>Другие еще сильнее тормозят

FR>А буст у тебя какой версии?
FR>Вообще не верится что от стандартной библиотеки так зависит, я пробовал с boost::pool_allocator не помогло.

Boost: 1.33.1.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, Denis2005, Вы писали:

АХ>Обожаю бенчмарки

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=dlang&lang2=gpp

C>Аналогичная скорость выполнения достигается на Lispe CMUCL, SBCL, если код реализуется в виде макры.

Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N. ;)))

Здравствуйте, cattus, Вы писали:

C>>Аналогичная скорость выполнения достигается на Lispe CMUCL, SBCL, если код реализуется в виде макры.

C>Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N.

))

Я тут тоже оптимизировал:

print 50000

Здравствуйте, cattus, Вы писали:

C>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Здравствуйте, Denis2005, Вы писали:

АХ>>Обожаю бенчмарки

C>http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=dlang&lang2=gpp

фигня

Здравствуйте, cattus, Вы писали:

C>Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N.

))

надо полагать сырцы тока завтра будут..?

Здравствуйте, Denis2005, Вы писали:

A>>Если взять STLPort, то результат будет лучше (циферки для AthlonXP@1916 MHz):
A>>MSVC 2003: 20 сек
A>>MSVC 2003 + STLPort 5.0: 6 сек.

A>>Если применить предикат, то время с STLPort сократиться до 2 сек.

D>Это все равно не очень радужный результат. У меня split-'велосипед' на STL-е с MSVC 2005 и strtok, выдает ~0.7 сек.

Очевидно что при многократном создании string получается медленне чем с strtok, который только указатели возвращает.

Могу подтвердить результат Aznog. У меня 2 сек. на MSVC 2005 + STLPort 5.1 + быстрый предикат типа isspace или bind2nd(equal_to<char>(),' ').
А если перейти на vector<iterator_range<string::iterator> >, то 1,2 сек.

Здравствуйте, cattus, Вы писали:

C>Все вопросы к реализации MinGW. И вообще, тестировать надо под нормальными операционками, а не под тормозами от дяди Билла.

Ну, вот мы и выяснили в чем проблема С++. Проблема как всегда в деде Билле. Если бы не он, то буст был бы в 30 раз быстрее и удобнее. Я всегда знал что это ЗАГОВОР!

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, saproj, Вы писали:

S>Очевидно что при многократном создании string получается медленне чем с strtok, который только указатели возвращает.

Почему же тогда с самописным split'ом (Re[4]: [Benchmark] DMD быстрее всех и Re[7]: [Benchmark] DMD быстрее всех) который работает с теми же string и создает их на каждый чих, получается гораздо шустрее чем с boost::algorithm::split?
Да и скрипты и шарп и D тоже создают строки и обгоняют буст без проблем.

S>Могу подтвердить результат Aznog. У меня 2 сек. на MSVC 2005 + STLPort 5.1 + быстрый предикат типа isspace или bind2nd(equal_to<char>(),' ').
S>А если перейти на vector<iterator_range<string::iterator> >, то 1,2 сек.

А на vc71 + STLport-4.6 с быстрым предикатом STLPort совсем не ускоряет.

Здравствуйте, _rasta, Вы писали:

C>>Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N.

))

_>надо полагать сырцы тока завтра будут..?

А они кому-то нужны? Все равно идиальнее чем у FR уже вряд ли получится.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, FR, Вы писали:

FR>Почему же тогда с самописным split'ом (Re[4]: [Benchmark] DMD быстрее всех и Re[7]: [Benchmark] DMD быстрее всех) который работает с теми же string и создает их на каждый чих, получается гораздо шустрее чем с boost::algorithm::split?
FR>Да и скрипты и шарп и D тоже создают строки и обгоняют буст без проблем.

А разве это не очевидно? Потому, что вместо выпендрежа люди просто писали библиотеки для реальной работы. А те кто писал бустовский сплит основной целью ставили сделать красиво на С++. Цель то была доказать тезис о том, что С++ настолько крут, что в нем все можно сделать в бибилотеке... и лямбду, и замыкание, и черта лысого. Меж тем если выбростиь все навороты, то написать шустрый сплит на С++ не составляет пробелмы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

C>>Все вопросы к реализации MinGW. И вообще, тестировать надо под нормальными операционками, а не под тормозами от дяди Билла.
VD>Ну, вот мы и выяснили в чем проблема С++. Проблема как всегда в деде Билле. Если бы не он, то буст был бы в 30 раз быстрее и удобнее. Я всегда знал что это ЗАГОВОР!

ну вот зачем писать бред?

изначально было:
6) GCC + Boost — 22.5 сек
7) MS VC++ + Boost — 35 сек

время GCC + Boost было достаточно тривиально улучшено до 6063(653) ms, по разным данным, что как минимум 4 (40) раз быстрее. буста у меня, к сожалению, нет, но можно попросить присутствующих собрать представленый код в лялихе с указанными либами и выложить время выполнения. если время будет не сильно отличаться от заявленного cattus-ом, то таки да, вянда традиционно г-но. все же просто...

Здравствуйте, _rasta, Вы писали:

_>ну вот зачем писать бред?

_>изначально было:
_>6) GCC + Boost — 22.5 сек
_>7) MS VC++ + Boost — 35 сек

ничего, что также изначально было

C# (под той же виндой) — 1сек ?

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Odi$$ey, Вы писали:

OE>ничего, что также изначально было
OE>C# (под той же виндой) — 1сек ?

но с этим-то никто не спорил

кстати было бы интересно посмотреть еще на яву

Здравствуйте, _rasta, Вы писали:

OE>>ничего, что также изначально было
OE>>C# (под той же виндой) — 1сек ?
_>но с этим-то никто не спорил

ну дык если под одной и той же виндой результат зависит от языка/библиотек с какой радости может быть "таки да, вянда традиционно г-но"?

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, Odi$$ey, Вы писали:

OE>>>ничего, что также изначально было
OE>>>C# (под той же виндой) — 1сек ?
_>>но с этим-то никто не спорил

OE>ну дык если под одной и той же виндой результат зависит от языка/библиотек с какой радости может быть "таки да, вянда традиционно г-но"?

я там смайлик забыл

собсно упор делался на то, чтов лялихе же быстрее работает, пока никто не сказал обратного

Здравствуйте, _rasta, Вы писали:

_>Здравствуйте, Odi$$ey, Вы писали:

OE>>>>ничего, что также изначально было
OE>>>>C# (под той же виндой) — 1сек ?
_>>>но с этим-то никто не спорил

OE>>ну дык если под одной и той же виндой результат зависит от языка/библиотек с какой радости может быть "таки да, вянда традиционно г-но"?

_>я там смайлик забыл

_>собсно упор делался на то, чтов лялихе же быстрее работает, пока никто не сказал обратного

Это пока неподвержденные данные, жаль не смогу скоро добратся до linux'а с установленным бустом.

	От:	_rasta
	Дата:	19.09.06 11:41
	Оценка:

	От:	FR
	Дата:	19.09.06 11:45
	Оценка:

	От:	cattus
	Дата:	19.09.06 11:48
	Оценка:	-1

	От:	cattus
	Дата:	19.09.06 11:50
	Оценка:

	От:	cattus
	Дата:	19.09.06 11:55
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	19.09.06 17:24
Оценка:	+1

От:	Odi$$ey	http://malgarr.blogspot.com/
Дата:	20.09.06 04:19
Оценка: