tag:blogger.com,1999:blog-10303035.post8216385802512981437..comments2024-02-04T23:20:04.066+03:00Comments on Алёна C++: Фрагментация памяти в C++ приложенияхAlenahttp://www.blogger.com/profile/09389124127364799922noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-10303035.post-42401630336052179622018-03-06T19:37:04.404+03:002018-03-06T19:37:04.404+03:00В свое время потратил много времени на исследовани...В свое время потратил много времени на исследование распределителей. В общем случае лучше всего с проблемой справляется jemalloc. Boost pool вам поможет только если вы используете один поток, если-же нет - то синхронизация "влоб" через критические секции или еще куда хуже мьютексы уничтожит производительность приложения. Boost Pool по-сути работает хорошо если его использовать как allocator для STL контейнера (или обойтись C++ 17 http://en.cppreference.com/w/cpp/experimental/polymorphic_allocator). Альтернативно можно "поиграться" с неблокирующими алгоритмами как я https://github.com/incoder1/small-object-allocator<br /> Victorhttps://www.blogger.com/profile/13680428415154708392noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-21835172672238561842015-07-14T11:58:23.242+03:002015-07-14T11:58:23.242+03:00Поскольку процессоры Intel имеют 42-битную адресну...Поскольку процессоры Intel имеют 42-битную адресную линию, то теоретический размер виртуального адресного пространства "всего" 256 терабайт. При этом обычные выпуски Windows разрешают только 8 терабайт виртуального пространства на процесс. Серверные и Win 8.1 - 128 терабайт.<br /><br />Учитывая, что обрабатываемые объемы данных растут, то фрагментировать доступные лимиты - дело времени.Kirill V. Lyadvinskyhttp://www.codeatcpp.comnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-6459631182955724272015-07-11T14:53:00.693+03:002015-07-11T14:53:00.693+03:00Есть такая проблема. Чем то подобным занимался год...Есть такая проблема. Чем то подобным занимался года полтора назад.<br />На самом деле правильно ее понимать не как проблему фрагментации памяти,<br />а как проблему фрагментации адресного пространства процесса, когда операционка <br />тебе может еще выделить физические страницы а непрерывных номерков <br />в адресном пространстве уже не найти куда это отобразить чтоб выделить <br />непрерывный кусок необходимой длины.<br /><br />В общем это больше проблема x32 легаси приложений, которые по каким то причинам пока <br />не получается перевести на x64. <br />как я понимаю для x64 приложений такой проблемы быть не должно.<br />Представте себе что у вас изза фрагментации на x32 адресном пространстве иногда заканчиваются<br />непрерывные номерки. А теперь представьте себе что вы работаете с x64 адресным пространством,<br />где адресного пространства в 4 миллиарда раз больше.<br /><br />Если всетаки вынуждены работать с x32 и есть такая проблема, то есть рекомендации <br />"хранить" отельно объекты с разным временем жизни. То есть отделять долгоживущие от<br />короткоживущих в адресном пространстве. Для этого можно завести отдельную кучу например и хранить<br />там всю долгоживущую мелочь к примеру чтоб она не била пространство где живут к примеру <br />короткоживущие большие объекты. Использование разных куч как то гарантирует разделенность<br />в пространстве разных по природе объектов.<br /><br />упомянутый выше LFH флаг помог только в плане увеличить производительность аллокаций на win 2003 server (x32)<br />когда на "свежей" куче загрузка отрабатывала скажем за 5 сек, а потом уже тупила 20-40-60 сек....<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-2895873524078443932015-07-01T22:18:52.813+03:002015-07-01T22:18:52.813+03:00tcmalloc неплохая вещь, некоторый эффект даёт.tcmalloc неплохая вещь, некоторый эффект даёт.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-6935094378911069962015-07-01T14:25:28.158+03:002015-07-01T14:25:28.158+03:00И еще хотел бы отметить насчет того, что не только...И еще хотел бы отметить насчет того, что не только С++ программист управляет памятью самостоятельно. При разработке серьезных приложений, в общем случае неплохо бы понимать что происходит за кулисами. Создавая программы на C# тоже можно легко попасть в неприятную ситуацию с памятью.Kirill V. Lyadvinskyhttps://www.blogger.com/profile/03118738824565485127noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-7584436122606945322015-07-01T14:14:20.651+03:002015-07-01T14:14:20.651+03:00В Windows есть Low-fragmentation Heap, которая вес...В Windows есть Low-fragmentation Heap, которая весьма неплохо справляется с фрагментацией. Бороться с фрагментацией приходится только в весьма специфичных случаях. Хотя куча в таком режиме по умолчанию работает в Vista, а в более ранних версиях ее можно включить, но реально хорошо это работает начиная с Windows 7. Поэтому в большинстве случаев лучше не пытаться решать проблему фрагментации, пока не ясно, что она реально будет проявляться. Это просто потому, что может выйти хуже, чем если ничего не делать.<br /><br />Win7 вообще довольно удачная вышла в плане разных плюшек. Тот же пул потоков в Windows 7 работает гораздо лучше, чем в Windows XP. Просто потому, что в WinXP он не умеет адекватно использовать более 2-х ядер процессора.Кириллhttp://www.codeatcpp.comnoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-202974600387388502015-06-30T10:27:57.654+03:002015-06-30T10:27:57.654+03:00slab / arena / pool дают отличный результат, если ...slab / arena / pool дают отличный результат, если система изначально строилась с учетом кастомных аллокаторов. Если есть уже работающий код с, например, STL контейнерами (дающими иллюзию легкой кастомизации аллокаторов), то кроме jemalloc можно попробовать tcmalloc.<br />Для полноты картины надо упомянуть, что, кажется, с седьмой винды, (2013 сервер), в винде low fragmentation heap включен по дефолту, и он старается делать примерно то же, что и jemalloc / tcmalloc. Только имплементация у него закрытая, на статистику его не взглянешь, и я знаю как минимум один большой виндовый проект, на котором tcmalloc в тестах показал себя сильно лучше.moriartynoreply@blogger.comtag:blogger.com,1999:blog-10303035.post-68855629928421973052015-06-30T03:41:01.366+03:002015-06-30T03:41:01.366+03:00SLAB это не Linux-specific(вообще впервые появился...SLAB это не Linux-specific(вообще впервые появился в Solaris). <br />Насколько я понимаю Boost.Pool довольно нетривиально использовать в контексте singleton так как вручную приходится освобождать выделенную pool'ом память. И если я правильно понимаю то будет создано 2 независимых pool'а для int и bool, и что еще хуже, для int и struct {int}.<br />Я бы рекомендовал использовать <a href="http://www.canonware.com/jemalloc/" rel="nofollow">jemalloc</a>. Вроде есть сборки и под MS Windows.Ni@mhttps://www.blogger.com/profile/08597984409156766747noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-58714692138792271052015-06-29T23:02:57.846+03:002015-06-29T23:02:57.846+03:00afiskon
А как же слаб алокейторы?
Это нечто Linu...<b>afiskon</b><br /><br /><i>А как же слаб алокейторы?</i><br /><br />Это нечто Linux-специфичное, а я-то под Windows пишу. По фунциональности это примерно то же, что и object_pool.Alenahttps://www.blogger.com/profile/09389124127364799922noreply@blogger.comtag:blogger.com,1999:blog-10303035.post-83394276018437456112015-06-29T22:45:42.099+03:002015-06-29T22:45:42.099+03:00А как же слаб алокейторы?А как же слаб алокейторы?afiskonhttp://eax.me/noreply@blogger.com