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

← →
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 или эврика.

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

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

А - во нашел:

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

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

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

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

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

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

28 не хочешь?

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

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

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

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

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

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

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

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

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

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

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

Я что-то не понял - ты подменил дельфийский менеджер 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

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