Зачем 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 явно упоминается крит.секция.

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

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

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

> jack128 © (22.01.13 17:09) [24]

Ну а lock cmpxchg еще шустрей.

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

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

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

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

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

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

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

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

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

Вижу это:

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

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

jack128 © (22.01.13 17:13) [27]

в Delphi GetMem реализован через VirtualAlloc. Куском кода со [skipped] бросить ?

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

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

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

← →
clickmaker © (2013-01-22 17:32) [36]

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

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

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

clickmaker © (22.01.13 17:32) [36]

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

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

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

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

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

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

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

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

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

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

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

← →
Mystic © (2013-01-22 18:02) [40]

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

«Для компиляции 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.

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

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

Насчет opencv ничего не могу сказать, Mozilla разработала свою замену malloc

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

> Eraser © (22.01.13 17:52) [39]

> она уже, в принципе, не будущая, а настоящая

Но попытки-то уже были - в том же "провальном" Kylix"e.

СтОит, наверно, заглянуть в справку к D3 на предмет присутствия структуры TMemoryManager - тогда можно определиться была ли у Борланда эта идея уже тогда.

← →
Rouse_ © (2013-01-22 18:51) [43]

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

Ну во первых менеджеров памяти у Дельфи несколько. Тот который от Пьера ле Ричи идет в составе дельфи начиная с 2005-ой дельфи, он гораздо шустрее того что был раньше.

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

В третьих мы не поддерживаем win9x, поэтому монопенисюально.

В четвертных - что я должен был критиковать?

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

Получается, что этот самый Пьер разработал менеджер памяти (хотя наверное его правильно назвать менеджер кучи) лучше (быстрее) чем стоковый у MS?

← →
Rouse_ © (2013-01-22 19:15) [45]

> чем стоковый у MS?

Чем тот же, но у предыдущих версий дельфи. Тестирование с кучами я не проводил.

← →
KilkennyCat © (2013-01-22 19:25) [46]

пока к микросхемкам напрямую не будет, все пофиг. а 99% пишущих программы вообще про менеджеров памяти не слышали. и ниче, пишут.

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

> Дмитрий С © (22.01.13 19:13) [44]
Что тебя смущает? Обычное "скорость vs универсальность". Винде для выделения памяти надо переключиться в режим ядра, найти доступную для выделения страницу памяти (4 килобайта), установить права доступа к ней, отметить во внутренних структурах, что память занята, перейти в режим пользователя... Сто раз выделишь якобы по байту — откушаешь 400 кб памяти. Делфовый менеджер один раз запросит 4 кб, а потом тебе в этих 4 килобайтах выделит сотню блоков по байту (накладные расходы по памяти тоже будут немаленькими, но куда меньше "системных"), притом переход в режим ядра/пользователя будет один, а не сотня.

ЗЫ. Это, конечно, очень грубое отражение реальности.

← →
Дмитрий С © (2013-01-22 19:46) [48]

> ЗЫ. Это, конечно, очень грубое отражение реальности.

Это если выделять память с помощью VirtualAlloc, а если HeapAlloc?

← →
Anatoly Podgoretsky © (2013-01-22 19:57) [49]

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

Верить надо не Рихтеру, он возможно инсайдер, а MSDN

← →
Rouse_ © (2013-01-22 20:17) [50]

> Дмитрий С © (22.01.13 19:46) [48]
>
> > ЗЫ. Это, конечно, очень грубое отражение реальности.
>
> Это если выделять память с помощью VirtualAlloc, а если
> HeapAlloc?

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

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

Anatoly Podgoretsky © (22.01.13 19:57) [49]

у MSDN память короткая

Rouse_ © (22.01.13 20:17) [50]

> HeapAlloc работает через VirtualAlloc с небольшим довеском

А GetMem в Delphi тоже работает через VirtualAlloc с небольшим довеском
если интересно, могу реализацию на паскале показать.

← →
Rouse_ © (2013-01-22 20:31) [52]

> А GetMem в Delphi тоже работает через VirtualAlloc с небольшим
> довеском
> если интересно, могу реализацию на паскале показать.

А смысл?

← →
Pavia © (2013-01-22 21:00) [53]

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

Зачем дельфи свой менеджер? Не знаю.

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

Не важно. У OpenCV архитектура такая сначала выделяем потом используем. Т.е её интерфейс способствует грамотной реализации. Которая выглядит так вначале запуска программы выделяется память. И далее уже не трогается, а используется уже выделенная. Поэтому на скорости это не влияет.

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

Pavia © (22.01.13 21:00) [53]

> Зачем дельфи свой менеджер? Не знаю.

Зачем в Windows несколько разных диспетчеров памяти ?

← →
Pavia © (2013-01-22 21:23) [55]

> Зачем в Windows несколько разных диспетчеров памяти ?

А что их несколько? Думаю с развитием технологий остались, и в наследство от других систем.

← →
Rouse_ © (2013-01-22 21:33) [56]

> Pavia © (22.01.13 21:23) [55]
> А что их несколько? Думаю с развитием технологий остались,
> и в наследство от других систем.

Ну я бы не сказал: http://www.ibm.com/developerworks/ru/edu/os_architecture_course2/section7.html

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

> Pavia © (22.01.13 21:00) [53]

> выглядит так вначале запуска программы выделяется память.

И сколько же, по-твоему, ее "выделяется" ?

← →
Дмитрий С © (2013-01-22 22:16) [58]

HeapAlloc при каждом вызове вызывает VirtualAlloc что ли?

Навскидку измерил скорость работы HeapAlloc GetTickCount-ом. Результат - 0 -> выполняется меньше миллисекунды. Куда уж быстрее:)

← →
Сергей М. © (2013-01-22 22:25) [59]

> HeapAlloc при каждом вызове вызывает VirtualAlloc что ли?

Зачем при каждом-то ?
Только при необходимости получения "оптом" одной или более страниц вирт.памяти.

← →
Rouse_ © (2013-01-22 22:28) [60]

> Навскидку измерил скорость работы HeapAlloc GetTickCount-
> ом. Результат - 0 -> выполняется меньше миллисекунды. Куда
> уж быстрее:)

Эмнь, как это ты так замерял-то? :)

program Project2; {$APPTYPE CONSOLE} uses Windows, SysUtils; const HEAP_ZERO_MEMORY = 8; var I: Integer; Start: DWORD; P: Pointer; hHeap: THandle; begin Start := GetTickCount; hHeap := GetProcessHeap; for I := 0 to 1000000 do begin P := HeapAlloc(hHeap, HEAP_ZERO_MEMORY, 100); HeapFree(hHeap, 0, P); end; Writeln(GetTickCount - Start); Start := GetTickCount; hHeap := GetProcessHeap; for I := 0 to 1000000 do begin P := VirtualAlloc(nil, 100, MEM_COMMIT or MEM_RESET, PAGE_READWRITE); VirtualFree(P, 100, MEM_RELEASE); end; Writeln(GetTickCount - Start); Readln; end.

← →
Пит (2013-01-22 23:04) [61]

программисты всё таки такие программисты )

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

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

← →
Rouse_ © (2013-01-22 23:06) [62]

> Пит (22.01.13 23:04) [61]
> программисты всё таки такие программисты )
>
> Какая буря обсуждений в вопросе, который по сути в прикладном
> смысле нафиг никому не нужен.

Оптимизацией доступа к большим блокам памяти (3-4 Гб) стало-быть не занимался :)

← →
Пит (2013-01-22 23:08) [63]

> Оптимизацией доступа к большим блокам памяти (3-4 Гб) стало-
> быть не занимался :)

я на это отвел аж 5% )

← →
Сергей М. © (2013-01-22 23:08) [64]

> абсолютное незнание вопроса никак не мешает реализовывать
> 95% задач

Но при этом хоть какое-то знание вопроса поможет реализовать оставшиеся 5%)
В нашем деле грань между любопытством, работой и искусством настолько тонка, что мы ее и сами порой не видим)

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

> Оптимизацией доступа к большим блокам памяти (3-4 Гб) стало-
> быть не занимался :)

а зачем ей заниматься ?

← →
Rouse_ © (2013-01-22 23:10) [66]

> Пит (22.01.13 23:08) [63]

Хм, ну под 5 процентов я бы отвел работу с AWE, но по сути при реализации высоконагруженного приложения всеж таки желательна оптимизация.
Хотя да, это уже не задача менеджера памяти - чей-то я тут не про то сказал :)

← →
Rouse_ © (2013-01-22 23:11) [67]

> Игорь Шевченко © (22.01.13 23:09) [65]
> а зачем ей заниматься ?

Индексы - будь они не ладны...

← →
картман © (2013-01-22 23:13) [68]

Удалено модератором

← →
Пит (2013-01-22 23:20) [69]

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

это да. Но мы по ходу в разных мирах живем. Я жизни не встречал ситуаций, чтобы оптимизация касалась оптимизации памяти. Оптимизировать алгоритм - да. Оптимизировать запрос к БД - ДА ДА ДА ДА ДА ДА ДА ДА ДА ДА ДА.

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

От менеджера памяти хочется не скорости, а иногда функционала типа подсчета утечек, ну это хорошо реализует FastMM или эврика.

← →
Rouse_ © (2013-01-22 23:30) [70]

> Пит (22.01.13 23:20) [69]
> это да. Но мы по ходу в разных мирах живем. Я жизни не встречал
> ситуаций, чтобы оптимизация касалась оптимизации памяти

Месяца четыре назад я постил цитату с нашего внутреннего форума что при наличии в среднем трех миллионов индексов (слов) в каждой базе (которых у нас около 450 на данный момент) даже если брать на каждый индекс по 4 байта , а не за реальную запись вида ID=Value, получается выход за 4 гигабайта памяти, из-за чего приложение просто перестанет загружаться.
В таких ситуациях приходится выкручиваться. Собственно сейчас у нас общая база почти 19 гигабайт, размер индекса после обработки около 400 метров, загрузка индекса около 6 секунд. Достаточно хороший результат...

← →
Rouse_ © (2013-01-22 23:31) [71]

А - во нашел:

В новой версии ГСИ мы ввели поисковые индексы на базе токенов. Токен - это скажем так некое уникальное слово. Например если у нас есть миллион документов состоящих из трех слов "мама мыла раму" то в итоге у нас на руках будет всего три токена (по одному на каждое слово) и куча индексов, указывающих в каком документе тот или иной токен встречается. В результате (если исключить поиск по параграфам или по дистанции) список документов отбирается меньше чем за 10 миллисекунд. А засада вылезла как раз в количестве этих самих токенов. Мы для себя сделали 10 самых больших баз от 3 гигабайт до 300 мегабайт (т.е. 10 самых больших) и тестировали на них. И скорость и память - все нас устраивало. Пока не пришло время тестировать на полном комплекте баз (sik). А это как раз произошло за день как мы решили отдавать тот вариант финальной беты. Немного математики: мы тестировали на обьеме 5 с половиной гигобайта (реальный общий размер баз), остальные копеешные базы занимают примерно еще гигобайт все вместе. Мы и не предполагали, что в более меньших по объему базах, количество памяти, необходимое под хранение токенов практически идентично большим базам. И тут представьте наше удивление когда приложение просто банально перестает запускаться из-за того что закончилась память на компьютере! WTF!!! Все это из-за того, что большинство слов встречаются повсеместно и будут присутствовать практически в каждом документе, из-за чего количество токенов даже в маленькой базе будет практически идентично размеру большой (около 3 миллионов). А этот нюанс мы полностью пропустили!!! А теперь опять банальная математика. Если в каждой базе будет в среднем по 3 миллионов токенов (а это сейчас так и есть) и допустим что нам нужно хотя бы 4 байта для хранения каждого (в действительности требуется гораздо больше) то получается что для 200 баз нам нужно памяти 2 гигобайта и 288 мегобайт. Т.к. у современного приложения всего доступно для чтения от двух до трех гигобайт (наше умеет работать с тремя) то сами видите с какой проблемой мы столкнулись. Собственно, последнее время перебираем движок, пытаясь впихнуть невпихуемое...

← →
Rouse_ © (2013-01-22 23:35) [72]

ЗЫ: кстати решали эту проблему в том числе частичной подменой менеджера памяти, т.е. нужные мне реалоки именно при работе с моими данными я реализовывал посредством собственного механизма, правда над блоком памяти полученным от стандартного, т.е. манагер над манагером.

← →
Пит (2013-01-22 23:46) [73]

я помню твой пост, очень забавная фигня ))

Но мой пост это не отменяет )

← →
Ega23 © (2013-01-23 00:55) [74]

> Собственно сейчас у нас общая база почти 19 гигабайт

28 не хочешь?

← →
Eraser © (2013-01-23 01:07) [75]

> Rouse_ © (22.01.13 23:31) [71]

а эта задаче разве не СУБД, или у вас свой движок?

← →
Ega23 © (2013-01-23 01:14) [76]

> а эта задаче разве не СУБД, или у вас свой движок?

Не, СУБД там не подходит по ряду причин.

← →
Дмитрий С © (2013-01-23 01:15) [77]

> я реализовывал посредством собственного механизма

Ну так этим наверное все когда-либо занимались.

← →
Pavia © (2013-01-23 06:28) [78]

> Не, СУБД там не подходит по ряду причин.

А можно подробнее?
А то по описанию именно что нужна СУБД.
Я другого пути не вижу если данных много и в память они не влазят то надо правильно организовывать работу с данными. А это СУБД или свою СУБД делать.

← →
Павиа (2013-01-23 07:17) [79]

>> выглядит так вначале запуска программы выделяется память.
>И сколько же, по-твоему, ее "выделяется" ?
Столько сколько за трабовал программист. Ещё раз количество вызовов alloc минимизированно (без уточнения какой именно alloc).
Делал я сегментацию клякс на изоброжении, для подсчёта числа символов. Делал на дельфи 7 это рекурсивный алгоритм с массивом. Так вот разница в использовании динамического и статического массива оказалась не большой 10-15%. При этом память под динамический массив постоянно выделяется освобождается. А для статического, только 2-3 раза. (вернее статический массив у меня был не совсем статическим)

← →
Сергей М. © (2013-01-23 09:29) [80]

> Столько сколько за трабовал программист

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

> память под динамический массив постоянно выделяется освобождается
> статический массив у меня был

Я что-то не понял - ты подменил дельфийский менеджер opencv"шным что ли ?

Полагаю что говоря об OpenCV-менеджере куч мы имеем ввиду MemStorage-механизм с соответствующим набором касаемых его OpenCVAPI-вызовов..

http://locv.ru/wiki/8.1_%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%B8

← →
Ega23 © (2013-01-23 09:49) [81]

> А можно подробнее?

Есть токены. Есть документы, в которых они встречаются. Токенов, ЕМНИП, примерно 3,5 миллиона (попозже уточню). Документов - примерно 15.000
Вероятность встречаемости токена в документе, если я не ошибаюсь, что-то около 40% (считал давно).
Вот и прикидывай, сколько кросс-таблица отношения токенов к документам займёт. 21 миллиард записей.

← →
Ega23 © (2013-01-23 10:35) [82]

Уточнил. Полтора миллиона. Но в индексном файле ещё и в lower case это дело сидит, это, считай, плюс примерно 85% от полутора лямов.
прилично, в общем, набИгает.

← →
Пит (2013-01-23 10:44) [83]

Ega23, ну я не особо вник в проблему. Но мне кажется вы все равно изобрели велосипед.

Вон Word делает проверку и орфографии и пунктуации, и разбирает синтаксис. Те же самые онлайн переводчики, какой там анализ встроен - я даже не представляю. И они не грузят в памят 4 гб словари...

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

← →
Ega23 © (2013-01-23 10:49) [84]

> Вон Word делает проверку и орфографии и пунктуации, и разбирает
> синтаксис. Те же самые онлайн переводчики, какой там анализ
> встроен - я даже не представляю. И они не грузят в памят
> 4 гб словари...

Ты не понял. подсветка она моментально делается, без всякой загрузки огромных кусков. Речь о поиске в 15.000 документах.
Дано: 15.000 документов. Отбери из них те, в которых есть слова с подстроками "масс", "отбив", "штукат", регистронезависимо, чтобы расстояние между словами было не более 15 слов.

← →
Ega23 © (2013-01-23 10:50) [85]

> Но просто наверняка бизнес-задача как-то и иначе решается.

Решается, 300 метров в памяти, пиковые - может до 600 метров доходить.

← →
Rouse_ © (2013-01-23 11:30) [86]

> Отбери из них те, в которых есть слова

Немного не так - отобрать нужно максимально быстро, бо клиентов на сервере много, чтоб ни у кого ничего не тормозило.

> Пит (23.01.13 10:44) [83]

Есть такая утилитка AvSearch. Удобная и шустрая - делает поиск по папке по введенному выражению (я ей обычно поиск в исходниках делаю). Тестировал на ней, выгрузив все наши документы в текстовом виде. Результат поиска в среднем около двух минут, что с нашим практически моментальны поиском не идет ни в какое сравнение.

← →
Ega23 © (2013-01-23 11:33) [87]

> Немного не так - отобрать нужно максимально быстро, бо клиентов
> на сервере много, чтоб ни у кого ничего не тормозило.

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

← →
Rouse_ © (2013-01-23 11:34) [88]

Да впрочем можно даже посмотреть на поиск самой дельфи.
Берем папку: C:\Program Files\Embarcadero\RAD Studio\7.0\source
В ней 1 718 файлов. Делаем поиск в дельфе по это папке слова GetTickCount.
Результат 11 секунд - что не допустимо в нашей ИСС.

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

Rouse_ © (23.01.13 11:34) [88]

Виндовый поиск с включенной индексацией ?

← →
Rouse_ © (2013-01-23 11:43) [90]

> Игорь Шевченко © (23.01.13 11:40) [89]

Не тестировал.

← →
Rouse_ © (2013-01-23 11:47) [91]

А он внутри текста документов разве ищет?

← →
Sha © (2013-01-23 12:05) [92]

> Ega23 © (23.01.13 10:49) [84]
> Речь о поиске в 15.000 документах.Дано: 15.000 документов. Отбери
> из них те, в которых есть слова с подстроками "масс", "отбив",
> "штукат", регистронезависимо, чтобы расстояние между словами
> было не более 15 слов.

поиск нужен по тексту документов в ОП или по индексам?

← →
Павиа (2013-01-23 12:07) [93]

Проблемы понятны. Сам ковырялся с моментальным поиском. Вот только пути решений у нас разные.

> поиск нужен по тексту документов в ОП или по индексам?

И тот и другой. Просто в документе слова встретились в произвольном порядке - там по общему индексу поиск идёт, это вообще меньше секунды, дольше отображать список документов. А вот если "строгое совпадение фразы", или "расстояние между словами" или "все слова встречаются в пределах параграфа" - тогда двухступенчатый поиск: сначала по первому отбираем все документы, в которых данные слова встречаются, потом к каждому документу подгружаем уже его индексный файл, где порядок слов и параграфов учтён. Тут уже дольше перебор идёт. ЕМНИП, основная просадка на файловых операциях (но тут могу ошибаться).

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

Весь алгоритм меньше сотни строчек.

← →
Пит (2013-01-23 12:19) [97]

Rouse_, ну понятно что блин поиск по диску универсальными утилитами даже рассматривать глупо.

Вы пробовали например хотя бы что-то типа: http://ru.wikipedia.org/wiki/Sphinx_%28%D0%BF%D0%BE%D0%B8%D1%81%D0%BA%D0%BE%D0%B2%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%29

?

[96] это в ответ на [94]

> Ega23 © (23.01.13 12:16) [95]

Нормальное решение. Очень интересно, есть ли статистика запросов пользователей? Почему недостаточно просто в пределах абзаца?

> Sha © (23.01.13 12:18) [96]

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

> Пит (23.01.13 12:19) [97]

Много чего перепробовали - скорость не устроила и возня с настройкой у конечного пользователя.

> Очень интересно, есть ли статистика запросов пользователей?

К сожалению нет, только по ошибкам.

> Почему недостаточно просто в пределах абзаца?

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

> Вы пробовали например хотя бы что-то типа

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

> Ega23 © (23.01.13 12:33) [101]

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

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

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

Именно так. Витала одно время идея абзацем <TR> считать, но, поскольку таблицы в 30% случаев составные, то на <TD> остановились.

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

> Игорь Шевченко © (23.01.13 13:57) [107]

> LookasideLists

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

> LookasideLists

Или это не только для драйверов? Если не только, то это хорошая штука, но к сожалению только под Windows.

DVM © (23.01.13 15:33) [108]

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

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

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

Если абстрагироваться от конкретных реализаций: в чем может быть фишка своего менеджера памяти? Очевидно в захвате некоторого блока у системы и последующее распределение меж нуждающимися без лишних аллокаций-реаллокаций. Все остальное - только вариации на тему. ИМХО.

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

> Rouse_ © (23.01.13 16:37) [111]

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

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

← →
Павиа (2013-01-23 17:51) [116]

invert, На осдеве обсуждали создать можно, но это java, net (т.е. компилятор должен быть квазинативный)

> [115] Игорь Шевченко © (23.01.13 17:40)
> Есть и такие

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

> [116] Павиа (23.01.13 17:51)
> На осдеве обсуждали создать можно, но это java, net (т.е.
> компилятор должен быть квазинативный)

Ну, про такие в общем-то понятно. Может, если в процессоре их реализуют, так то и будет.

Inovet © (23.01.13 17:54) [117]

Ты вообще о чем ? О каких процессорах и каких указателях ? Такие указатели были еще в Windows 3.1

← →
Павиа (2013-01-23 18:08) [120]

Ну, про такие в общем-то понятно. Может, если в процессоре их реализуют, так то и будет.
>

Зачем в процессоре! dz делает ОС с такими указателями. Называется ФантомОС (не путать с человеком)

> [119] Игорь Шевченко © (23.01.13 17:59)
> Ты вообще о чем ?

Это фантазии. Указатели, которые в Интел, на слишком крупные куски указывают. Надо, чтобы на любой адрес. В общем памяти для трасляции понадобится ещё столько же, как и основной.

> [120] Павиа (23.01.13 18:08)
> ФантомОС

Посмотрел.

> Полагаю что говоря об OpenCV-менеджере куч мы имеем ввиду
> MemStorage-механизм с соответствующим набором касаемых его
> OpenCVAPI-вызовов..http://locv.ru/wiki/8.1_%D0%A5%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%B8

Добрался до дому. Залес в исходники OpenCV. Для основных объектов OpenCV используется malloc. И ещё раз повторюсь в грамотной архитектуре не нужно лишнего. Что касается того что описано в вике то оно используется рас два и обчёлся где. И судя по всему появилась после открытия исходников OpenCV. (т.е кривыми руками).

> Я что-то не понял - ты подменил дельфийский менеджер opencv"шным
> что ли ?

Нет. У меня свой аналог OpenCV на Delphi.

> [124]

Бред какой-то..

А вот ещё
http://www.gunsmoker.ru/2009/01/blog-post.html

> А вот ещё
> http://www.gunsmoker.ru/2009/01/blog-post.html

Про HeapAlloc автор ничего не сказал.

← →
Тымохов (2013-01-24 14:36) [128]

наск. помню по манагеру старому и манагеру начиная с fastmm они и берут большой кусок сразу, потом распределяют.

fastmm наск. помню историю во много спас какой-то из дельфей. вроде как 8-ой дельфи был страшно тормознутый. потом вышла след. версия в новым манагером (как в создаваемых программах, так и в самой IDE) и стало все существенно быстрее.

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

видимо, в этом и есть ответ - зачем свой манагер - так быстрее.

>Про HeapAlloc автор ничего не сказал.
зачем свой манагер - дабы не нарушать авторские права фирмы MicroSoft. При возможном переезде на другую платформу портируется СВОЯ рун-тайм библиотека - и всё будет работать.

> зачем свой манагер - дабы не нарушать авторские права фирмы
> MicroSoft. При возможном переезде на другую платформу портируется
> СВОЯ рун-тайм библиотека - и всё будет работать.

угу, тут на WinRT не могут переехать, а ты про другие платформы..

> jack128 © (25.01.13 15:23) [130]

вообще очень радует firemonkey, пока "промышленно" под него ничего не писали, но тесты провожу регулярно. например, без особого труда удалось перевести две известные криптобиблиотеки (LockBox 3 и dcpcrypt), да и вообще исходные модули XE3 уже фактически готовы для ARM и Linux (для Mac уже можно компилировать). Генофонд сильно переписан за последнее время. Т.е., по крайней мере у меня, впечатление, что на этот раз, с N-ой попытки, им удалось сделать хороший кроссплатформенный инструмент, верной дорогой идут.

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