Как стать автором
Обновить

Как протащить верблюда сквозь игольное ушко, или обновление компилятора С++ на проекте старше 10 лет

Время на прочтение12 мин
Количество просмотров21K
Всего голосов 78: ↑78 и ↓0+78
Комментарии29

Комментарии 29

Добрый день, а у вас уже появился опыт использования EASTL?

Действительно переход с stl дает заметный выигрыш в реальных сложных приложениях? Спасибо.

Масштабно заменять nstl, на котором построен проект, на eastl нет смысла. Долго, очень багоопасно, профит, возможно, и будет, но есть сомнения, что грандиозный. Из того, что сравнивал, собственный nstl::hash_map при обработке нанонапильником оказался практически аналогичным eastl::hash_map, местами чуть быстрее. Правда пришлось масштабно перепилить итерирование, сильно отставало из-за кривой реализации.

Если же говорить именно о std::stl, то у EA есть же много сравнений, там прирост местами очень значительный. Мы просто не используем std. Сейчас у нас гибрид из nstl и eastl. Что касается самого eastl, безусловно, очень гибкий инструмент в критичных к производительности проектах. Однозначно, must have.

Спасибо!
>> то у EA есть же много сравнений, там прирост местами очень значительный

Но это их сравнения :) . Хотелось услышать вашу оценку.

Как я уже сказал, в проекте мы std не используем. По сравнению с nstl удобнее в плане гибкости, в плане быстродействия преимуществ особых нет, только, если в nstl нет откровенного косяка, а они там встречаются. У меня есть планы провести отдельное небольшое сравнение нескольких реализаций stl с eastl, тогда смогу ответить более предметно. Но их результатам сравнений, имхо, можно доверять.

EASTL нужен в первую очередь не для выигрыша в производительности, а для совместимости и предсказуемости.
Когда вы собираете код на разных платформах/компиляторах/процессорных архитектурах, меньше всего вы хотите увидеть различное поведение std.

Сейчас с этим проще, т.к. везде можно использовать Clang.

Ну на самом деле по поводу приоритетов здесь не всё так однозначно. Для игр, например, попугаи имеют не менее определяющее значение, чем предсказуемость поведения "стандартных" шаблонов на разных платформах и архитектурах. Возможно, как раз производительность ставится во главу угла, а однозначность поведения идёт важным приятным бонусом.

Неплохо, я думал вылезет больше ошибок. А так, в общем-то, практически ничего менять и не пришлось. Круто

Дорогу осилит идущий.

Караван в игольном ушке

Ваша картинка даже лучше бы подошла. )))

После просмотра работ Владимира Анискина других ассоциаций быть не может ;)

Я думал все игры умирают сразу после покупки их mail.ru)

Хотя, прочитав книгу "Нажми Reset. Как игровая индустрия рушит карьеры и дает второй шанс", Книга, Джейсон Шрейер, понял, что все большие компании имеют эту проблему)

Да и не только большие. Можно почитать книгу Кушнера про Doom. Небольшие студии тоже этим страдают.

У АО был момент жесткой завязки на донаты. Где ты не имел high-level контента без денежек на счёте. Точно не помню когда это появилось - прямо перед покупкой mail или сразу после, но такой момент был.

Очень интересный материал! Спасибо!

Успехов в дальнейшем развитии Аллодов!

Если бы вы видели хотя бы одну из версий C++ Builder, выпущенных за 20 лет с момента релиза шестерки, то, возможно, не удивлялись бы :)

А переезд на другой фреймворк это всегда дорого (иногда, очень дорого, если у вас миллионы строк кода) и далеко не всегда оправданно.

Почему-то вспомнился анекдот про мужика, которому жена звонит, чтобы сказать, что по радио передали, что один водитель едет против движения… :)

Как мы видим, в сборках Visual C++ 2010 и Visual C++2019 раздел импорта отличается. Debug-версии отличаются только наличием sized-версии operator delete в сборке Visual C++ 2019, а вот в Release-сборке версии 2019 вообще отсутствуют operator new/delete. Это отдельный интересный вопрос, который стоит задать компилятору и линковщику.

А какой тут вопрос? Вызов стандартный. Исключения отключены. Вызов только одной функции с параметром без преобразований. Компилятор честно считает, что не зачем городить обертку над функцией, если никаких выделений и преобразований нет. Все просто. Компилятор прав. А линковшику пофиг))

Ну компилятор VS2010 находится в тех же условиях, однако, он не увидел, что от обёртки можно избавиться.

Ну тогда это не проблема VS2019, это проблема VS2010.

Современный C++ очень сильно полагается на оптимизатор

В статье упоминается как msvc, так и mingw. Так чем собираете в итоге? Cmake осилили или все-таки нет?

Ответ на первый вопрос, очевидно, следует из названия статьи. Ну а второй отпадает, ввиду ответа на первый.

Почем второй отпадает? У меня CMake отлично переваривает генерацию сборки под MSVC/ClangCL. Без никаких проблем

Да уж, цирк с конями да и только. Но вывод очевидный - регулярно обновляйте компилятор, это, как минимум, позволит вам обнаружить и избавиться от ошибок в вашем коде.

Почему клиентское приложение аллодов показывает красное качество работы клиентского приложения при этом не утилизируя полностью видеокарту и процессор?

Это проблема. Видеокарта, действительно, юзается, мягко говоря, не на все деньги. Процессор, наоборот, на все, но только одно ядро. Об этом уже шла речь в комментариях.

4. Получили возможность дальнейшей оптимизации кодовой базы проекта на основании последних нововведений стандартов C++11/14/17

Расскажите, про успех оптимизации с использованием новых стандартов. Это уменьшение строк кода, читабельность, быстродействие?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий