Здравствуйте, xRAZORx, Вы писали:
RAZ>Тут читал на хабре
Это все бессмысленные пиписько-замеры. По моему опыту производительности, что шарпа, что явы в большинстве случаев за глаза. Памяти они по сравнению с С++ все же кушают больше раза в 3, но как правило и это не проблема. С++ требует очень высокой квалификации — на нем можно написать реально быстрый код, а можно по невнимательности сделать тормозной.
Здравствуйте, Nuzhny, Вы писали:
N>P.S. Я уже молчу про центральный пассаж, что bubble sort — это типичный код. Скажите мне пожалуйста, кто из плюсовиков или шарпистов вообще писал хоть какую-нибудь сортировку? А buble sort?
Почему "писал"? Использовал. Сортировка — довольно типичный исполняемый код.
А мерять пузырёк или quicksort, идущий по умолчание в Linq2Object(т.е. в подавлящем большинстве случаев в .net) — действительно разница невелика.
Здравствуйте, xRAZORx, Вы писали:
RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.
Как обычно в таких тестах — по всем измерениям видно что с# медленнее чем с++. Но вывод автор делает "Получается в .NET Native быстродействие такое же, как у C++."
Здравствуйте, xRAZORx, Вы писали:
RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.
At Cassandra Summit opening today, Avi Kivity and Dor Laor (who had previously written KVM and OSv) announced ScyllaDB — an open-source C++ rewrite of Cassandra, the popular NoSQL database. ScyllaDB claims to achieve a whopping 10 times more throughput per node than the original Java code, with sub-millisecond 99%ile latency. They even measured 1 million transactions per second on a single node. The performance of the new code is attributed to writing it in Seastar — a C++ framework for writing complex asynchronous applications with optimal performance on modern hardware.
Здравствуйте, PM, Вы писали:
PM>Новость из реальной жизни — переписывание проекта с Java на C++ дало ускорение в 10 раз: http://m.slashdot.org/story/300257
О, еще один синтетический тест 10-летней давности, когда MS активно продвигала .Net и C# был светлым будущим для всех без исключения. "Память больше не ресурс" ага, помню такое на этом сайте.
По вашей же ссылке первый комментатор справедливо указал, что хоть Реймонд Чен и голова, но как-то быстро он скатился в древний C, заново изобретая велосипеды. Скорее всего потому, что C++ он не знал, как не знал и то, что умные указатели, пулы объектов и регулярные выражения уже существовали в Boost в 2005 году.
Думаю современный C++11 компилятор использовал бы перемещение строк вместо копирования при добавлении новых элементов в словарь. Так что даже первая версия с минимальными изменениями показала бы сопоставимые с C# результаты.
Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/
Здравствуйте, PM, Вы писали:
PM>По вашей же ссылке первый комментатор справедливо указал, что хоть Реймонд Чен и голова, но как-то быстро он скатился в древний C, заново изобретая велосипеды. Скорее всего потому, что C++ он не знал, как не знал и то, что умные указатели, пулы объектов и регулярные выражения уже существовали в Boost в 2005 году.
PM>Думаю современный C++11 компилятор использовал бы перемещение строк вместо копирования при добавлении новых элементов в словарь. Так что даже первая версия с минимальными изменениями показала бы сопоставимые с C# результаты.
PM>Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/
А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз быстрее.
Здравствуйте, alexzz, Вы писали:
A>А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз быстрее.
Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))
_>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. ))) https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx
и солнце б утром не вставало, когда бы не было меня
_>Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. )))
Если бы программы состояли исключительно из автовекторизуемых циклов, то вообще не нужен был бы никакой язык, кроме C++ .
Здравствуйте, Serginio1, Вы писали:
_>>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. ))) S> https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну это то как раз очень просто, в отличие от вышеприведённого случая, который явно надо было очень долго специально придумывать. Достаточно взять любой цикл, занятый например преобразованием массива чисел. В случае нормального современного компилятора C++ сработает автовекторизация, что скоре всего даст ускорение раз 6 на современных процессорах. Ну и плюс общая слабость оптимизатора C# ещё в пару раз ускорение даёт. В итоге раз в 12 как раз выйдет. ))) S>> https://msdn.microsoft.com/ru-ru/library/system.numerics(v=vs.110).aspx
_>И какое это имеет отношение к автовекторизации? )
К авто не имеет, а к векторизации полное.
Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.
Здравствуйте, alexzz, Вы писали:
PM>>Впрочем, это довольно распространённая практика — взять малознакомый инструмент; попытаться сделать что-то игрушечное; получить результаты хуже, чем со своим любимым молотком; сделать и опубликовать далеко идущие выводы. Вот недавний пример: http://eax.me/cpp-regex/
A>А, ну понятно. Дословный перевод программы с C++ на C# сходу заработал в 10 раз быстрее, потому что исходная программа была написана на C++ неправильно. Вполне такое может быть. Мне искренне любопытно, как должна быть написана программа на C#, чтобы её дословный перевод на C++ заработал в 10 раз
Я думаю в вычислительных задачах типа такой: C# — from indians by indians в настоящее время сложно обогнать С++, может быть разница будет не в 10 раз, но ощутима.
По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.
Здравствуйте, PM, Вы писали:
PM>Я думаю в вычислительных задачах типа такой: C# — from indians by indians в настоящее время сложно обогнать С++, может быть разница будет не в 10 раз, но ощутима.
Там дальше по теме Sinix привёл unsafe вариант на C#, который работает в 1,8 раза быстрее оригинала на C#. Далее цитата самого автора задачи:
Глянул сейчас. В общем на старой машинке (C2D, WinXP 32) C# unsafe вариант кода исполняется почти с той же производительностью, что и C++ вариант с SIMD
У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.
PM>По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.
Про то, что ускорение в 10 раз вызвал именно переход с Java на C++, упоминается лишь в желтушном заголовке новости.
Здравствуйте, Serginio1, Вы писали:
_>>И какое это имеет отношение к автовекторизации? ) S>К авто не имеет, а к векторизации полное.
Ну так тогда и код не будет одинаковым, даже близко. ))) В C++ останется изначальный простенький цикл, а в C# надо будет нагородить всяких ужасов. А в вопросе речь шла об одинаковом коде.
S>
S> Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.
Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))
Здравствуйте, xRAZORx, Вы писали:
RAZ>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.
Приходится писать на всех языках в зависимости от потребностей. У меня получается так, что:
— ядро рабочего приложения на работе пишется на С++, т.к. он кроссплатформенный.
— кодогенераторы — питон.
— интерфейс — самописный специализированный езыг.
— графика — glsl
— домашние исследования по алгоритмам — C#
— домашний сервак — Ruby
— сейчас вот прожку на андроиде пишу на яве, на ней же писал некоторые серваки пару лет назад.
Если не считать Ruby (который был выбран из любопытства) то остальные языки были практически безальтернативны.
Здравствуйте, alexzz, Вы писали:
A>Там дальше по теме Sinix привёл unsafe вариант на C#, который работает в 1,8 раза быстрее оригинала на C#.
Угу. Сделав дико страшный код (в сравнение и с C# оригиналом и с C++ оригиналом) он сумел ускориться в пару раз, но при этом отставание в разы от C++ всё равно сохранилось. )))
A>Я написал свой вариант на C#, работает ещё быстрее оригинала, в 2,3 раза: http://pastebin.com/v2ZMRu86 A>original: 9881 A>optimized: 4342
мы смело можем заменить значение для C# unsafe с 5,0 секунд на 4,6 секунды. Что впрочем вообще никак не меняет общую картину.
Кстати, возник ещё один интересный нюанс. Оригинальный C# из данного исходника исполнялся у меня 8,1 секунды, а не 8,7 секунды, как в изначальном коде. Хотя всё выглядит практически одинаково. Я немного поигрался с кодом и выяснил, что это происходит при передаче данных в Test в виде параметров (у меня это были статические члены класса приложения). Это конечно же характеризует оптимизатор .net с интересной стороны. )))
A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.
Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.
Здравствуйте, alex_public, Вы писали
_>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.
Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".
