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

EP>Sinix, а что смешного? Ты же сам намерял >8x

Автор: Sinix
Дата: 16.07.16

abstraction penalty на C#.

Ну как сказать... вот первоначальная цитата:

Вот тут C++ код скомпированный в JavaScript и запущенный в Firefox показывает скорость близкую к native'у — 75ms, на native C++ было 60ms, на C# — 69ms.
Если на C# использовать не низкоуровневый цикл, а transform и лямбду (как было на C++) — то получается 141ms.

Она у тебя магией превращается в

C++ скомпилированный в ненативный JavaScript (в веб-браузере, Карл!) оказался практически в два раза быстрее кода на C#?

Ну да блин, _внезапно_ шарп не инлайнит делегаты, не использует автоматом simd, не выполняет автовекторизацию и не делает ещё кучу плюшек (что, в принципе, может быть поправлено в .net native, но явно не в ближайшем будущем). Ну так про это и надо писать, а не передёргивать.

Попробую намекнуть: в том же топике тот же самый код, скормленный компилятору 2013й студии выполнялся с Elapsed = 189.011 ms. Собсно вопрос: как я буду выглядеть, если из топика в топик буду рассказывать, что шарп быстрей плюсов в три раза (куча восклицательных знаков, му-ха-ха по выбору)?


UPD
EP>Ты же сам намерял >8x

Автор: Sinix
Дата: 16.07.16

abstraction penalty на C#.

Ну так снова то же самое — сравниваем вариант с вызовом делегата и без делегата внутри tight loop при очень дешёвом делегате. Для боль-менее тяжёлого кода (см результаты для сравнения строк) разницы не видно, для критичных мест можно не полениться и расписать вручную. Хотя правильный вариант, разумеется, пересмотреть алгоритм. Потому что утыкаться в "мы миллионы раз в секунду ищем элемент с минимальным значением поля"... Тут точно надо консерваторию править.