LINUX.ORG.RU

Создание собственного диспетчера памяти для проектов C/C++

 


0

0

Оптимизация производительности программ является чрезвычайно важной задачей. Часто приходится сталкиваться с функциональными программами, написанными на C или C++, которые работают слишком медленно, потребляют слишком много памяти или, в худшем случае, делают и то и другое. Одним из важнейших средств, предоставляемых C/C++ разработчику для увеличения производительности и предотвращения утечек памяти, является управление выделением и перераспределением памяти. Это руководство проясняет принципы управления памятью на примере создания собственного диспетчера памяти для специальных случаев.

>>> Подробности

★★★

Проверено: Shaman007 ()

Хорошая статья для новичков. Для продвинутых "пользователей" статья слишком поверхностна.

the_coder ★★
()

Пля, слов не матерных нету... Вы еще наизобретайте велосипедов: тред, мутекс, парсер конфигов, контейнер, смарт-поинтер и т.п. И статью напишите.

В нашей конторе за изобретение велосипедов и оптимизацию скорости кода на С++ (!!!) с ходу увольняют ввиду профнепригодности.

anonymous
()

> " ... Команды malloc и new осуществляют вызовы к ядру операционной системы для выделения памяти, а команды free и delete создают запрос для освобождения памяти. Это означает, что операционная система выполняет переключение между пользовательским кодом и кодом ядра каждый раз при выполнении запроса памяти. ..."

4.2

anonymous
()
Ответ на: комментарий от anonymous

А что за контора если не секрет (чтобы не попасть случайно). valgrind по-вашему непрофессионалы писали? На C++ можно написать так неоптимально, что и быстрый процессор не спасет.

anonymous
()
Ответ на: комментарий от anonymous

тебя первого следует уволить за профнепригодность

Reset ★★★★★
()
Ответ на: комментарий от the_coder

За таким - лучше к Мейерсу/Саттеру все-таки... А здесь - как на идиота. Начиная с того, что забыли сказать классическое "прежде чем оптимизировать, проверьте - а там ли узкое место". Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать. Основные тормоза не от этого, а от того, что стандартный менеджер поддерживает весьма сложные структуры для произвольного размера выделяемого блока, примитивный пример чего они и дают. Но кроме первого теста, они скромно не привели время выполнения программы. Подозреваю, что окончательный вариант не быстрее оригинальной реализации new...

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

Резюме - лучше б не писали совсем.

anonymous
()
Ответ на: комментарий от anonymous

Да можно плюсы оптимизировать, и выделение памяти - первый кандидат. И идеи верные, в общем. Просто описано ну совсем уж примитивно и как-то "рецептообразно" - без ссылок, что еще можно прикрутить, что желательно изучить и т.д. на идиота.

anonymous
()
Ответ на: комментарий от anonymous

IMHO достаточно хорошо это освещено у Александреску.

anonymous
()
Ответ на: комментарий от anonymous

>Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать.

+1

Интересно, в Линуксе приложение может отдать память системе? В Солярке память системе никогда не возвращается до завершения процесса. Это и правильно, для ядра процесс занимает непрерывную область памяти, если бы и можно было чего отдать то только уменьшить ее размер, фрагментации не предусмотрено. Возможно и есть какие экзотические исключения, но уж явно не из области new/delete.

A-234 ★★★★★
()
Ответ на: комментарий от A-234

> Интересно, в Линуксе приложение может отдать память системе?

brk(-size), munmap(), mremap()

anonymous
()
Ответ на: комментарий от anonymous

>В нашей конторе за изобретение велосипедов и оптимизацию скорости кода на С++ (!!!) с ходу увольняют ввиду профнепригодности.

Microsoft?

anonymous
()
Ответ на: комментарий от A-234

>Местами просто чушь - например, что memory manager на каждый запрос о выделении берет память у ОС. Они давным-давно сами умеют пулы создавать.

Вообще-то не всегда. Если в кэше аллокатора нет соответствующего блока, то память берется через mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

anonymous
()

Вроде тема провокационная, а так тихо... Все тролли в кдеешной теме?

anonymous
()

Опять велосипеды и самокаты? Уныло. Не ездийте на на них, и на АвтоВазе не ездите. Присоединяйтесь к нормальным людям. У нас интересно. )))

void_ptr ★★★★
()
Ответ на: комментарий от A-234

>Это и правильно, для ядра процесс занимает непрерывную область памяти,

В "непрерывную область памяти" _задачи_ могут мапиться куски памяти откуда угодно, и необязательно памяти.

madcore ★★★★★
()
Ответ на: комментарий от anonymous

> В нашей конторе за изобретение велосипедов и оптимизацию скорости кода на С++ (!!!) с ходу увольняют ввиду профнепригодности.
anonymous (*) (29.07.2008 17:59:35)

как хорошо, что я у вас не работал :)

lester ★★★★
()
Ответ на: комментарий от anonymous

> В нашей быдлоконторе за изобретение велосипедов и оптимизацию скорости кода на С++ (!!!) с ходу увольняют ввиду профнепригодности.

fixed

anonymous
()
Ответ на: комментарий от anonymous

Название быдлоконторы - в студию!

anonymous
()
Ответ на: комментарий от anonymous

Нет ты! Очевидно же.

капча wasing намекает - что был точно.

anonymous
()
Ответ на: комментарий от madcore

>В "непрерывную область памяти" _задачи_ могут мапиться куски памяти откуда угодно, и необязательно памяти.

Во-первых какая разница какая память куда мапится? Во-вторых почувствуйте разницу между задачей - "task" и процессом - "process". И что у нас собственно scheduler переключает - задачи или процессы?

A-234 ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

anonymous
()

> Поделиться этой статьей:
> забобрить 	забобрить 	memori 	сохранить в memori

O_O

vilfred ☆☆
()
Ответ на: комментарий от anonymous

> пускание пыли в глаза и больше ничего. висту делали также? - "оптимизация это пускание пыли в глаза и больше ничего"

anonymous
()
Ответ на: комментарий от anonymous

Баян. IBM че думает одни лохи кругом чтоли? Или там такие тока и работают? Пиздаболы - одно слово

anonymous
()
Ответ на: комментарий от anonymous

сразу видна - ананимусы - жабы :-)

anonymous
()

классно. и свою либу(qt4-стайл). и можно будет писать, по-настоящему БОЛЬШИЕ проекты. начиная с мобильной(любые платформы, энитайм)OS, для таковых ;) взяв за прототип, Mini3, к примеру.

BasileyOne
()

И где тут новость? Подобная хрень описывалась уже не раз. Гнать таких велосипедописателей в три шеи.

Не могу припомнить чтобы выделение памяти было узким местом. Капча pinting со мной согласна.

anonymous
()

Качество исходного текста не обсуждаю, но поскольку перевод сделан ПРОФЕССИОНАЛОМ примерно за 10 центов/слово, смело скажу: переводчика и редактора из ИБМ Россия (особенно последнего) -- фтопку. Вполне себе любительщина. Да, кстати, у них нет ни глоссария, ни руководства по стилю, а основным справочным материалом служат предыдущие переводы, авторизованные компанией. В том числе вот такие, и это вариант ещё не худший :(((

anonymous
()

узкое место - не "выделение памяти"(!!!! студент детектед) узкое место - мозг "памятевыделитель" писателя. что, с оглядкой на олдскул макось(моторола) и виндовз - ОЧЕНЬ УЗКИМ местом можеть быть. или не быть вообще таковым. по факту. написанного.

BasileyOne
()

Отличная статья. Просто прекрасный сборник всего того, что нельзя делать.

Чего только стоят строки

> std::set<BitMapEntry*> FreeMapEntries; > std::map<void*, ArrayMemoryInfo> ArrayMemoryList;

Плюс - бред про переключения контекста в операторах new / delete.

В связи со всем этим у меня вопрос: кто автор сего бреда?

stellar
()
Ответ на: комментарий от anonymous

>поэтому "эффективные" говноплюсы не нужны

Анонимус не нужен.

stellar
()
Ответ на: комментарий от stellar

А что не так с этими строками? И что еще там "нельзя делать"? Ну упрощено все сильно больше, чем надо - это да. Но что там (и главное - почему) - "вредные советы"?

anonymous
()
Ответ на: комментарий от anonymous

>В нашей конторе за ... оптимизацию скорости кода на С++ (!!!) с ходу увольняют ввиду профнепригодности.

А в нашей конторе, за ускорение хотя бы одной из частей программы (на C++) хотя бы на пять процентов премию выписывают...

yz
()

Ну да, напишем свой аллокатор, а про то, что glibc и так освобождённую память оставляет для последующих выделений, и никаких переключений контекста при new/delete благодаря этому не происходит почти никогда, можно и умолчать...

anonymous
()

> Для запуска примеров из этого руководства, вам понадобится ОС Linux или UNIX с установленным компилятором g++. Также понадобится необходимое количество ОЗУ (около 256 Мб).

О боже ... что ж сразу не гиг то

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

что за бред?

> Часто память, выделенная для программы и ненужная в дальнейшем, остается неудаленной.

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

> Компиляция данного теста при помощи gcc-3.4.6 на компьютере под управлением Solaris 10 заняла в среднем 3,5 секунды. Это базовый показатель производительности при использовании глобальных операторов new и delete и стандартного компилятора.

Не понял, а при чем здесь компиляция? Если это не ошибка переводчика и так было в оригинале (кстати не увидел ссылки на оригинал), то это полный бред.

Дальше не стал читать. Новичкам такие статейки крайне не рекомендую читать.

Vark
()
Ответ на: комментарий от yz

> А в нашей конторе, за ускорение хотя бы одной из частей программы (на C++) хотя бы на пять процентов премию выписывают...
Переводите проект на Java - озолотитесь :)

Korwin ★★★
()
Ответ на: комментарий от A-234

>Интересно, в Линуксе приложение может отдать память системе?

канэчно, как и в соляре (munmap например) однако зачем? ос все равно вытащит страницу у процесса из под носа, если clock алгоритм покажет, что она не используется.

>Это и правильно, для ядра процесс занимает непрерывную область памяти,

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

aydef
()
Ответ на: комментарий от Vark

> Не понял, а при чем здесь компиляция? Если это не ошибка переводчика и так было в оригинале (кстати не увидел ссылки на оригинал), то это полный бред.

Это не бред, это подход ИБМ. Наверняка там было run time, а редактор ИБМ Россия хлопнул на перевод печать "Проверено и одобрено!". И пошёл гулять по свету очередной ИБМовсеий косяк типа "восстановление после сбоев" для "disaster recovery" (!!!) -- по их меркам, ураган "Катрина" -- ЭТО СБОЙ... Голубая небесная канцелярия, блин...

Капча: hangher -- висельник, что ли?!...

anonymous
()
Ответ на: комментарий от Vark

> Не понял, а при чем здесь компиляция? Если это не ошибка переводчика и так было в оригинале (кстати не увидел ссылки на оригинал), то это полный бред.

ИБМ -- не Микрософт и даже не САн, ссылки на оригиналы на другших языках не выкладывает.

Путём некоторых ухищрений я нашёл-таки ссылку на оригинал. Вот она:

> http://www.ibm.com/developerworks/edu/au-dw-au-memorymanager-i.html

Однако для просмотра текста оригинала требуется ИБМовская регистрация, которой у меня пока нету (для перевода -- не требуется НИЧЕГО. Оригинально...). Господа, посмотрите, пожалуйста, кто может!...

anonymous
()
Ответ на: комментарий от anonymous

>А что не так с этими строками? И что еще там "нельзя делать"?

1) Скорость поиска по std::map - логарифмическая. Эффективные аллокаторы работают со скоростью O(1).

2) map<void * - это отвратительный тон. Который еще и негарантированно работает.

3) Вранье про сисколлы. Современные операционные системы выделяют память без такого количества переключений контекста.

>Ну упрощено все сильно больше, чем надо - это да. Но что там (и главное - почему) - "вредные советы"?

Не в упрощении дело. А в кривизне примеров.

stellar
()

Напишите уже прогу для постирования на лоре в формате: "... не нужен".

Люди ведь время теряют, мучаются!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.