Поговаривают, что std::ranges из C++20, а именно стандартную библиотеку мы хотим в обычной жизни использовать, уступает по производительности стандартным C++11/17 алгоритмам из <algorithm>. Хотелось бы подискутировать на эту тему, а не просто прочитать, чем view лучше классики.
Объяснений худшей производительности std::ranges я знаю два.
а). не успели ещё сделать оптимизацию для конкретных типов в std::ranges
б). из-за того, что конвейер создаётся из нескольких объектов-адаптеров, каждый из них хранит в себе какие-то лямбда-функции, указатели или ссылки и т.д., а сами объекты образуют сложную цепочку типов, то компилятор не может сквозь это всё увидеть суть, и сгенерировать код, сравнимый по эффективности с классическим "ручным" циклом, или применить SIMD-оптимизации.
Если вы включаете -std=c++17, то можно использовать std::filesystem вместо boost::filesystem. Ещё, у вас сервер синхронный, т.е. если какие-то дисковые операции выполняются медленно, или застревают, то остальные клиенты просто ждут, и диск у вас получается "узким местом". Например, у вас файловая система по NFS.
В Go нет исключений в описание языка. Но они там есть, причём, по честному, с разматыванием стека.
Ещё при этом, я посылаю проклятия всем писателям библиотек, кто панику с самого низа посылает. Понятное дело, что панику можно перехватить и обработать, но не все джуны к этому готовы, но это не правильный подход при написании библиотек!
Статья с пометкой hubs/cpp - это, конечно, оффтоп. А так, вам бы C++ std::flat_map создавать, и перезагружать конфигурацию на лету через RCU. У вас не было бы столько потери CPU на сборку мусора, и производительность бы зашкаливала из-за локального кэша процессора. Ещё наверняка, какие-то алгоритмы можно было переписать так, чтобы кэшировать промежуточные результаты, чтобы не вычислять на каждый запрос.
Вопрос чайника - а если уже есть ESP32, то зачем потребовалась ещё и Arduino Nano? Можно было код ардуины впихнуть в ESP32, или там какой-то жёсткий реалтайм нужен, которого нет в ESP32?
Статью надо было озаглавить: "Всегда делайте getters/setters inline".
Или, что, когда у вас есть указатель на класс, который final, то vtable не нужон. Но тогда вы тему CRTP ни разу не раскрыли. <offtopic> В Расте вообще это просто traits, которые бывают двух типов, а в С++ это превращается в виртуал, или в CRTP.</offtopic>
Что-то про ranges было, но ни разу не упомянули, что они ни в libstdc++, ни в libc++, они не оптимизированы, а делают код, который медленнее, чем старые аналоги, если только это не Range-v3 библиотека. <offtopic> Кстати, C++20 format тоже сосёт, по сравнению с {fmt}.</offtopic>
И превращается это в старый добрый vim, который бесплатный, и ещё быстрее.
Поговаривают, что std::ranges из C++20, а именно стандартную библиотеку мы хотим в обычной жизни использовать, уступает по производительности стандартным C++11/17 алгоритмам из <algorithm>. Хотелось бы подискутировать на эту тему, а не просто прочитать, чем view лучше классики.
Объяснений худшей производительности std::ranges я знаю два.
а). не успели ещё сделать оптимизацию для конкретных типов в std::ranges
б). из-за того, что конвейер создаётся из нескольких объектов-адаптеров, каждый из них хранит в себе какие-то лямбда-функции, указатели или ссылки и т.д., а сами объекты образуют сложную цепочку типов, то компилятор не может сквозь это всё увидеть суть, и сгенерировать код, сравнимый по эффективности с классическим "ручным" циклом, или применить SIMD-оптимизации.
Если вы включаете -std=c++17, то можно использовать
std::filesystemвместоboost::filesystem.Ещё, у вас сервер синхронный, т.е. если какие-то дисковые операции выполняются медленно, или застревают, то остальные клиенты просто ждут, и диск у вас получается "узким местом". Например, у вас файловая система по NFS.
Обязательно именно этот компилятор, или mingw64 пойдёт?
В Go нет исключений в описание языка. Но они там есть, причём, по честному, с разматыванием стека.
Ещё при этом, я посылаю проклятия всем писателям библиотек, кто панику с самого низа посылает. Понятное дело, что панику можно перехватить и обработать, но не все джуны к этому готовы, но это не правильный подход при написании библиотек!
Вопрос, с чем сравнивать. Многие переписывают с Python на Go микросервисы, и получают весомую прибавку в производительности.
Порог вхождения в Go ниже, чем на C++, а в таких объёмах С++ программистов нанимать сложно.
Программист на Go реализует сервис за время быстрее, чем если бы программист писал на C++. Понятно, что за удобство приходится расплачиваться runtime.
[+] Moderatorial
Если бы вы отвечали в Фидо, вам бы уже выписали плюс за оверквотинг.
А бабушка не материлась со словами SIGSEGV?
Три недели они писали свой код, но они импортировали стопицот библиотек видимо, и как будто вы в C++ затащили Boost.
Статья с пометкой
hubs/cpp- это, конечно, оффтоп.А так, вам бы C++ std::flat_map создавать, и перезагружать конфигурацию на лету через RCU. У вас не было бы столько потери CPU на сборку мусора, и производительность бы зашкаливала из-за локального кэша процессора.
Ещё наверняка, какие-то алгоритмы можно было переписать так, чтобы кэшировать промежуточные результаты, чтобы не вычислять на каждый запрос.
Современные компиляторы генерируют код, что когда исключения не бросаются, то нет накладных расходов.
Всегда было правило, что dynamic_cast для дебагерных билдов, и в продакшене static_cast.
Судя по описанию, у них вот так
Вы ещё забыли сказать, что никаких исключений и rtti в геймдеве!
Похоже VectorLoop0 был соптимизирован этим бенчмарком в ничего.
Рейт лимит не завезли?
Tcmalloc? У вас там треды? Тогда надо про треды пейсать. А иначе, если топик про c++, то давайте вспомним c++17 std::pmr::polymorphic_allocator
... низкий уровень материала.
Вопрос чайника - а если уже есть ESP32, то зачем потребовалась ещё и Arduino Nano? Можно было код ардуины впихнуть в ESP32, или там какой-то жёсткий реалтайм нужен, которого нет в ESP32?
Можно ещё добавлю (код) ревью?
Надо бы добавить виртуальный деструктор.
Мы так не говорим. Does it work in this way? Или, Does it work like this?
Здесь не хватает барьеров для переменной
__guard. Но проще всегоstd::atomicиспользовать.Статью надо было озаглавить: "Всегда делайте getters/setters inline".
Или, что, когда у вас есть указатель на класс, который final, то vtable не нужон. Но тогда вы тему CRTP ни разу не раскрыли.
<offtopic>В Расте вообще это просто traits, которые бывают двух типов, а в С++ это превращается в виртуал, или в CRTP.</offtopic>Что-то про ranges было, но ни разу не упомянули, что они ни в libstdc++, ни в libc++, они не оптимизированы, а делают код, который медленнее, чем старые аналоги, если только это не Range-v3 библиотека.
<offtopic>Кстати, C++20 format тоже сосёт, по сравнению с {fmt}.</offtopic>Ромбовидное наследование? Если приходится так делать, то это сигнал к тому, что надо пересмотреть дизайн.