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 не помогло.
Здравствуйте, cattus, Вы писали:
C>>Аналогичная скорость выполнения достигается на Lispe CMUCL, SBCL, если код реализуется в виде макры.
C>Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N. ))
Здравствуйте, cattus, Вы писали:
C>Поигравши с лисповыми макрами, мой друг улучьшил время выполнения кода до 0 мс, притом время выполнения совершенно не зависит от N. ))
надо полагать сырцы тока завтра будут..?
Re[3]: BOOST, .NET, String.Split и производительность…
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: BOOST, .NET, String.Split и производительность…
) который работает с теми же 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. ))
_>надо полагать сырцы тока завтра будут..?
) который работает с теми же 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-ом, то таки да, вянда традиционно г-но. все же просто...
Здравствуйте, Odi$$ey, Вы писали:
OE>>>ничего, что также изначально было OE>>>C# (под той же виндой) — 1сек ? _>>но с этим-то никто не спорил OE>ну дык если под одной и той же виндой результат зависит от языка/библиотек с какой радости может быть "таки да, вянда традиционно г-но"?
я там смайлик забыл
собсно упор делался на то, чтов лялихе же быстрее работает, пока никто не сказал обратного
Здравствуйте, _rasta, Вы писали:
_>Здравствуйте, Odi$$ey, Вы писали:
OE>>>>ничего, что также изначально было OE>>>>C# (под той же виндой) — 1сек ? _>>>но с этим-то никто не спорил OE>>ну дык если под одной и той же виндой результат зависит от языка/библиотек с какой радости может быть "таки да, вянда традиционно г-но"?
_>я там смайлик забыл _>собсно упор делался на то, чтов лялихе же быстрее работает, пока никто не сказал обратного
Это пока неподвержденные данные, жаль не смогу скоро добратся до linux'а с установленным бустом.