информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаСтрашный баг в WindowsАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
- delimiter, поправки? :( 18.06.01 09:49  Число просмотров: 915
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> метод первого встречного - хорошо конечно
> ( но почему не второго ,третьего...etc) (алгоритм смены
> лучшего не проблема) пройтись до первого встречного или по
> всему "массиву"
> ....я думаю не критично

...... sousce skip............

> а соединение соседних свободных в один , это слабое но
> выигрывающее
> по времени подобие сборке мусора (cистема при использовании
> метода
> выборки лучшего самоорганизована)

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

вот собсна и вся задача...
<programming>
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 15.06.01 16:57  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
привет всем.

задача такая. надо написать свой Memory Manager, который контролирует кучу, через которого объекты получают память с помощью оператора new и удаляются, точнее возвращается обратно куче, с помощью delete.

иначе говоря - сначала резервируем вольшой кусок памяти - куча, скажем на 8Kb - HEAP. теперь, вызываем new и пытаемся получить пространство размером в 256 байт -Block. в операторе new, перенаправляеться на MemManager.

MemManager ищет внутри 8Kb (HEAP) свободное место, помечает его как используемое, помечает используемый размер (256), если нужно делает пометки, для внутреннего использования и возвращает указатель на начало блока (Block). т.е. каждый HEAP содержит внутри n-ое кол-во Block.

при освобождении, т.е. вызов - delete Block, смотрит из какой кучи (HEAP) он выдавал Block, помечает Blockкак свободный, или происходит слияние этого блока с предидущим/последуюущим если они тоже помечены как свободный. естественно увеличивая размер свободного пространства + 256.

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

у кого будут другие предложения, может кто занимался подобным?

и еще. будь он связанный список или еще какой объект, он должен быть внутренний. и вызов операвтора new не разрешен, т.к. пойдет рекурсия - MemManager сам конролирует new / delete.

не знаю на сколько понятно все изложил, думаю те кто писали подобное поняли о чем речь. а если кто не понял, спрашивайте, не стесняйтесь :-)))
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 18.06.01 17:55  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 18.06.01 18:03  Количество правок: 1
<"чистая" ссылка>
> привет всем.

[skip]
>
> иначе говоря - сначала резервируем вольшой кусок памяти -
> куча, скажем на 8Kb - HEAP. теперь, вызываем new и пытаемся
> получить пространство размером в 256 байт -Block. в
> операторе new, перенаправляеться на MemManager.


> MemManager ищет внутри 8Kb (HEAP) свободное место, помечает
> его как используемое, помечает используемый размер (256),
> если нужно делает пометки, для внутреннего использования и
> возвращает указатель на начало блока (Block). т.е. каждый
> HEAP содержит внутри n-ое кол-во Block.
>
> при освобождении, т.е. вызов - delete Block, смотрит из
> какой кучи (HEAP) он выдавал Block, помечает Blockкак
> свободный, или происходит слияние этого блока с
> предидущим/последуюущим если они тоже помечены как
> свободный. естественно увеличивая размер свободного
> пространства + 256.
>
> теперь вопрос. естественно как то надо вести учет
> свободного простраиства, и держать информацию о всех
> блоках. есть вариант всю инфу собирать и контролировать
> через связанные списки, не трудный вариант, но он плох тем
> что на поиск блока внутри кучи тратиться время и не малое.
>
> у кого будут другие предложения, может кто занимался
> подобным?
>
> и еще. будь он связанный список или еще какой объект, он
> должен быть внутренний. и вызов операвтора new не разрешен,
> т.к. пойдет рекурсия - MemManager сам конролирует new /
> delete.
>
> не знаю на сколько понятно все изложил, думаю те кто писали
> подобное поняли о чем речь. а если кто не понял,
> спрашивайте, не стесняйтесь :-)))

Пара замечаний:

1)Ты видимо решил отказаться от весьма удобной привязки памяти к страницам с
аппаратной поддержкой функции защиты страниц,и сделать т.н. "общий случай"
т.е. ты в случае BOF легко сможешь разрушить всю внутреннюю структуру своего
хипа - я в аналогичной ситуации привязывался таки к страницам и заголовки
блоков держал в защищеных от записи страницах (mprotect() -ом) что по крайней мере гарантировало целостность внутренней структуры а заголовки блоков разблокировались только при операциях выделении/освобождении памяти - минус такого подхода это минимальный размер блока в 8кв

2) c точки зрения скорости двунаправленного связянного списка сейчас хватает за
глаза ... а вот с точки зрения оптимизации фрагментации удобнее деревья
(оптимальный поиск подходящего блока и простота слияния 2-х соседних своботных)

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

то есть ты хранишь 2-набора указателей и любая операция с памятью будет приводить к изменениям в 5-блоках

но повторю - это извращения - юзай связанные списки - скорости у них хватит ...
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 19.06.01 09:34  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> Пара замечаний:
>
> 1)Ты видимо решил отказаться от весьма удобной привязки
> памяти к страницам с
> аппаратной поддержкой функции защиты страниц,и сделать т.н.
> "общий случай"
> т.е. ты в случае BOF легко сможешь разрушить всю внутреннюю
> структуру своего
> хипа - я в аналогичной ситуации привязывался таки к
> страницам и заголовки
> блоков держал в защищеных от записи страницах (mprotect()
> -ом) что по крайней мере гарантировало целостность
> внутренней структуры а заголовки блоков разблокировались
> только при операциях выделении/освобождении памяти - минус
> такого подхода это минимальный размер блока в 8кв

весь это разговор ведется в контексте известной тебе задачи....
а для Nt KernelMode реализовать защиту на уровне страниц на мой взгляд не самая хорошая идея...

> но повторю - это извращения - юзай связанные списки -
> скорости у них хватит ...

о чем и говорили большевики... ;))
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 19.06.01 01:25  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
>
> Пара замечаний:
>
> 1)Ты видимо решил отказаться от весьма удобной привязки
> памяти к страницам с
> аппаратной поддержкой функции защиты страниц,и сделать т.н.
> "общий случай"
> т.е. ты в случае BOF легко сможешь разрушить всю внутреннюю
> структуру своего
> хипа - я в аналогичной ситуации привязывался таки к
> страницам и заголовки
> блоков держал в защищеных от записи страницах (mprotect()
> -ом) что по крайней мере гарантировало целостность
> внутренней структуры а заголовки блоков разблокировались
> только при операциях выделении/освобождении памяти - минус
> такого подхода это минимальный размер блока в 8кв

ну почему. защита интересует. поподробней о защите можешь сказать. хотя думаю так или иначе если захотеть похерить можно.

> но повторю - это извращения - юзай связанные списки -
> скорости у них хватит ...
уже кажется пришел к такой мысли.
[C++] про защиту... 19.06.01 12:13  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> ну почему. защита интересует. поподробней о защите можешь
> сказать. хотя думаю так или иначе если захотеть похерить
> можно.

Как я понял cb - реализовывать аппаратную защиту придется в kernel mode NT
- а это вызывает дополнительные сложности ...
по идее можно логически разнести выделяемую память и заголовки в разные концы
линейного буфера (так как в процессе живут стек и хип) ... но ImHO логической
защиты недостаточно ... так что ты прав - без апарратной поддержки защиты действительно все можно похерить ...
[C++] про защиту... 19.06.01 17:56  
Автор: Бяша <Biasha> Статус: Member
<"чистая" ссылка>
> > ну почему. защита интересует. поподробней о защите
> можешь
LPVOID VirtualAlloc(
  LPVOID lpAddress,        // region to reserve or commit
  SIZE_T dwSize,           // size of region
  DWORD flAllocationType,  // type of allocation
  DWORD flProtect          // type of access protection
);

---
Сначала вызываешь её с MEM_RESERVE, а по мере выделения new памяти с MEM_COMMIT. В обоих случаях можешь указывать атрибут защиты.
Как уже писали - единственная проблема 8кб'ый минимальный блок.

> > сказать. хотя думаю так или иначе если захотеть
> похерить
> > можно.
Если сменить атрибут доступа.

> Как я понял cb - реализовывать аппаратную защиту придется в
> kernel mode NT
Тогда я не понял что за защита имелась ввиду?
[C++] про защиту... 19.06.01 18:11  
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 19.06.01 18:14  Количество правок: 1
<"чистая" ссылка>
> > > ну почему. защита интересует. поподробней о
> защите
> > можешь
>
LPVOID VirtualAlloc(>   LPVOID lpAddress,	   // region to reserve or commit
>   SIZE_T dwSize,	   // size of region
>   DWORD flAllocationType,  // type of allocation
>   DWORD flProtect	   // type of access protection
> );

---
> Сначала вызываешь её с MEM_RESERVE, а по мере выделения new
> памяти с MEM_COMMIT. В обоих случаях можешь указывать
> атрибут защиты.
> Как уже писали - единственная проблема 8кб'ый минимальный
> блок.
>

Это только в UserMode...
см. комментарий cb

> > > сказать. хотя думаю так или иначе если захотеть
> > похерить
> > > можно.
> Если сменить атрибут доступа.
>
> > Как я понял cb - реализовывать аппаратную защиту
> придется в
> > kernel mode NT
> Тогда я не понял что за защита имелась ввиду?

...та самая но только средствами ядра NT ....
Linux к примеру это умеет ... я подозпеваю что и NT должна уметь


BTW: вроде бы у win2k что то было на эту тему но довольно криво в плане управления ...
цитирую cb:

"В Win2k появилась защита ядра от записи на уровне страниц. Для того чтобы
разрешить запись,
необходимо внестии соответствующие изменения в реестр:
НKLM\System\CurrentControlSet\Control\Session Manager\Memory
Managment\EnforceWriteProtection = 1"
[C++] про защиту... 19.06.01 18:05  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> > Как я понял cb - реализовывать аппаратную защиту
> придется в
> > kernel mode NT
> Тогда я не понял что за защита имелась ввиду?

защита на уровне страниц... ее можно реализовать и в KernelMode.
2 all - delimiter, sandy. поправки !!! 17.06.01 04:52  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Народ,

с самого начала ЗАБУДЬТЕ про какую либо ОС, будь это Вин, *НИХ, или хрен ..... не связывайте это ни с каким ОС, забудьте про какой либо системный сборщик мусоров, налогов, рекет и прочее явление. Нет никакого виртуального поинтера - это тоже не волнует. так же не волнует как запрашивать память у системы. волнует ЛИШЬ котроль памяти, который я УЖЕ имею у себя.
речь идет о сугубо "ЛИЧНОМ" манагере.

вся суть такая - система выделяет память - на это уходит время. я хочу выделить БОЛЬШОЙ кусок память, чтобы каждый раз не запрашивать у системы по 20-30 байт или 1Кб. и "МНЕ" надо контолировать память - и только "МНЕ", а не системе. Надо котролировать от выделения блоков, до мемори ликов. Заметьте, вынужден повториться, это не Вин, это тем более не МФС, это не *НИХ, это не МАК и пр. Согласитесь, в такой задаче, ОС обсалютно не имеет значения.

2 Delimiter и 2 + :
насчет связанных листов понятно - как не крути, вынужден идти методом "первого встречного". потому как на сортинг и на поиск теряю много времени.
как соединять куски в листе и как проверки делать - это тоже понятно, более того часть кода уже реализована и работает. но не знаю, а может пока не знаю, можно ли там что либо оптимизировать. это потом будет видно.

2 Sandy:
Node-ы в листе в ТАКОЙ ситуации создаются не через
Node* pNode = new Node,
а из того куска памяти, который я уже имею - в pHeap - е, создаю вот так
Node* pNode = new(pHeap)Node; - этот оператор не выделяет новую память, а в имеющейся памяти делает иничиализацию, т.е. просто вызываю конструктор на прямую.
когда говорил о запрете new - имелл ввиду new(size_t nSize), а не new(size_t, void* ptr).

насчет сборки мусора. у меня была некоторая идея, но не знаю на сколько она оправдана.
код вообще то не я сам пишу. но у автора (конкретно cb) была хорошая идея - иметь 2 типа кучи - Спец Куча и Общая Куча. в спец куче, естественно спец объекты, которые не часто и не много создаются, а некоторые из них создаются и лежат до конца. общая куча - это тоже понятна, и она наиболее проблематична!!!
мое предложение было такое :
есть Общая1 и вместе с ним создается Общая2, как олько Общая1 полностью или частично заполняеться, то она перестает выделять память. вместо нее действует Общая2, чтобы по ходу Общая1 частично или полностью освобождалась. после чего "останавливаеться" Общая2 и снова в ход пускается Общая1. и т.д.
т.е. всегда иметь под рукой "временную" кучу, которая и поможет как то вычистить другие рабочие кучи. получается как бы данные кочуют из одной кучи в другую. я не утверждаю, что метод самый лучший, и наиболее оптимальный - это просто идея и думаю есть какой то смысл.

но опять таки -
неужели нет ничего быстрее, чем связаный лист для контроля блоков?
а может с ним иметь еще какой нить другой дополнительный объект?

давайте попробуем оставить связаный лист в покое и попробуем поговорить о других, тоже не маловажных объектах. не забывайте есть vector, map, hash table, binary tree, etc - не объекты реализованные STL или MFC, а прсто их понятие. но мне ща в голову не лезет как и каким образом можно что либо из этого использовать. т.е. "как" понятно, но "каким образом" - не знаю.
- delimiter, поправки? :( 17.06.01 17:21  
Автор: Delimiter Статус: Незарегистрированный пользователь
Отредактировано 17.06.01 17:45  Количество правок: 2
<"чистая" ссылка>
Хм если спрашиваешь совета то внимательнее смотри
на ответы :))

> 2 Delimiter и 2 + :
> насчет связанных листов понятно - как не крути, вынужден
> идти методом "первого встречного". потому как на сортинг и
> на поиск теряю много времени.

смотри мой sample (это не метод первого встречного) :))
(я не из басни "кукушка и петух" :))

к счастью это метод "выборки лучшего"
ПОВТОР-ПОВТОР-====================================
метод первого встречного - хорошо конечно
( но почему не второго ,третьего...etc) (алгоритм смены лучшего не проблема) пройтись до первого встречного или по всему "массиву"
....я думаю не критично

примерно так
uint lookforsize; // какой размер ищем
uint between; // для хранения разницы
uint nchoise; // индекс выбора
between=sizeofheap; // присваиваем максимальный размер элемента
char *returnvalue //возврашаемый указатель

for(uint i=0;i<number_elements;i++)
{
if(elementisempty(i))
if(lookforsize<getsizeofelement(i))
if((getsizeofelement(i)-lookforsize)<between)
{
nchoise=i;
returnvalue=getpointerofelement(i);
between=getsizeofelement(i)-lookforsize;
}
}
if(nchoise!=numberofelement) // не последний?
{ // расчщщщепляем средний толкайя
for(uint j=numberofelement;j>nchoise;j--)
copyelement(j,j-1); // направление j <- j-1
numberofelement++;
}
copyelement(nchoise+1,nchoise);
setelementpointer(getelementpointer(nchoise)+lookforsize,nchoise+1)
// корректируем pointer^^^
setsizeofelement(lookforsize,choise);
setsizeofelement(getsizeofelement(choise+1)-lookforsize,choise+1);

setbuzy(nchoise); // теперь будет занято
return returnvalue;

один проход only :)) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

.... процедуру слияние двух рядом лежаших пустых блоков
я бы посоветовал делать во момент освобождения блока
uint totalsize;
setelementasempty(index)
for(uint i=0;i<numberofelment-1;i++)
{
if(elementisempty(i) && elementisempty(i+1))
{
totalsize=getsizeofelement(i)+getsizeofelement(i+1);
for(uint j=i;j<numberofelement-1;j++)
copyelement(j,j+1);
setsizeofelement(totalsize,i);
numberofelement--;
}
}

КОНЕЦ-ПОВТОРА-====================================

а соединение соседних свободных в один , это слабое но выигрывающее
по времени подобие сборке мусора (cистема при использовании метода
выборки лучшего самоорганизована)

если не веришь или не хочешь проверить на бумажке могу написать
МОДЕЛЯТОР


советую внимательнее посмотреть мой sample

> как соединять куски в листе и как проверки делать - это
> тоже понятно, более того часть кода уже реализована и
> работает. но не знаю, а может пока не знаю, можно ли там
> что либо оптимизировать. это потом будет видно.
>
> но опять таки -
> неужели нет ничего быстрее, чем связаный лист для контроля
> блоков?
> а может с ним иметь еще какой нить другой дополнительный
> объект?
>

по моему и я и Sandy говорили как раз об методах с простейшими
указателями и плевали в сторону достижений программисткой мысли
(т.к. ты хочешь максимальную производительность...потом заменишь
операции умножения на сдвиги и микромягкие умрут от зависти) :)))


> давайте попробуем оставить связаный лист в покое и
> попробуем поговорить о других, тоже не маловажных объектах.
> не забывайте есть vector, map, hash table, binary tree, etc
> - не объекты реализованные STL или MFC, а прсто их понятие.
> но мне ща в голову не лезет как и каким образом можно что
> либо из этого использовать. т.е. "как" понятно, но "каким
> образом" - не знаю.

.... а по моему выделение 2-х куч heap1 & heap2
намного хуже выделения одной heap3=heap1+heap2
- sandy, поправки? :( 18.06.01 21:33  
Автор: Sandy <Alexander Stepanov> Статус: Elderman
<"чистая" ссылка>
> .... процедуру слияние двух рядом лежаших пустых блоков
> я бы посоветовал делать во момент освобождения блока

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

> по моему и я и Sandy говорили как раз об методах с
> простейшими
> указателями и плевали в сторону достижений программисткой
> мысли

Именно :)

> .... а по моему выделение 2-х куч heap1 & heap2
> намного хуже выделения одной heap3=heap1+heap2

На мой взгляд - тоже. Объясняю: 2 кучи не есть панацея, так как не факт, что к моменту заполнения одной в другой будет достаточно свободных блоков. К тому же если в одной куче есть свободный блок размером 200 байт и в другой 200 байт, а выделить надо 300, то память выделить невозможно, хотя она есть в наличии.
- sandy, поправки? :( 19.06.01 01:11  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Неоптимально! Возможно, в будущем выделять память не
> придется, а время на слияние будет затрачено. Сливать блоки
> нужно только в момент выделения памяти и только если не
> нашлось готового блока подходящего размера.
да ладно, блоки слить это как 2 пальца. тут даже обхода не надо :)))
так что в run time он займет не больше 2-3 сравнений, и еще пару операций. так что тут о времени говорить даже стыдно...

> > .... а по моему выделение 2-х куч heap1 & heap2
> > намного хуже выделения одной heap3=heap1+heap2
>
> На мой взгляд - тоже. Объясняю: 2 кучи не есть панацея, так
> как не факт, что к моменту заполнения одной в другой будет
> достаточно свободных блоков. К тому же если в одной куче
> есть свободный блок размером 200 байт и в другой 200 байт,
> а выделить надо 300, то память выделить невозможно, хотя
> она есть в наличии.
hmmmmmmmmmm ....... сорри, но не убедительно. в таком случе, можно просто захапать, нипример, около 128Mb памяти и катайся как по маслу. но согласись с моей стороны будет "жадностью" :))))
- delimiter, поправки? :( 18.06.01 09:49  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> метод первого встречного - хорошо конечно
> ( но почему не второго ,третьего...etc) (алгоритм смены
> лучшего не проблема) пройтись до первого встречного или по
> всему "массиву"
> ....я думаю не критично

...... sousce skip............

> а соединение соседних свободных в один , это слабое но
> выигрывающее
> по времени подобие сборке мусора (cистема при использовании
> метода
> выборки лучшего самоорганизована)

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

вот собсна и вся задача...
- delimiter, поправки? :( 18.06.01 11:50  
Автор: Delimiter Статус: Незарегистрированный пользователь
<"чистая" ссылка>

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

в таком случае поделите общий "список" на два свободные и занятые
блоки при операции выделения ускоряете процедуру в 2 раза

об фрагментации кучи - опять а это вам надо...?
...я не верю.....все зависит от размера кучи и максимального размера блока
(реально) а также кол-во потенциальных клиентов на запрос(реально)
- это ведь КУЧА ...попробуйте сделать запрос на блок больший чем сама КУЧА :))

ну а если ваша КУЧА динамически растущая , то почему вы опять
говорите о фрагментации

при метое выбора лучшего мусора не существует
под мусором я понимаю блоки которые "Клиент" забыл
освободить-ну тода надо говорить о "киллере" блоков

...если фрагментация-то честно ответьте для себя вы способны на это время блокировать определенного клиента (чей блок вы собираетесь
перемещать) на операции askblok/getvalue/setvalue (утрирую:)

- delimiter, поправки? :( 18.06.01 12:16  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> в таком случае поделите общий "список" на два свободные и
> занятые
> блоки при операции выделения ускоряете процедуру в 2 раза

согласен...

> об фрагментации кучи - опять а это вам надо...?

что именно?

> ...я не верю.....все зависит от размера кучи и
> максимального размера блока
> (реально) а также кол-во потенциальных клиентов на
> запрос(реально)
> - это ведь КУЧА ...попробуйте сделать запрос на блок
> больший чем сама КУЧА :))

и чего?

> ну а если ваша КУЧА динамически растущая , то почему вы
> опять говорите о фрагментации

потому что из-за фрагментации блоков мы жрем зря системную память.

> при метое выбора лучшего мусора не существует
> под мусором я понимаю блоки которые "Клиент" забыл
> освободить-ну тода надо говорить о "киллере" блоков

про это я вообще не думаю... сборщик мусора не входил в мою первоначальную задачу...

> ...если фрагментация-то честно ответьте для себя вы
> способны на это время блокировать определенного клиента
> (чей блок вы собираетесь
> перемещать) на операции askblok/getvalue/setvalue
> (утрирую:)

не понял о чем речь.. поконкретней пожалуйста...
- Delimiter :)))) 18.06.01 13:37  
Автор: Delimiter Статус: Незарегистрированный пользователь
<"чистая" ссылка>
про 2-е таблицы....на самом деле она одна а вторая "нам впомощь"
изменяется в момент освобождения блока (если отдельной задачей
то можно и сортировать по ходу)

...ну идти делением на пополам :)) ...а уж ежели блокирована
использовать основной метеод


> потому что из-за фрагментации блоков мы жрем зря системную
> память.
Ok
sample (занятые с большой буквиК)-работа mysample
....а ето и есь моделятор
4К 1k 16К 5k 3K 2k 3K 7k 6K 20k 3K 9k 5K 450k
запрос на 14k
4К 1k 16К 5k 3K 2k 3K 7k 6K 14K 6k 3K 9k 5K 450k
запрос на 8k
4К 1k 16К 5k 3K 2k 3K 7k 6K 14K 6k 3K 8K 1k 5K 450k
освобождение 3K + split
4К 1k 16К 10k 3K 7k 6K 14K 6k 3K 8K 1k 5K 450k
освобождение 5K + split
4К 1k 16К 10k 3K 7k 6K 14K 6k 3K 8K 456k
запрос на 26k
4К 1k 16К 10k 3K 7k 6K 14K 6k 3K 8K 26K 430k
освобождение 8K
4К 1k 16К 10k 3K 7k 6K 14K 6k 3K 8k 26K 430k
освобождение 3K + split
4К 1k 16К 10k 3K 7k 6K 14K 17k 26K 430k
запрос на 5k
4К 1k 16К 5K 5k 3K 7k 6K 14K 17k 26K 430k
освобождение 3K + split
4К 1k 16К 5K 15k 6K 14K 17k 26K 430k
запрос на 2k
4К 1k 16К 5K 2K 13k 6K 14K 17k 26K 430k
освобождение 16K + split
4К 17К 5K 2K 13k 6K 14K 17k 26K 430k
освобождение 4K + split
4k 17К 5K 2K 13k 6K 14K 17k 26K 430k
запрос на 5k
4k 17К 5K 2K 5K 8k 6K 14K 17k 26K 430k
освобождение 5K
4k 17К 5k 2K 5K 8k 6K 14K 17k 26K 430k
освобождение 26K
4k 17К 5k 2K 5K 8k 6K 14K 473k
запрос на 2k
2K 2k 17К 5k 2K 5K 8k 6K 14K 473k
запрос на 4k
2K 2k 17К 4K 1k 2K 5K 8k 6K 14K 473k


etc.....если вы это называете ЖРАТЬ
то я теперь понимаю почему я такой толстый :))


> про это я вообще не думаю... сборщик мусора не входил в мою
> первоначальную задачу...
>
> > ...если фрагментация-то честно ответьте для себя вы
> > способны на это время блокировать определенного
> клиента
> > (чей блок вы собираетесь
> > перемещать) на операции askblok/getvalue/setvalue
> > (утрирую:)

...а это из области мечты относится к таблице ретрансляции
указателей ....... сделать практически нельзя
но я в нее ВЕРЮ :))))))

>
> не понял о чем речь.. поконкретней пожалуйста...
Voobche to heap tak i rabotaet (I imeu v vidu algoritm kotoryi ty opisal)(smotri bhytpu) 18.06.01 21:35  
Автор: + <Mikhail> Статус: Elderman
Отредактировано 19.06.01 00:22  Количество правок: 1
<"чистая" ссылка>
To All:
I odnogo ne ponimau checvy tak kipishite pro etot heap, kakaia takaia zadacha est` ne reshennaia?
Optimizirovat`.... What?
Esli ubirat` fragmentaciu budete teriat` skorost` rabotu s pamit`u, a eto 80-90% operacii v komputere esli ne bolshe. Pamiat` to nichego ne stoit seichas. i deshevle kupit` fizicheskuu pamiat` , chem teriat proizvoditel`nost` i defragmentirovat` na letu. i processoru po barabanu esli dva addressa nahodiatsia drug ot druga v 20 megs drug ot druga on schitaet ih s odinakovoii skorostiu, eto ne hard drive.
Vy mozhete skazat` : "A begat` po heapu i iskat` etii kuski pamiaty beret vremia".
Bla- bla-bla, Eto beret menshe vremeni chem sortirovat heap kazhdyii ras kak tolko proisohli ismenenia, potomuchto razmer bloaka ne ntakoi uzh bolshoi:
1. Pri sortirovke pamiat` dolzhna byt` zachichena ot zapisi i veroiatno ot chtenia (dlia teh kto ispolzuet eti kuski o-ochen` ploho , nado zdat`)
2. Pri serche zhdat` ni komu ni chego ne nado vse dotupno kazhdui hoziain svoego dobra.



P.S. esli uzh tak hochetsia togda sdelaite neskolko heaps dlia raznyh razmerov.
Naprimer h1<1K, 1k<h2<10k, 10k< h3<100K, . . .
Eti razmery mozhno optimalno podobrat` esli posmotret` statisticu allocacii pamiati (razmery, i kak chasto ona allociruetsia)
- Delimiter :)))) 18.06.01 15:02  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> sample (занятые с большой буквиК)-работа mysample

SKIP

> etc.....если вы это называете ЖРАТЬ
> то я теперь понимаю почему я такой толстый :))

все зависит от размера кучи и от интенсивности потребления...
не понятно что ты пытался показать своим логом...
можешь не объяснять это не вопрос...
теория остается теорией - если не бороться с фрагментированностью, то
системной памяти для кучи потребуется больше... и не важно на сколько...
- delimiter, поправки? :( 18.06.01 01:29  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Хм если спрашиваешь совета то внимательнее смотри
> на ответы :))

ОК спасибо, уже внимательней посмотрел :)))
хотя не самое оптимальное решение, но это шас не важно (за целый один обход много чего можно сделать)

> а соединение соседних свободных в один , это слабое но
> выигрывающее
> по времени подобие сборке мусора (cистема при использовании
> метода
> выборки лучшего самоорганизована)
>
> если не веришь или не хочешь проверить на бумажке могу
> написать
> МОДЕЛЯТОР
о каком моделяторе ты говоришь? о сборшике мусора?


> по моему и я и Sandy говорили как раз об методах с
> простейшими
> указателями и плевали в сторону достижений программисткой
> мысли
> (т.к. ты хочешь максимальную производительность...потом
> заменишь
> операции умножения на сдвиги и микромягкие умрут от
> зависти) :)))
ну нет до такого маразма не дойду, ОБЕШАЮ !!!! :))))))
более того не собираюсь ни с кем конкурировать. Я пока, слава Богу, не страдаю манией селичия, конкурировать с компаниями :))))

> .... а по моему выделение 2-х куч heap1 & heap2
> намного хуже выделения одной heap3=heap1+heap2
почему так думаешь? есть причины(опыт) или просто предположение?
- delimiter, поправки? :) 17.06.01 17:52  
Автор: Delimiter Статус: Незарегистрированный пользователь
<"чистая" ссылка>
я уже на VOS7(60 threads) проверил :))
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach