Пусть каждый тред считает свой счётчик, а в конце встаёт на ожидание, чтобы приплюсовать результат к общему счётчику. Вот и вся оптимизация. P.s. кстати, предложенная в видео программа при таком подходе сработает мгновенно с любым вариантом оптимизаций из ролика. Потому что компилятор на этапе сборки раскроет цикл и просто подставит в итератор верхнюю границу цикла. В итоге исполнение самого цикла будет пропущено, и вычисление произойдет моментально.
Ну тестировать надо или на одноплатнике с фиксированной тактовой частотой, ну либо хотя бы попробовать залочить частоту и потребление своего процессора. Тогда результаты будут более предсказуемы.
А разве корректно сравнивать массив из си и вектор из stl? В подобных случаях, насколько я понимаю, когда программист может предугадать кол-во элементов в массиве заранее будет использоваться простой статичный массив. Или хотя бы проинициализировать вектор вместе с capacity. Тоже самое с noexcept, его можно было бы прописать в C++ для большего соответствия С. Плюсы не основной язык, поправьте если не что-то не так.
В целом корректно, в современных компиляторах стандартные библиотеки что С что С++ - интринсикуются и оптимизируются компилятором. И большая часть оптимизаций идет уже на уровне промежуточного представления - что в LLVM что в GCC. Вот реально где мы получим действительно поражение по производительности и размеру кода и памяти - это когда начнем использовать классическое крестовое ООП с наследованием интерфейсами и виртуальными методами. А композиция, плейн классы и шаблоны оптимизируются в С++ великолепнейше. Особенно шаблоны современных крестов которые вот прямо смысл перейти с С. Без семантики ООП просто на Сях в языке жить можно - тому примеры та же библиотека GTK+. А вот без шаблонов рано или поздно начинает гореть - да в последнем С сделали параметризованые макросы но все равно не то пальто.
@@АлександрСоловьев-ю9ц2к То, что компилятор С++ очень лихо сворачивает конструкции это да, замечал сам на практике. Но по поводу массива и вектора все таки есть сомнения, ведь, как минимум, стат. массив должен быть на стэке, а вектор должен запрашивать память на куче (наверное, malloc). Или он НАСТОЛЬКО умный, что подменит вектор? В большинстве случаев это да, экономия на спичках, но в каком-нибудь цикле в обработке фрейма в игре может выстрелить. "Плата" за виртуальные функции это все таки плата за ветвление. Что кстати, было бы интереснее сравнить: switch на С и аналогичное полиморфизмом на плюсах. Другой вопрос, что сейчас пошла мода использовать интерфейсы и абстрактные классы там, где это вовсе и не нужно, и ветвление (или хитрая динамичность вроде плагинов) никогда не предполагалось. А поводу горения, я программирую в основном на .Net и у меня от местных generic-ов горит безостановочно из-за знания, что было на плюсах.
Не указано, что все выводы и сравнения идут с учетом конкретной архитектуры системы. Для примера попробуйте сравнить на архитектуре процессора без MMU - там все ваши размышления будут ложны :)
Очень познавательно. Спасибо!
Пусть каждый тред считает свой счётчик, а в конце встаёт на ожидание, чтобы приплюсовать результат к общему счётчику.
Вот и вся оптимизация.
P.s. кстати, предложенная в видео программа при таком подходе сработает мгновенно с любым вариантом оптимизаций из ролика. Потому что компилятор на этапе сборки раскроет цикл и просто подставит в итератор верхнюю границу цикла. В итоге исполнение самого цикла будет пропущено, и вычисление произойдет моментально.
на одноядерном микроконтроллере бы попробовать подобные вещи, там виднее будет. Тут ОС, переключение контекста, фоновые потоки....
Ну тестировать надо или на одноплатнике с фиксированной тактовой частотой, ну либо хотя бы попробовать залочить частоту и потребление своего процессора. Тогда результаты будут более предсказуемы.
А разве корректно сравнивать массив из си и вектор из stl? В подобных случаях, насколько я понимаю, когда программист может предугадать кол-во элементов в массиве заранее будет использоваться простой статичный массив. Или хотя бы проинициализировать вектор вместе с capacity. Тоже самое с noexcept, его можно было бы прописать в C++ для большего соответствия С. Плюсы не основной язык, поправьте если не что-то не так.
В целом корректно, в современных компиляторах стандартные библиотеки что С что С++ - интринсикуются и оптимизируются компилятором.
И большая часть оптимизаций идет уже на уровне промежуточного представления - что в LLVM что в GCC.
Вот реально где мы получим действительно поражение по производительности и размеру кода и памяти - это когда начнем использовать классическое крестовое ООП с наследованием интерфейсами и виртуальными методами.
А композиция, плейн классы и шаблоны оптимизируются в С++ великолепнейше.
Особенно шаблоны современных крестов которые вот прямо смысл перейти с С.
Без семантики ООП просто на Сях в языке жить можно - тому примеры та же библиотека GTK+.
А вот без шаблонов рано или поздно начинает гореть - да в последнем С сделали параметризованые макросы но все равно не то пальто.
@@АлександрСоловьев-ю9ц2к То, что компилятор С++ очень лихо сворачивает конструкции это да, замечал сам на практике. Но по поводу массива и вектора все таки есть сомнения, ведь, как минимум, стат. массив должен быть на стэке, а вектор должен запрашивать память на куче (наверное, malloc). Или он НАСТОЛЬКО умный, что подменит вектор? В большинстве случаев это да, экономия на спичках, но в каком-нибудь цикле в обработке фрейма в игре может выстрелить.
"Плата" за виртуальные функции это все таки плата за ветвление. Что кстати, было бы интереснее сравнить: switch на С и аналогичное полиморфизмом на плюсах.
Другой вопрос, что сейчас пошла мода использовать интерфейсы и абстрактные классы там, где это вовсе и не нужно, и ветвление (или хитрая динамичность вроде плагинов) никогда не предполагалось.
А поводу горения, я программирую в основном на .Net и у меня от местных generic-ов горит безостановочно из-за знания, что было на плюсах.
Не указано, что все выводы и сравнения идут с учетом конкретной архитектуры системы. Для примера попробуйте сравнить на архитектуре процессора без MMU - там все ваши размышления будут ложны :)
qsort и std::sort сравни.
da
смысл видоса: примеры тоже нужно уметь правильно придумывать.
Всё Ззависит от степени кривизны рук инженера
Погода на Марсе зависит?