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

Пилим движок Arcanum. Урок 03. Работа с памятью, используем полиморфные аллокаторы

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров7.4K
Всего голосов 14: ↑12 и ↓2+14
Комментарии11

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

Мне это так нравится, что я даже зарегистрировался здесь и подписался :) Надеюсь, в итоге получится крутой движок!

Было бы интересно узнать, насколько ваша реализация получилась быстрее обычного new?

Спасибо. Мне уже посоветовали сделать бенчмарк. Обязательно сделаю, в том числе, запущу на древнем железе и древней ОС.

Жалуется на медленный new. Реализует свой new через виртуальные функции.

Проблема не во времени вызова new как функции. А именно в аллокации памяти. Используя линейный буфер я гарантировал время аллокации О(1) при любом количестве объектов и любого размера.

Cтандартный аллокатор неизбежно сделает что-то вроде:

  1. установит мьютекc или применит любой другой доступный способ синхронизации

  2. обратится к ОС за памятью

  3. ОС выполнит довольно заковыристый алгоритм для поддержания структуры данных heap'а.

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

По сравнению с этим, вызов виртуальной функции (всего-то два перехода по указателю) - просто капля в море. Современные компиляторы этот вызов еще и зачастую девиртуализировать могут.

Спасибо за подробный ответ. Полностью согласен.

Возможно это будет несколько нагло, но я хочу попросить автора сменить язык проекта на что угодно кроме C и Cpp.
Являюсь практикующим программистом (основной язык go, но бывают таски на самых разных от раста и js до zig и odin) и тем не менее несмотря на несколько часов попыток не смог собрать проект с cmake. Хотел попробовать поконтрибьютить что-то полезное, но такие ситуации крайне демотивируют и загоняют в депрессию.
Искренне не понимаю почему в 2024 году нельзя использовать более читаемые и не требующие колдовства при сборке языки.

и тем не менее несмотря на несколько часов попыток не смог собрать проект с cmake

Вы имеете в виду вообще проект на С++ или мой проект не смогли собрать?

Возможно это будет несколько нагло, но я хочу попросить автора сменить язык проекта на что угодно кроме C и Cpp.

Я вас понимаю, но это сделать это не хочу и не могу. Так как банально потеряется переносимость на множество устаревших платформ и архитектур, в том числе для старых консолей. И мне просто не интересно, продолжать проект на другом языке.

Искренне не понимаю почему в 2024 году нельзя использовать более читаемые и не требующие колдовства при сборке языки.

Не согласен, cmake довольно серьезный и проверенный проект. И очень серьезно упрощает сборку проекта несколькими строками.

Ваш, большинство собираются и не выносят мозг. Уверен что любой язык на llvm скомпилируется под любую старую консоль. Он серьезный и проверенный, но нечитаемый и недружелюбный.

Я сегодня проверю и исправлю сборку, во всех уроках. Возможно, что то не досмотрел.

Проверил все уроки, все собирается. @gohrytt вы можете прислать описание ошибки?

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

Публикации

Истории