Войти
ФлеймФорумПрограммирование

[C++] Как такая фигня с дизайном языка получилась? (10 стр)

Страницы: 16 7 8 9 10 11 Следующая »
#135
18:43, 7 июля 2019

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

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


#136
(Правка: 18:47) 18:46, 7 июля 2019

}:+()___ [Smile]
> Когда типов много, то память, зарезервированная под один тип, не может быть
> использована под другой — это, по сути, фрагментация, причем в наихудшем ее
> проявлении.

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

#137
20:31, 7 июля 2019

Dmitry_Milk
> Строки выделять независимо, указатели на них - в другой Y-массив, то есть
> просто вместо дереференса со сложением [y*width+x] будет двойной дереференс
> [y][x].
Это сосёт по производительности. По причине хреновой локальности. А хорошая локальность - это, внезапно, именно то, ради чего затевалась борьба с фрагментацией.

#138
20:32, 7 июля 2019

Dmitry_Milk
> Так с обычным универсальным аллокатором проблема та же и останется, только он
> еще и работает медленнее.
Он в среднем отлично работает по скорости.
Сделать более быстрый пул в отдельном случае - никто не запрещает.

Dmitry_Milk
> Так с обычным универсальным аллокатором проблема та же и останется
Это проблема есть у любого неперемещающего аллокатора.
А перемещающий - это двойная индирекция на каждое разыменование.

#139
20:47, 7 июля 2019

Dmitry_Milk
Я думал ты решение проблемы фрагментации предлагаешь. А пулы по размеру объектов - популярная штука, многие аллокаторы ее используют. Дельфийский, например. Но она неуниверсальная.

#140
20:57, 7 июля 2019

kipar
Универсального решения нет и не предвидится.

#141
(Правка: 21:04) 21:03, 7 июля 2019

totoro
Ну да, и я о том же.

#142
23:48, 7 июля 2019

kipar
> Я думал ты решение проблемы фрагментации предлагаешь

Нет, я предлагал перестать видеть в фрагментации злостную проблему, т.к. от ее основных "злобностей" можно избавиться, соблюдая некоторые ограничения и не избавляясь от нее самой (и не делая за счет этого аллокацию тяжелой задачей, на что было посетовано на седьмой странице).

#143
0:37, 8 июля 2019

Dmitry_Milk
Ну так твое предложение не решает проблемы фрагментации. Что же за такая "злобность" от которой нас спасут пулы?

#144
0:58, 8 июля 2019

Dmitry_Milk
Так а что ты предлагаешь? О(1)-аллокацию? Ну так тут тоже нет проблемы.

#145
5:16, 8 июля 2019

kipar
> потом выгрузили каждую четную
Ну хрень же. Как часто такое в жизни встречается? Обычно, если ты навыделял разом много данных, то они как-то связаны между собой, а значит и удаляться будут вместе.

> и теперь хотим загрузить кучу больших текстур.
Опять же, странный случай. Обычно данные программ более-менее однородные, а значит ты будешь грузить новые текстуры +- такого-же размера.

#146
(Правка: 8:19) 8:18, 8 июля 2019

kipar
> Что же за такая "злобность" от которой нас спасут пулы?

Не пулы. Еще раз, исходно я предложил не изменения в аллокатор, а ОГРАНИЧЕНИЯ. А именно - запретить аллоцировать области произвольных размеров, запретить malloc(N байтов), разрешив только аллокацию типов, известных на этапе компиляции (в том числе и массивов заранее известных размеров).

А "злобность" - тот вред от фрагментации, на который указали на 7 странице - полное выедание памяти при постоянной вновь возникающей фрагментации (#101). А при соблюдении вышеуказанных ограничений принципиально невозможно постоянное нарастание вреда от фрагментации - с определенного момента любой тип сможет сразу же гарантированно переиспользовать память.

#147
8:23, 8 июля 2019

Dmitry_Milk
ты попробуй меньше фантазировать и больше писать (код, не прозу). в том же PS4 вообще аллокатора памяти нету, тебе даётся один кусок на 5Gb(ram + vram) и ты с ним делаешь всё что хочешь, с какими хочешь ограничениями. да или хотя бы на вулкане память менеджится подобным образом, возьми да попробуй.

#148
8:47, 8 июля 2019

Dmitry_Milk
> А при соблюдении вышеуказанных ограничений принципиально невозможно постоянное
> нарастание вреда от фрагментации
Я ничего не понял.
Проблема фрагментации состоит в том, что в какой-то момент приложение падает с нехваткой памяти, нет никакого "нарастания вреда" - мы просто в какой-то момент падаем. И твои ограничения этого не предотвращают. Я даже почти уверен что они по факту соблюдаются - никто же обычно и не аллоцирует массивы произвольной длины. Векторы аллоцируют память размера sizeof(void*)*2^n, строки - 2^n (ну или не 2ч там свои нюансы), в общем есть вполне дискретный набор размеров.

#149
8:59, 8 июля 2019

Suslik
> ты попробуй меньше фантазировать и больше писать (код, не прозу)

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

Страницы: 16 7 8 9 10 11 Следующая »
ФлеймФорумПрограммирование