Некоторое время назад сделал свой логгер - просто потому что захотелось упороться в производительность. С берчмарками, все дела. Так вот, что меня удивило - очень большая разница cout / fwrite и ofstream / fopen / mapping подходов на MSVC. В то время как на gcc / cmake все эти методы дают практически одинаковую производительность, в MSVC разница в первом случае 18 : 1, во втором - 9 : 1.22 : 1 Кому интересно, поковыряться можно тут.
Статья хороша в том плане, что можно увидеть, где именно у вас в проекте могут быть проблемы и как их можно решить. Но с самого начала следовать им я бы не советовал, иначе проект рискует не добраться до момента, когда кому-то будет не пофиг на его производительность.
Особенно это касается замены вектора на сырой массив, избегания туплов и других движений в сторону примерно С++03. Не поймите меня неправильно, они скорее всего действительно работают и полезны в плане перфы, но точно не для рандомных багов выделения памяти или увеличенного времени на реализацию фичи, потому что чёрт ногу сломит в низкоуровневом коде.
Извините, но статья больше похожа на "в С++ есть интерфейс для аллокаторов, выглядит вот так, можно делать разные прикольные штуки" Вот библиотека с кастомными аллокаторами, там в ридми в разы больше информации - https://github.com/mtrebi/memory-allocators
Я правильно понимаю, что движок будет нормально работать только при "axis aligned" пространстве, а если у меня геоид, то я иду лесом? Что посоветуете использовать в таком случае?
Ваш способ просто неверный, OpenGL не разрешает доступ к одному контексту из разных потоков
То, что это работает на вашей машине, не гарантирует, что оно не развалится у соседа
Я думал, сейчас почитаю статью про создание нового контекста на другом потоке и шаринге ресурсов между ними (а это правильный способ сделать то, что вы хотите сделать), но был несколько разочарован
Да, я имел в виду именно проблему с динамическими библиотеками
Честно говоря, я сам не копал так глубоко, чтобы самостоятельно ковырять все компиляторы и пилить бенчмарки, но читал некоторые статьи, плюс видел, что на каждом моём месте работы (геймдев) была своя похожая замена RTTI, в т.ч. это UE.
Конечно, возможно, что все эти люди и замеры неправы, а рандомный чел из инета - прав, но что то я сомневаюсь =)
Вы имеете в виду производительность? Нет. RTTI зачастую вообще реализуется через сравнение строк (названий классов), оверхед использования vtable по сравнению с этим - пыль.
Я не совсем понял, зачем прибивать гвоздями классы к их отражению в виде enum - разве что вам очень сильно хочется вынести это в constexpr В своей реализации я вынес этот "айди" класса в статический член, который генерирует новый айди для каждого класса, и делает это при запуске программы - автоматически, конечно В итоге всё работает только на виртуальных методах без хранимого объекта айдишника вообще, и при этом очень легко расширяемо - нужно только добавить макрос в класс, примерно как в qt
Новая фича «Designated initializers» - топ. Столько раз об это спотыкался.
Некоторое время назад сделал свой логгер - просто потому что захотелось упороться в производительность. С берчмарками, все дела. Так вот, что меня удивило - очень большая разница cout / fwrite и ofstream / fopen / mapping подходов на MSVC. В то время как на gcc / cmake все эти методы дают практически одинаковую производительность, в MSVC разница в первом случае 18 : 1, во втором - 9 : 1.22 : 1
Кому интересно, поковыряться можно тут.
Хотелось бы ещё увидеть сравнение с использованием std::formatted_size, т.е.
Замерить длину
Аллоцировать память
Форматировать
Мы проходим строку два раза, но аллоцируем лишь однажды
Не оспариваю общую мысль, но всё же использовать США тех времён для сравнения некорректно.
Статья хороша в том плане, что можно увидеть, где именно у вас в проекте могут быть проблемы и как их можно решить. Но с самого начала следовать им я бы не советовал, иначе проект рискует не добраться до момента, когда кому-то будет не пофиг на его производительность.
Особенно это касается замены вектора на сырой массив, избегания туплов и других движений в сторону примерно С++03. Не поймите меня неправильно, они скорее всего действительно работают и полезны в плане перфы, но точно не для рандомных багов выделения памяти или увеличенного времени на реализацию фичи, потому что чёрт ногу сломит в низкоуровневом коде.
Извините, но статья больше похожа на "в С++ есть интерфейс для аллокаторов, выглядит вот так, можно делать разные прикольные штуки"
Вот библиотека с кастомными аллокаторами, там в ридми в разы больше информации - https://github.com/mtrebi/memory-allocators
Пользуясь случаем, прорекламирую своё расширение для VS для генерации доксиджен комментариев в C++ коде. Функционал намного шире, чем дефолтный в студии, большие возможности для кастомизации и бесплатность.
https://marketplace.visualstudio.com/items?itemName=NickKhrapov.DoxygenComments2022
Всем хорошей документации кода.
А я помню, как мелкомягкие рассказывали, что новой винды не будет и десятка будет развиваться через обновления
Благодарю
Я правильно понимаю, что движок будет нормально работать только при "axis aligned" пространстве, а если у меня геоид, то я иду лесом? Что посоветуете использовать в таком случае?
Ваш способ просто неверный, OpenGL не разрешает доступ к одному контексту из разных потоков
То, что это работает на вашей машине, не гарантирует, что оно не развалится у соседа
Я думал, сейчас почитаю статью про создание нового контекста на другом потоке и шаринге ресурсов между ними (а это правильный способ сделать то, что вы хотите сделать), но был несколько разочарован
Кажется, вы изобрели magic_enum
Я бы ещё добавил Kenshi. Чувак пилил игру 12 лет и только на заключительных этапах добавил рабочей силы, игра очень хорошо выстрелила
А не помню =) Стоит поправить, да, или вынести инициализацию из ленивой в "при старте программы"
А в хедере моего файла указан источник, вероятно вы его и видели. Взял его за основу и сильно модифицировал.
Да, я имел в виду именно проблему с динамическими библиотеками
Честно говоря, я сам не копал так глубоко, чтобы самостоятельно ковырять все компиляторы и пилить бенчмарки, но читал некоторые статьи, плюс видел, что на каждом моём месте работы (геймдев) была своя похожая замена RTTI, в т.ч. это UE.
Конечно, возможно, что все эти люди и замеры неправы, а рандомный чел из инета - прав, но что то я сомневаюсь =)
Вы имеете в виду производительность? Нет. RTTI зачастую вообще реализуется через сравнение строк (названий классов), оверхед использования vtable по сравнению с этим - пыль.
Я не совсем понял, зачем прибивать гвоздями классы к их отражению в виде enum - разве что вам очень сильно хочется вынести это в constexpr
В своей реализации я вынес этот "айди" класса в статический член, который генерирует новый айди для каждого класса, и делает это при запуске программы - автоматически, конечно
В итоге всё работает только на виртуальных методах без хранимого объекта айдишника вообще, и при этом очень легко расширяемо - нужно только добавить макрос в класс, примерно как в qt
Это называется trailing return type и он может быть использован в любой функции
Ну классика, защитим детей от интернета. Что бы мы делали без подобных инициатив, подумать страшно.