А, тю. Ну в моей система это элементарно реализуется прямо в шейдерах.
Все эти крутилки. Единственное что - задавать их придётся конечно не так, как в кутрёх, иной синтаксис. Но тут как бы тоже не всё печально. В моей системе ведь есть макросы! так что можно очень даже близко переопределить всё. Я конечно потом проверю, аж самому интересно стало.
Я тут принял решение отказаться от всех этих кастомных аллокаторов памяти, в настоящее время они практически неактуальны. Простенький лик-детектор еще можно оставить, но не более того. Я тут проанализировал код и понял, что мемпулы у меня используются только при загрузке моделей, а всё остальное прекрасно в деструкторах высвобождается. Ну то есть городить огород нет смысла. Для моделей я мемпулы завернул в класс, там это всегда полезно - посмотреть сколько памяти занимает та или иная модель, а остальное интереса не представляет.
XaeroX маллок обычный. Вообще-то в CRT есть своя куча. Вот пусть и разбираются там. Я же говорю, после того как все рассчёты переместились на GPU, единственное что неплохо бы кастомизировать это модели.
Кармака понять можно, он для теневых объемов временные буфферы на кадре аллокал постоянно. Конечно ему кастомная куча была нужна.
Сейчас память аллокается только при загрузке, во время работы - нет.
Ну так и смысл городить аггарот?
Тебе приятно работать с чёрными ящиками? А если там завтра что-то сломают, то ты гордо пожмёшь плечами и скажешь "я ничо не знаю, пишите в суппорт майкрософт"?
Так оно и бывает. Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.
Цитата:
Дядя Миша писал: маллок обычный. Вообще-то в CRT есть своя куча.
Это понятно, но в конечном итоге под виндой всё сводится к системному вызову в VirtualAlloc.
Добавлено 24-10-2019 в 18:26:
Цитата:
Дядя Миша писал: во время работы - нет.
Во время работы можно кешировать разные промежуточные результаты. Когда куча кастомная - ты всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш. А потом - если она кому-то понадобилась в обычном аллоке - этот кеш грохать по принципу FIFO.
Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока? Ну там объявить гигантский статичный массив и черпать память из него, пока не кончится?
Цитата:
XaeroX писал: Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.
ну не надо. Ты имплементацию ZIP сам писал или всё же zlib используешь? Совсем без сторонних библиотек не получится. Вот когда PVS в сторонней библиотеке, это конешно трогедия.
Цитата:
XaeroX писал: ы всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш
Твой хитрый план определённо имеет значение, если мы активно выделяем память во время рендеринга. Но если мы этого не делаем, то и смысла нет.
Цитата:
XaeroX писал: всё сводится к системному вызову в VirtualAlloc
Я к слову почти не видел менеджеров, построенных на вызовах VirtualAlloc, видимо для портабельности. malloc то везде есть.
Ну даже если таковые и существуют, мне неизвестно чтобы они прям хорошо-хорошо работали, пуще прежнего. Конечно мне несложно эту кучу из Doom3 опробовать в деле и я вероятно это сделаю. Но навряд ли будет толк в 2019-м году.
Дядя Миша писал: Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока?
Нет, вообще без маллока конечно же обойтись нельзя, но можно выделить сразу много страниц, а потом самим ими управлять, а не доверять это библиотеке, в исходниках которой чёрт ногу сломит.
Да не в исходниках дело. Эти маллоки сделаны универсальными, подходящими под любые задачи. Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?
Цитата:
Дядя Миша писал: Ты имплементацию ZIP сам писал или всё же zlib используешь?
Я использую её в виде исходного кода, а не либы.
Цитата:
Дядя Миша писал: Совсем без сторонних библиотек не получится.
Я понимаю - zlib, ogg-vorbis, даже lua какая-нибудь, тут нет смысла изобретать велосипед.
Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.
XaeroX писал: Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?
Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.
Цитата:
XaeroX писал: Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?
Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы. А если и выделять, то самый минимум, под списки там какие-нибудь.
Цитата:
XaeroX писал: Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.
Вы сегодня прямо все расшутились как не знаю кто. В процессоре контролерр памяти и защищенный режим, который тебя никогда не пустит в реальную ячейку физической памяти, а сверху слой абстракции от операционки, которая следит, что ты там навыделял и если что-то не так - кидается исключение, а не виснет весь комп нахрен. И вот в таких вот условиях ты что-то там за максимальный контроль агитируешь?
Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать? Ну скажем, на примере Волатилы.
Дядя Миша писал:
Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.
Я, признаться, бесконечно был бы RAD
Лечь под этот электронный агрегат,
Чтобы капал самогон мне в VIS
Днём и ночью BSP!
Цитата:
Дядя Миша писал: Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы.
Ну ты не будешь выделять, а потом придёт Мастер и прикрутит асинхронную загрузку моделей...
Цитата:
Дядя Миша писал: Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать?
Я уже привёл пример с кэшем. Приведу другой: в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их. Т.к. у кваров значения обычно либо пустые, либо 0/1/2, то это позволяет избежать от 20% до 30% аллокаций на куче.
XaeroX писал: а потом придёт Мастер и прикрутит асинхронную загрузку моделей...
для моделей я оставил мемпулы, говорю жеж. Для остального считаю излишним.
Цитата:
XaeroX писал: в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их.
Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.
И получим Unknown software exception или что-то в этом роде. Но для чистого Си с кучей, вполне норм вариант.
Цитата:
XaeroX писал: Я уже привёл пример с кэшем
У меня стойкое подозрение, что твои знания по кэшу больше относятся к 90-м и нулевым годам. Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.
Дядя Миша писал:
Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.
Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString, эту ситуацию разруливает.
Цитата:
Дядя Миша писал: Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.
Ну понятно, когда есть гигантский L3, то это не то же самое, как фетчинг из оперативки. Но тем не менее.
Я где-то на хабре видел статью вот как раз по архитектуре коры дуба и она полностью мои представления перевернула. Ну точнее привела в соответствие с современным железом.
Добавлено 24-10-2019 в 17:01:
Цитата:
XaeroX писал: Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString
ага, это если мы городим фабрику. Ну или как эта херь правильно называется. Но это именно Сишное мышление. Кресты навязывают маленькие локальные АТД.
Добавлено 24-10-2019 в 17:01:
Цитата:
XaeroX писал: Ну понятно, когда есть гигантский L3
щас вообще существуют процы с L3 менее 16 метров? Мне кажется там уже за сотню перевалило.
| IP: 
23-10-2019 19:43
