Да, вы правы, я тоже попробовал в VS - почему-то не оптимизируется ни фига, хотя такой простейший вариант, казалось бы... По сути сводится к такому:
А точно включили всю оптимизацию в настройках проекта? Я в непонятных случаях включаю генерацию ассемблерного листинга и смотрю в него, очень познавательное занятие.
Интереса ради решил протестить также в C#. Мало того, что результаты практически не отличаются между собой по скорости, так ещё и работают на порядок быстрее, чем C++.
publicclass Program
{
publicstaticvoid Main()
{
int count = (int)10e6;
{
var watch = System.Diagnostics.Stopwatch.StartNew();
int sum = 0;
for (int i = 0; i < count; i++)
{
string st;
st = "12345678qwertyuioasdfgh";
sum += st[i % 23];
}
Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
}
{
var watch = System.Diagnostics.Stopwatch.StartNew();
int sum = 0;
string st;
for (int i = 0; i < count; i++)
{
st = "12345678qwertyuioasdfgh";
sum += st[i % 23];
}
Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
}
Console.ReadKey();
}
}
Результаты:
Sum: 894782460, Time: 69 ms
Sum: 894782460, Time: 56 ms
А вот аналог в C++:
Sum: 894782460, Time: 2947 ms
Sum: 894782460, Time: 684 ms
Тестирую в VS 2019. Вся оптимизация включена.
В топку такой C++ )
p.s. Результаты в C# заметно скачут от теста к тесту, но в среднем выходит, что оба варианты одинаковы по скорости.
который сиди в libstdc++. Т.е. на фоне почти голого цикла узким местом становятся сами вызовы функций (ну и из ...replaceEmmPKcm тоже пара вызовов идёт). Компилятор ведь может оптимизировать в рамках одной единицы трансляции. Тут можно попробовать заюзать LTO (link time optimization), т.е. это позволит производить оптимизацию на стадии линковки. Но я её особо не юзал, сейчас с ходу не буду делать. Ну там ничего особо сложного - передать компилятору/линкеру опцию -flto (правда у меня какого-то плагина не хватает), короче лень разбираться + возможно придётся пересобрать libstdc++.
Ну как там будет с оптимизацие кода в связи с грядующим вкручиванием модулей (начиная с C++20) ? Не знаю, можете в vs повертеть, хотя всё сыро и экспериментально https://habr.com/en/company/pvs-studio/blog/328482/
Команда Visual C++ рада сообщить, что в Visual Studio 2017 было существенно улучшено качество реализации модулей C++ согласно технической спецификации; также мы добавили возможность подключать Стандартную Библиотеку C++ через интерфейсы модулей. Эти интерфейсы, как и поддержка модулей компилятором, являются экспериментальной разработкой и будут...
Интереса ради решил протестить также в C#. Мало того, что результаты практически не отличаются между собой по скорости, так ещё и работают на порядок быстрее, чем C++.
Результаты:
Sum: 894782460, Time: 69 ms
Sum: 894782460, Time: 56 ms
А вот аналог в C++:
Sum: 894782460, Time: 2947 ms
Sum: 894782460, Time: 684 ms
Тестирую в VS 2019. Вся оптимизация включена.
В топку такой C++ )
p.s. Результаты в C# заметно скачут от теста к тесту, но в среднем выходит, что оба варианты одинаковы по скорости.
Бр-р-р-р, да быть не могет! Всегда шарп чистым плюсам сливал раза в два, вы проект выложите плз.
Тут надо понять причины тормозов сначала. Покопал маленько, там всё инлайнится кроме вызова
который сиди в libstdc++.
Так вроде выяснили, что он память каждый раз выделяет и удаляет даже в таком случае:
char *str = newchar[23];
...
delete str;
Кстати я возможно некорректные результаты привёл в прошлый раз. Это скорее всего было в режиме x86. Сейчас тестю в x64 - результаты по C++ значительно лучше:
1) ~ 2000 мс
2) ~ 200 мс (ускорилось 3 раза)
Правда я ещё Студию обновил до последней версии, видимо это тоже повлияло, т.к. даже x86 сейчас быстрее прошлых замеров.
Ну в общем теперь C++ не так позорно сливает шарпу. Всего в 3 раза примерно )
Так вроде выяснили, что он память каждый раз выделяет и удаляет даже в таком случае:
Кстати я возможно некорректные результаты привёл в прошлый раз. Это скорее всего было в режиме x86. Сейчас тестю в x64 - результаты по C++ значительно лучше:
1) ~ 2000 мс
2) ~ 200 мс (ускорилось 3 раза)
Правда я ещё Студию обновил до последней версии, видимо это тоже повлияло, т.к. даже x86 сейчас быстрее прошлых замеров.
Ну в общем теперь C++ не так позорно сливает шарпу. Всего в 3 раза примерно )
вы не поняли, я о другом. Вообще тест игрушечный - голый цикл без полезной нагрузки. Я вам пытался сказать - что потери на вызовах функций, которые не могут заинлайниться. Лучше потестите плюсовые модули, интереснее там результат, хотя может быть еще недопиленные.
time = 1018
sum = 894782460
time = 371
sum = 894782460
Х.з. почему, но мкл сильно обгоняет (и более затейливые варианты с rand()).
А для меня очевидно - выносить за цикл.
Да, вы правы, я тоже попробовал в VS - почему-то не оптимизируется ни фига, хотя такой простейший вариант, казалось бы... По сути сводится к такому:
Да, вы правы, я тоже попробовал в VS - почему-то не оптимизируется ни фига, хотя такой простейший вариант, казалось бы... По сути сводится к такому:
А точно включили всю оптимизацию в настройках проекта? Я в непонятных случаях включаю генерацию ассемблерного листинга и смотрю в него, очень познавательное занятие.
Интереса ради решил протестить также в C#. Мало того, что результаты практически не отличаются между собой по скорости, так ещё и работают на порядок быстрее, чем C++.
Результаты:
Sum: 894782460, Time: 69 ms
Sum: 894782460, Time: 56 ms
А вот аналог в C++:
Sum: 894782460, Time: 2947 ms
Sum: 894782460, Time: 684 ms
Тестирую в VS 2019. Вся оптимизация включена.
В топку такой C++ )
p.s. Результаты в C# заметно скачут от теста к тесту, но в среднем выходит, что оба варианты одинаковы по скорости.
Тут надо понять причины тормозов сначала. Покопал маленько, там всё инлайнится кроме вызова
который сиди в libstdc++. Т.е. на фоне почти голого цикла узким местом становятся сами вызовы функций (ну и из ...replaceEmmPKcm тоже пара вызовов идёт). Компилятор ведь может оптимизировать в рамках одной единицы трансляции. Тут можно попробовать заюзать LTO (link time optimization), т.е. это позволит производить оптимизацию на стадии линковки. Но я её особо не юзал, сейчас с ходу не буду делать. Ну там ничего особо сложного - передать компилятору/линкеру опцию -flto (правда у меня какого-то плагина не хватает), короче лень разбираться + возможно придётся пересобрать libstdc++.
Ну как там будет с оптимизацие кода в связи с грядующим вкручиванием модулей (начиная с C++20) ? Не знаю, можете в vs повертеть, хотя всё сыро и экспериментально https://habr.com/en/company/pvs-studio/blog/328482/
с++'у вас будет не хватать )).
Интереса ради решил протестить также в C#. Мало того, что результаты практически не отличаются между собой по скорости, так ещё и работают на порядок быстрее, чем C++.
Результаты:
Sum: 894782460, Time: 69 ms
Sum: 894782460, Time: 56 ms
А вот аналог в C++:
Sum: 894782460, Time: 2947 ms
Sum: 894782460, Time: 684 ms
Тестирую в VS 2019. Вся оптимизация включена.
В топку такой C++ )
p.s. Результаты в C# заметно скачут от теста к тесту, но в среднем выходит, что оба варианты одинаковы по скорости.
Бр-р-р-р, да быть не могет! Всегда шарп чистым плюсам сливал раза в два, вы проект выложите плз.
Дети малые :)
Аж на 10 страниц растянули игрушку...
Тут надо понять причины тормозов сначала. Покопал маленько, там всё инлайнится кроме вызова
который сиди в libstdc++.
Так вроде выяснили, что он память каждый раз выделяет и удаляет даже в таком случае:
Кстати я возможно некорректные результаты привёл в прошлый раз. Это скорее всего было в режиме x86. Сейчас тестю в x64 - результаты по C++ значительно лучше:
1) ~ 2000 мс
2) ~ 200 мс (ускорилось 3 раза)
Правда я ещё Студию обновил до последней версии, видимо это тоже повлияло, т.к. даже x86 сейчас быстрее прошлых замеров.
Ну в общем теперь C++ не так позорно сливает шарпу. Всего в 3 раза примерно )
Так вроде выяснили, что он память каждый раз выделяет и удаляет даже в таком случае:
Кстати я возможно некорректные результаты привёл в прошлый раз. Это скорее всего было в режиме x86. Сейчас тестю в x64 - результаты по C++ значительно лучше:
1) ~ 2000 мс
2) ~ 200 мс (ускорилось 3 раза)
Правда я ещё Студию обновил до последней версии, видимо это тоже повлияло, т.к. даже x86 сейчас быстрее прошлых замеров.
Ну в общем теперь C++ не так позорно сливает шарпу. Всего в 3 раза примерно )
Бр-р-р-р, да быть не могет! Всегда шарп чистым плюсам сливал раза в два, вы проект выложите плз.
Лучше потестите плюсовые модули, интереснее там результат, хотя может быть еще недопиленные.
Посмотрел, получается, что модули не допилил ни один компилятор https://en.cppreference.com/w/cpp/compiler_support, так что и смотреть нечего.