×Закрыть

C++ дайджест #22: детально про оптимізацію, Trip Report засідання комітету зі стандартизації

Привіт, мої любі сішники! Сьогодні випуск буде присвячено оптимізації коду. Тож почнімо? :)

Оптимізація коду

Окрім неперевершених робіт S. Meyers з теми отимізації корисну інформацію пропоную переглянути в книгах:

А також:

Пам’ятка, що варто робити та що не варто :)

Оптимізованного вам коду!

Modern C++

Named Template Arguments

C++20 span tutorial

Trip report: Autumn ISO C++ standards meeting (Belfast)

WG21 in my own backyard: Belfast trip report

Trip Report: Freestanding Errors in Belfast

Trip Report: C++ Standards Meeting in Belfast, November 2019

Unnamed / anonymous namespaces vs static in namespace.

Корисні посилання

Bjarne Stroustrup: C++ | Artificial Intelligence (AI) Podcast

5 Ways Using Braces Can Make Your C++ Code More Expressive

Most common Git mistakes and how to fix them

A beginner’s guide to C++ Ranges and Views

Trueface Tutorials: How to Cross Compile Popular Computer Vision C++ Frameworks for Raspberry Pi 4

How to Get Started with OptiX 7

7 Advanced C++ concepts & idiom examples you should know

21 new features of modern C++ to use in your project

Rust And C++ On Floating-Point Intensive Code

8 essential patterns you should know about functional programming in C++14

Don’t Use unique_ptr for PIMPL

C++ exceptions and alternatives from Bjarne Stroustrup

Інструменти

CLion 2019.3: A Quality-Targeted Release Focused on Performance and Some

Long-Awaited Enhancements

Support for C++20’s Concepts in CLion

Why precompiled headers do (not) improve C++ compile times

Clang precompiled headers and improving C++ compile times, take #2

Clang-format tanks performance

Using Visual Studio Code for Writing Qt Applications

Оновлення

Цього місяця маємо такі оновлення:

Хвилиночка флуду

Longest C++ Variable Declaration

Creating a console animation with C++


← Попередній випуск: C++ дайджест #21
Наступний випуск: C++ дайджест #23

LinkedIn

19 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Мало коментарів щось. Треба підкинути.

От ми лишаємося на GCC 6.5, бо основний алгоритм (пошук центру мас інтенсивності лампочки, якщо коротко) на 7+ виконується рази в 3 довше, а добратися нема коли.

В когось щось подібне було?

если честно я дошёл до

6 Tips to supercharge C++11 vector performance.

прифигел и понял что я уже сильно стар для всей этой ))

Да ну. Там же базовые советы типа «используйте reserve, если знаете, сколько элементов придётся вставить» / «используйте shrink_to_fit, если ранее занимаемая вектором память вам больше не понадобится», и т.д.
Единственная спорная фигня это «Prefer emplace_back() instead of push_back() while inserting into a vector» — с этим советом не всё так однозначно, ибо быстрее может оказаться как одно, так и другое, в зависимости от конкретных типов. У Майерса об этом было более подробно.

шёл 2019-й год вектор был изобретён ... в 93-м прошлого века? emplace в 11-м века нынешего? а ну ок не все десятки лет одинаково полезны )) где-то до сих пор так вообще ссср

Ну да. И в чём проблема?

в чём проблема?

=>

что я уже сильно стар для всей этой ))
У Майерса об этом было более подробно

Де саме? В книжці він пише, що emplace_back не завжди швидше за push_back, є випадки коли він спрацює за той же час. Прикладу де emplace_back працює повільніше — я не бачив. Ну, вірніше, такий приклад можна придумати для якогось теоретичного класу, у якого звичайний конструктор працює повільно, а конструктор копіювання — швидко. Але для такого класу чесно було в порівнювати не чистий час виклику push_back/emplace_back, а повний час створення об’єкту і поміщення його в контейнер.

Здається, у цій лекції було щось подібне: www.youtube.com/watch?v=smqT9Io_bKo
Точний таймстамп зараз навряд чи знайду.

Мені теж важко придумати приклад, де б emplace працював повільніше. Але теоретично це можливо хоча б тому, що виклики цих методів часто генерують різний асм.

Нещодавно зловили асерт в link time optimization на новому GCC. За пару днів нагуглили forkstat, знайшли, на якому файлі він навернувся, і поставили усе, що не використовується, під #ifdef. Перестав падати. Перформанс не міряли, бо і так менше 5% CPU.

Вам би відпрофайлить.

А у чому проблема була? Та як тут допомогла умовна компіляція?

Та хто його знає. Там ще тиждень можна було б той GCC дебажить. Проблема що він сам створює якісь тимчасові файли, потім сам викликає свої шматки окремими процесами, тоді вони оті файли хавають, пишуть інші, а потім головний модуль усе вичищає. Коли сабмодуль падає, GCC все одно після нього вичищає усе, що згодував йому на вхід, і вже нема можливості запустить отой сабмодуль руцями під gdb і подивитись, де він заплутався. Тому замість камасутри з дебагером прибрав кілька глобальних вказівників та ще якусь фігню, котра не використовувалась в конфігурації, що роняла LTO, і воно перестало ронятись.
Ще ускладнення — це крос-компіляція, при компіляції на компі воно не падало. Можливо, там йшла оптимізація лінковки з libusb чи ще з чимось, що на компі динамічно підіймається. Коротше, не розбирався, бо можна сильно залипнуть.

Дякую, вже неактуально, а коли треба було — швидко не зміг розібратись.

Было :)
На GCC 7+ много жалоб, которые к тому же подтверждены тестамы на benchmarks ( www.phoronix.com/...​rticle&item=gcc-7-january ).

GCC 9 в некоторых мометах по производительности кода дотягивается до 6.5, но в некоторых еще медленнее. Т.е нужно более предметно смотреть.

( Тесты для GCC 9: www.phoronix.com/...​&item=gcc9-eoy-2018&num=3 )

Спасибо!

Просто відмінний випуск дайджесту.

Подписаться на комментарии