Сами по себе — это библиотечные вызовы (с этим и правда косяк).
Однако в конечном счете получить память для процесса все равно необходимо, поэтому системный вызов сделать хоть раз придется. А теперь представим, что это случилось не в подходящий момент — вуаля, все так же плохо :)
Не берусь утверждать, как работает компилятор на платформе от Майкрософт, однако clang на MacOS дает следующее: void* p = 0; void* d = nullptr; p == d? (it is true). Получается что 0 — это и валидное значение, и одновременно null идентификация. Плюс, насколько я понимаю, заявляется возможность линковки с С библиотеками, следовательно передавая nullptr как аргумент вызова любой функции, это как никак должен быть 0, в С ведь nullptr просто нет.
(поправьте меня, пожалуйста, если с чем-то наврал)
Это проблема не столько Майнкрафта, сколько создателей проекта, которые так и не определились, что это должно быть: телега для модов или нет. Безусловно, любая игра с динамической подгрузкой локация будет насиловать runtime, однако если это не критично, то стоит на это забить) Смотрел, как ребята делаю инди проекты, хорошие игры с 3D для десктопа, и средняя джава с 2GiB памяти спокойно их запускает
Наверное, лучше было на java пример с шахматами приводить, тогда точно бы проблем не было)
Не сложно придумать ситуацию, в которой Майнкрафт начнет тормозить.
Изначально, когда вы запускаете игру из коробки (как это было давно давно), модов, шейдеров у вас нет. Разумеется, вы все это добавляете и благополучно нагружаете систему.
Посыл был не в том, что на Java Майнкрафт не тормозит, а скорее в том, что на Java можно и нужно делать игры, если требования по производительности это допускают. Если бы в Майнкрафт была четко сформулированная функциональность и проработанная архитектура, то проблем было бы меньше.
Безусловно, согласен с вами.
Под 'иметь только 1' я понимал именно работу с этим unique ptr. Никто не сможет запретить вам из сырого C ptr сделать несколько unique ptr и выстрелить себе в ногу (обязательно это добавлю).
И про передачу прав владения и просто передачу как аргумента — вы хорошо подметили. Но это уже скорее к вопросу о том, как использовать умные указатели, что лучше описывается в соответствующей литературе
Я бы и рад приложить код на asm, да вот только не очень много опыта в написании программ именно на этом языке. На С/С++ реализация, которую лично делал, не достойна внимания, так как код в целом не очень документирован и презентабелен.
Приложил ссылку на стороннюю реализацию, так как это 1) хороший пример, заслуживающий упоминания 2) это показывает, что тема развита, и можно в интернете еще много реализаций аллокаторов на C++ найти :)
Что вы понимаете в первом пункте под ' отсутствие физической непрерывности аллокаций'?
Имеется ввиду, что реально в ОЗУ данные не подряд лежат? Если я правильно понял, когда мы работаем скажем с OpenGL, Vulkan, нам так и так приходиться пересылать данные с RAM на VRAM. Если оперировать в этих категориях, то контролировать это процесс более мы не можем, разве что минимизировать кол-во пересылок. На этом фоне, думаю, мы можем пожертвовать физической разрозненностью, хоть это и проблема, но не такая критичная, как частая пересылка данных. (если вы об этом, конечно)
Очень хорошее замечание. Совсем не вспомнил про это в процессе написания статьи.
На самом деле, это обыденная вещь. Минимальный размер важен, так как хотим попадать в кэш. Но и не забываем про то, что процессору удобнее в выровненными под машинное слово полями работать. К тому же, иногда требуется отображать структуры из CPU на GPU, там тоже свои подвохи есть.
Так что надо будет обязательно это добавить)
Однако в конечном счете получить память для процесса все равно необходимо, поэтому системный вызов сделать хоть раз придется. А теперь представим, что это случилось не в подходящий момент — вуаля, все так же плохо :)
(поправьте меня, пожалуйста, если с чем-то наврал)
Наверное, лучше было на java пример с шахматами приводить, тогда точно бы проблем не было)
Изначально, когда вы запускаете игру из коробки (как это было давно давно), модов, шейдеров у вас нет. Разумеется, вы все это добавляете и благополучно нагружаете систему.
Посыл был не в том, что на Java Майнкрафт не тормозит, а скорее в том, что на Java можно и нужно делать игры, если требования по производительности это допускают. Если бы в Майнкрафт была четко сформулированная функциональность и проработанная архитектура, то проблем было бы меньше.
Под 'иметь только 1' я понимал именно работу с этим unique ptr. Никто не сможет запретить вам из сырого C ptr сделать несколько unique ptr и выстрелить себе в ногу (обязательно это добавлю).
И про передачу прав владения и просто передачу как аргумента — вы хорошо подметили. Но это уже скорее к вопросу о том, как использовать умные указатели, что лучше описывается в соответствующей литературе
Приложил ссылку на стороннюю реализацию, так как это 1) хороший пример, заслуживающий упоминания 2) это показывает, что тема развита, и можно в интернете еще много реализаций аллокаторов на C++ найти :)
Что вы понимаете в первом пункте под ' отсутствие физической непрерывности аллокаций'?
Имеется ввиду, что реально в ОЗУ данные не подряд лежат? Если я правильно понял, когда мы работаем скажем с OpenGL, Vulkan, нам так и так приходиться пересылать данные с RAM на VRAM. Если оперировать в этих категориях, то контролировать это процесс более мы не можем, разве что минимизировать кол-во пересылок. На этом фоне, думаю, мы можем пожертвовать физической разрозненностью, хоть это и проблема, но не такая критичная, как частая пересылка данных. (если вы об этом, конечно)
Очень хорошее замечание. Совсем не вспомнил про это в процессе написания статьи.
На самом деле, это обыденная вещь. Минимальный размер важен, так как хотим попадать в кэш. Но и не забываем про то, что процессору удобнее в выровненными под машинное слово полями работать. К тому же, иногда требуется отображать структуры из CPU на GPU, там тоже свои подвохи есть.
Так что надо будет обязательно это добавить)