Здравствуйте, B0FEE664, Вы писали:
BFE>Преобразование строки в число? Так это никогда нормально в С++ не работало и не работает. BFE>Хотите быстрого когда — пишите парсинг руками.
есть два примера для сравниния — на C++ и на C# — с максимально приближенным кодом и рукописными процедурами парсинга — примитивными, но равноценными. И пример на C++ проигрывает примеру на C# процентов на 10 — 15. Не в пять раз, конечно, но проигрывает! Пока никто не смог даже предположительно объяснить, как такое может быть. Там быстродействие зависит от значений во входной последовательности. Этому вопросу я тоже уже уделил внимание — все примерно равноценно.
--
Re[26]: [performance] чего-то я не понимаю в этой жизни
есть два примера для сравниния — на C++ и на C# — с максимально приближенным кодом и рукописными процедурами парсинга — примитивными, но равноценными. И пример на C++ проигрывает примеру на C# процентов на 10 — 15. Не в пять раз, конечно, но проигрывает! Пока никто не смог даже предположительно объяснить, как такое может быть.
Здравствуйте, ArtDenis, Вы писали:
AD>Оптимизатор JIT умеет профилировать и дополнительно оптимизировать налету учитывая особенности исполнения кода. Возможно дело в этом. Чтобы это повторить в плюсах, придётся немного попотеть: https://docs.microsoft.com/en-us/cpp/build/profile-guided-optimizations ))
Супер! Ща мы быстренько найдем желающих попотеть... Ау, желающие! Все сюда!
--
Re[4]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, ArtDenis, Вы писали:
AD>Оптимизатор JIT умеет профилировать и дополнительно оптимизировать налету учитывая особенности исполнения кода. Возможно дело в этом. Чтобы это повторить в плюсах, придётся немного попотеть: https://docs.microsoft.com/en-us/cpp/build/profile-guided-optimizations ))
Предыдущий раз ошибся на 3 порядка. Но не важно.
Всё очень зависит от того как будут расположены строки в памяти, а не от реализации parseInt.
Если расположить строки последовательно друг за другом с выравниванием на 4 байта получим 2х кратное ускорение (с тем же кодом)
Здравствуйте, rg45, Вы писали:
R>Да не в этом сейчас вопрос. Непонятно, каким образом плюсовый вариант может быть в пять раз медленнее шарпного, даже в исходном виде.
А если убрать throw из метода Parse и сделать метод inline, скорость у С++ вырастает ?
Я c C# дела не имел. Я не пойму, нельзя сравнить assembler С# на выходе с выхлопом С++ ?
Re[4]: [performance] чего-то я не понимаю в этой жизни
. Ускорение, конечно, есть, но в C# аналогичная мера приводит к еще большему ускорению. В итоге разрыв увеличивается и получается 600 мс (C#) против 750 мс (C++). Использование inline и __forceinline никакого эффекта не дает, потому что функция инлайнится и без этого. Если встроить цикл парсинга в основной цикл прохода по входной последовательности, результат остается таким же.
V>Я c C# дела не имел. Я не пойму, нельзя сравнить assembler С# на выходе с выхлопом С++ ?
У C# выхлоп не непосредственно в машинные коды, а в промежуточный платформенно-независимый код intermediate language (IL). Во время запуска выполняется докомпиляция IL в машинные коды той платформы, на которой запускается приложение — так называемая процедура just-in-time compilation (JIT) или джиттинг. Джиттинг обеспечивается дотнетовой средой Common Language Runtime (CLR). Таким образом, достигается двухфазная оптимизация. Не знаю даже, имеет ли смысл сравнивать IL с ассемблером.
Здравствуйте, Nuzhny, Вы писали:
N>Ещё интересно, а они не могут незаметно по ядрам цикл распараллелить? Тут же никаких эффектов нет.
Была у меня такая мысль... Но это просто фантастика, если это так. Допустим XOR распараллелить — не проблема, но далеко ведь не все вычисления поддаются распараллеливанию.
Еще у меня была мысль, что они могут кэшировать результаты вычислений. Допустим, если какая-то строка встречается повторно, то вместо вычислений, просто берется ранее вычисленный результат. Тут может быть задействовано интернирование строк. Но, по-моему, все это на уровне фантастики.
R>У C# выхлоп не непосредственно в машинные коды, а в промежуточный платформенно-независимый код intermediate language (IL). https://godbolt.org/z/1oanThds6
Re[7]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>Еще у меня была мысль, что они могут кэшировать результаты вычислений. Допустим, если какая-то строка встречается повторно, то вместо вычислений, просто берется ранее вычисленный результат. Тут может быть задействовано интернирование строк. Но, по-моему, все это на уровне фантастики.
Согласен. Ещё у Александреску был быстрый вариант на switch без цикла. Но это не для wchar
Re[6]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, σ, Вы писали:
R>>У C# выхлоп не непосредственно в машинные коды, а в промежуточный платформенно-независимый код intermediate language (IL). σ>https://godbolt.org/z/1oanThds6
Фига он соптимизировал:
lea eax, [rax+4*rax]
lea eax, [rbx+2*rax-48]
Re[7]: [performance] чего-то я не понимаю в этой жизни
А причем тут умножение на 10. Он всю строчку: res = res * 10 + d — '0'; в два lea загнал.
P.S. Кстати, почему-то С# инкрементит на единицу, как-будто у него строка из char-ов состоит, а С++ на 2-ку. Если в С++ заменить std::wstring на std::string и компилировать gcc, то код идентичный C# получается
