Зачем delphi свой менеджер памяти?

← →
Дмитрий С © (2013-01-22 10:55) [0]

Чем тот что windows предоставляет не подходит?

← →
Romkin © (2013-01-22 11:01) [1]

О каком именно из тех, что предоставляет Windows ты говоришь? :)

← →
clickmaker © (2013-01-22 11:22) [2]

Для оптимизации при выделении памяти в куче под небольшие объекты (классы, строки, дин. массивы)

← →
Rouse_ © (2013-01-22 11:31) [3]

Какой именно Менеджер памяти предоставляет Windows?

← →
Пит (2013-01-22 11:31) [4]

Дмитрий С, ну ты даешь старик!

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

← →
Inovet © (2013-01-22 12:33) [5]

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

← →
jack128 © (2013-01-22 13:58) [6]

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

зависит от того, как именно запрашивать эту память, ибо см [1].

← →
jack128 © (2013-01-22 13:59) [7]

> Ведь именно дельфи знает о своих типах данных и как их грамотно
> размещать в памяти.

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

← →
Дмитрий С © (2013-01-22 14:40) [8]

Я может неправильно выразился громким словом "Менеджер памяти".
По-умолчанию, delphi использует функцию SysGetMem для выделения памяти. Почему нельзя было просто использовать HeapAlloc или VirtualAlloc или типа того вместо нее?

← →
Дмитрий С © (2013-01-22 14:42) [9]

> Ведь именно дельфи знает о своих типах данных и как их грамотно
> размещать в памяти.

Если честно, то у меня сомнения, что Delphi это сделает лучше чем Windows.

← →
RWolf © (2013-01-22 14:50) [10]

если я правильно помню, в FastMem есть режим работы с динамической памятью через WinAPI; используется для отладки и отличается крайней неторопливостью.

← →
Rouse_ © (2013-01-22 14:51) [11]

SysGetMem использует VirtualAlloc для выделения большого куска памяти, а потом оперирует этой выделенной памятью. Т.е. реальных реалоков не происходит (с условием что выделеной памяти достаточно) а сталобыть и тормозов связаных с выделением и реалокированием нет.

← →
Игорь Шевченко © (2013-01-22 14:59) [12]

Зачем Delphi использует свой - потому что быстрее

← →
брат Птибурдукова (2013-01-22 15:18) [13]

> Дмитрий С © (22.01.13 14:40) [8]
слово "гранулярность" о чём-то говорит?

← →
Пит (2013-01-22 15:20) [14]

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

Жень, а ты в этом уверен?
Никакой оптимизации никогда не происходит в соответствии о знании специфики?

Тогда я согласен с:

> Если честно, то у меня сомнения, что Delphi это сделает
> лучше чем Windows.

неужто вы все согласны, что разработчики Дельфи на порядок талантливее, чем разработчики Windows?

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

С чего это вдруг менеджер памяти дельфи окажется быстрее виндового, за счет каких алгоритмов то?

Если они оба оперируют исключительно одними понятиями и входные данные всегда ДайПамяти(<СтолькоВотБайт>) в одни и те же моменты времени, то как раз менеджер памяти Windows должен уделывать Delphi, по крайней мере быть не хуже.

← →
брат Птибурдукова (2013-01-22 15:26) [15]

> Пит (22.01.13 15:20) [14]
[13] и Руссиновича читал? :-)

← →
jack128 © (2013-01-22 15:28) [16]

> Почему нельзя было просто использовать HeapAlloc или VirtualAlloc
> или типа того вместо нее?

ну как Игорь сказал дельфийский менеджер памяти побыстрее будет.
Но надо сказать, что сишный рантайм от MS использует HeapAlloc напрямую. Вроде как в win2k его(HeapXXX) переписали и он стал весь из себя жутко быстрый.

← →
Anatoly Podgoretsky © (2013-01-22 15:32) [17]

Есть несколько менеджеров памяти в ДЕЛЬФИ и все они различаются скоростью. При том победителя нет.

← →
Дмитрий С © (2013-01-22 15:47) [18]

> Anatoly Podgoretsky © (22.01.13 15:32) [17]
>
> Есть несколько менеджеров памяти в ДЕЛЬФИ и все они различаются
> скоростью. При том победителя нет.

А готовые тесты для этого есть?

Написал небольшой модуль, может кто потестит скорость?

unit MyMem; interface implementation type DWORD = Cardinal; BOOL = LongBool; const kernel32 = "kernel32.dll"; HEAP_ZERO_MEMORY = $00000008; function HeapAlloc(hHeap: THandle; dwFlags, dwBytes: DWORD): Pointer; stdcall; external kernel32 name "HeapAlloc"; function HeapFree(hHeap: THandle; dwFlags: DWORD; lpMem: Pointer): BOOL; stdcall; external kernel32 name "HeapFree"; function HeapReAlloc(hHeap: THandle; dwFlags: DWORD; lpMem: Pointer; dwBytes: DWORD): Pointer; stdcall; external kernel32 name "HeapReAlloc"; function GetProcessHeap: THandle; stdcall; external kernel32 name "GetProcessHeap"; var Heap: THandle; function GetMem(Size: Integer): Pointer; begin Result := HeapAlloc(Heap, 0, Size); end; function FreeMem(P: Pointer): Integer; begin if P <> nil then HeapFree(Heap, 0, P); Result := 0; end; function AllocMem(Size: Cardinal): Pointer; begin Result := HeapAlloc(Heap, HEAP_ZERO_MEMORY, Size); end; function ReAllocMem(P: Pointer; Size: Integer): Pointer; begin Result := HeapReAlloc(Heap, HEAP_ZERO_MEMORY, P, Size); end; function RegisterExpectedMemoryLeak(P: Pointer): Boolean; begin Result := True; end; function UnRegisterExpectedMemoryLeak(P: Pointer): Boolean; begin Result := True; end; var MM: TMemoryManagerEx = ( GetMem: GetMem; FreeMem: FreeMem; ReallocMem: ReAllocMem; AllocMem: AllocMem; RegisterExpectedMemoryLeak: RegisterExpectedMemoryLeak; UnregisterExpectedMemoryLeak: UnRegisterExpectedMemoryLeak ); OldMM: TMemoryManagerEx; initialization Heap := GetProcessHeap; GetMemoryManager(OldMM); SetMemoryManager(MM); finalization SetMemoryManager(OldMM); end.

← →
Eraser © (2013-01-22 16:17) [19]

> Дмитрий С © (22.01.13 15:47) [18]

такой тест про оптимальность ничего не скажет. тестирование менеджера памяти - весьма нетривиальная задача.

> Если честно, то у меня сомнения, что Delphi это сделает
> лучше чем Windows.

доля правды в этом есть, нынче уже не win9x и даже не XP. начиная с висты, в ОС кардинально переделали работу с памятью.

← →
Сергей М. © (2013-01-22 16:21) [20]

> С чего это вдруг менеджер памяти дельфи окажется быстрее
> виндового, за счет каких алгоритмов то?
>

Подозреваю что как минимум за счет использования мьютексов виндовым хип-менеджером в режиме HEAP_NO_SERIALIZE = False.
Стандартный дельфийский менджер в режиме IsMultithreading = True использует крит.секцию.
Обращения к КС существенно быстрее чем к мьютексам.

← →
Пит (2013-01-22 16:58) [21]

> Обращения к КС существенно быстрее чем к мьютексам.

> ну как Игорь сказал дельфийский менеджер памяти побыстрее
> будет.
> Но надо сказать, что сишный рантайм от MS использует HeapAlloc
> напрямую. Вроде как в win2k его(HeapXXX) переписали и он
> стал весь из себя жутко быстрый.

то есть, сведения о том, что дельфийский менеджер быстрее относятся к системам до win2k? )))
А где такие еще стоят и кто на них ориентируется еще?

Блин, тока Розыч бы сча не вылез со своей критикой что ой как много клиентов на win9x сейчас у гранда)

То есть, на системах которые были выпущены последние лет 12-13 уже не факт кто быстрее?

> Обращения к КС существенно быстрее чем к мьютексам.

а почему тогда виндовый менеджер не использует секции?
И опять же - не относятся твои сведения как тут выясняется к системам 15-ти летней давности?

← →
Eraser © (2013-01-22 17:01) [22]

> Пит (22.01.13 16:58) [21]

> а почему тогда виндовый менеджер не использует секции?

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

← →
Игорь Шевченко © (2013-01-22 17:01) [23]

> Но надо сказать, что сишный рантайм от MS использует HeapAlloc
> напрямую

вместо malloc ?

← →
jack128 © (2013-01-22 17:09) [24]

> Стандартный дельфийский менджер в режиме IsMultithreading
> = True использует крит.секцию.

стандартный менеджер памяти в д2010 не использует крит.секции. Он просто выставляет флажок лока через lock cmpxchg, а если натыкается на конфликт, то ждет sleep"ом.

← →
clickmaker © (2013-01-22 17:09) [25]

> > Но надо сказать, что сишный рантайм от MS использует HeapAlloc
>
> > напрямую
>
>
> вместо malloc ?

malloc - обертка для HeapAlloc

← →
Дмитрий С © (2013-01-22 17:13) [26]

> потому что крит. секцию можно использовать только в рамках
> одного процесса.

А с кучей можно из разных процессов работать?

← →
jack128 © (2013-01-22 17:13) [27]

> вместо malloc ?

malloc реализуется через HeapAlloc. вот тут http://www.rsdn.ru/forum/cpp/1769838.1 народ кусками кода бросается.

← →
Сергей М. © (2013-01-22 17:18) [28]

> не относятся твои сведения как тут выясняется к системам
> 15-ти летней давности?

msdn гласит что хип-менеджер стал доступен начиная с XP

А насчет мьютексов могу и ошибаться, если трактовать "в лоб"

If HEAP_NO_SERIALIZE is not specified (the simple default), the heap serializes access within the calling process. Serialization ensures mutual exclusion when two or more threads attempt simultaneously to allocate or free blocks from the same heap

Хотя в комментах к HeapLock/Unlock явно упоминается крит.секция.

Вряд ли там мьютексы. Речь ведь идет о доступе из разных потоков, а не процессов, within the calling process

> msdn гласит что хип-менеджер стал доступен начиная с XP

Рихтер в курсе ? А то в книге 96-года издания он про heap-функции пишет

> clickmaker © (22.01.13 17:22) [29]

В любом случае, согласно msgn, виндовых хипов попросту не было во времена Win9x/Me.

> Игорь Шевченко © (22.01.13 17:24) [31]

Понятия не имею.

Вижу это:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366569%28v=vs.85%29.aspx

> В любом случае, согласно msgn, виндовых хипов попросту не
> было во времена Win9x/Me.

Не верь, хозяин, этому Константинопольскому ходже. В Windows 95 kernel32.dll экспортирует Heap-функции

> [32] Сергей М. © (22.01.13 17:25)

Это у MS политика такая: все, что устарело и не поддерживается - того как бы и не было. Стерто из памяти людской и из истории. А "кучные" функции появились еще в вин 95

clickmaker © (22.01.13 17:32) [36]

"таймс 03.12.83 минусминус изложен наказ с. б. упомянуты нелица переписать сквозь наверх до подшивки"

> Игорь Шевченко © (22.01.13 17:32) [35]

> clickmaker © (22.01.13 17:32) [36]

Ну может быть, ворошить не буду)

Но тогда Борланду остается минимум одно оправдание незадействования хипов - прицел на будущую кроссплатформенность.

p.s.
Вот просто ради интереса бы глянуть - какой менеджер пользуют в устоявшихся версиях, скажем, OpenCV ? Он тоже верхом на malloc сидит ? Что-то я сомневаюсь - там ведь тоже ориентация на быструю [ре]аллокацию большого кол-ва малоразмерных блоков, хотя дефрагментированность не критична ..
У кого есть под рукой исх-ки ?

> Сергей М. © (22.01.13 17:50) [38]

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

она уже, в принципе, не будущая, а настоящая (см. FM). да и вызовы стандартного MM можно сделать просто обертками над системным.

Когда-то было проблемой, сейчас не знаю.

«Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4 не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с выделением памяти для мелких объектов)».

Евгения Рошаль, описание новых возможностей Far (версия 1.70 beta 2, сборка 321 от 16.12.2000).

В те времена Heap-функции не были заточены под работу с мелкими объектами. А для Delphi это было критично. Впрочем, примерно в Delphi 6-7 была возможность поставить свой менеджер памяти, и там, как вариант, можно было поставить вызовы Windows. Преимущества - такой менеджер памяти разделяем с DLL.

Зачем delphi свой менеджер памяти? Найти похожие ветки