The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

06.04.2010 12:58  Новая техника управления памятью позволяет ускорить программы на 19%

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

Суть техники в выделении функций динамического распределения памяти в отдельный поток MMT (Memory Management Thread), работающий параллельно и не блокирующий работу основного приложения. В настоящий момент разработчиками подготовлен прототип динамической библиотеки, подменяющей стандартные функции распределения памяти (malloc, free) и не требующей модификации приложения.

Измерение производительности различных программ, в зависимости от активности операций выделения и освобождения блоков памяти, показало, что в среднем программы тратят на выполнение операций по распределению памяти до 30% своего времени выполнения. Использование техники MMT позволяет увеличить скорость работы таких программ в среднем на 19%.

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

  1. Главная ссылка к новости (http://news.ncsu.edu/releases/...)
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: gcc, memory, malloc, free, lib, optimization, speed
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Dcow (?), 13:31, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]
  • –2 +/
    это будет в ядре?
     
     
  • 2.56, sluge (ok), 13:58, 07/04/2010 [^] [ответить]    [к модератору]
  • +1 +/
    ядро то тут причом?
     
  • 1.2, aZ (ok), 13:49, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]
  • –4 +/
    На какой ОС? На виндовс?)
     
     
  • 2.15, Zenitur (?), 14:48, 06/04/2010 [^] [ответить]    [к модератору]
  • +/
    Да на любой.
     
  • 2.31, XoRe (ok), 18:11, 06/04/2010 [^] [ответить]     [к модератору]
  • +2 +/
    От них дождешься Там если явно самому в своей программе накодить А на любой ... весь текст скрыт [показать]
     
     
  • 3.37, Damon (??), 19:11, 06/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Да, как бы не сверх проблема На C в первом приближении , пишете обертку и п... весь текст скрыт [показать]
     
     
  • 4.40, XoRe (ok), 20:44, 06/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Согласен Свой код - своя вольница Но я про то, что в нормальных ОС можно задав... весь текст скрыт [показать]
     
     
  • 5.45, Damon (??), 21:13, 06/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Ну, согласно закону Мерфи -- Если высказывание может быть не понято, непременно... весь текст скрыт [показать]
     
  • 4.57, sluge (ok), 13:59, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    new то тут причем?
    вызвал я скажем strdup-где тут new? все идет от malloc и собратьев, даже new!
     
     
  • 5.60, Damon (??), 15:06, 07/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Я же написал -- в первом приближении , я же не предлагал, как нихрена не делая,... весь текст скрыт [показать]
     
  • 1.3, Konstantin (??), 13:55, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Интересно в PDF-е и в новости написано про прототип динамической библиотеки! Кто нибудь видел link на эту библиотеку?
     
  • 1.4, DeDA (?), 14:01, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    исходники в студию!
     
     
  • 2.14, croster (ok), 14:45, 06/04/2010 [^] [ответить]     [к модератору]  
  • +1 +/
    Искал исходники, но пока не нашел Есть только пара презентаций 1 http www4 ... весь текст скрыт [показать]
     
  • 1.5, iZEN (ok), 14:03, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Это будет хорошо дополнять ZFS prefetch и другие техники файлового кэширования. Правда, при этом, оперативка будет загружена на 100% (однако, память на то и покупается, чтобы использоваться не на 20%, а на полную свою длину).
     
     
  • 2.18, аноним (?), 14:53, 06/04/2010 [^] [ответить]    [к модератору]  
  • +2 +/
    Да, жависты любят эту ересь нести. Только память всегда гораздо лучше пустить под дисковые кэши, чем под забитие бесполезным мусором, как в случае с java.
     
  • 1.6, Анон (?), 14:04, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +6 +/
    Главное чтобы не запатентовали.
     
  • 1.7, sergej (??), 14:17, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Чето я не понял за счет чего ускорение. malloc все равно будет ждать завершения выделения памяти в этом потоке
     
     
  • 2.9, Аноним (-), 14:27, 06/04/2010 [^] [ответить]     [к модератору]  
  • +3 +/
    Аналогично, какая разница в каком потоке выполняется код malloc, если ему всё ра... весь текст скрыт [показать]
     
     
  • 3.44, pavlinux (ok), 21:07, 06/04/2010 [^] [ответить]     [к модератору]  
  • +/
    По сути, для начал использования памяти, достаточно получить указатель на начал... весь текст скрыт [показать]
     
  • 1.8, PatentTroll (?), 14:20, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Начинаю патентовать... :)
     
  • 1.10, Аноним (-), 14:31, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +6 +/
    Заголвок должен быть "Новая техника управления памятью позволяет ускорить плохо распараллеливаемые программы с интенсивным выделением и освобождением памяти на 19%. А то можно подумать, что изобрели какой-то мегаускорятель программ...
     
  • 1.11, Anton (??), 14:39, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Да все просто, делаете отдельный обьект , в который кидаете запросы на выделение памяти.
    Выполнение происходит в отдельном потоке, вот вам и прирост. Поидее так и надо было делать изначально.
     
     
  • 2.12, sergej (??), 14:41, 06/04/2010 [^] [ответить]    [к модератору]  
  • +3 +/
    Ага. А как узнать насколько заранее нужно послать запрос на выделение памяти, что бы он успел ее выделить к тому моменту, когда она понадобится?
     
  • 2.13, IGX (?), 14:43, 06/04/2010 [^] [ответить]    [к модератору]  
  • +6 +/
    полный бред! поток, которому необходима память всё равно будет ожидать окончания выделения памяти другим потоком и не продолжится, пока память не будет выделена
     
     
  • 3.16, Anton (??), 14:52, 06/04/2010 [^] [ответить]    [к модератору]  
  • –1 +/
    Поток с выделением будет выполнятся на другом ядре(процессоре) ,
    а поток из которого был запрос на выделение будет ждать , не занимая ядро(процессор).
     
     
  • 4.19, аноним (?), 14:56, 06/04/2010 [^] [ответить]     [к модератору]  
  • +2 +/
    И откуда тут выигрыш по сравнению с обычным подходом ... весь текст скрыт [показать]
     
     
  • 5.21, Anton (??), 15:08, 06/04/2010 [^] [ответить]    [к модератору]  
  • –2 +/
    потому что запрос будет неблокирующий
     
     
  • 6.23, IGX (?), 15:20, 06/04/2010 [^] [ответить]     [к модератору]  
  • +1 +/
    Специально для особо одарённых танкистов http www ece ncsu edu arpers Papers ... весь текст скрыт [показать]
     
  • 6.27, sergej (??), 16:11, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >> потому что запрос будет неблокирующий

    в пдфке вроде говорят, что интерфейс malloc/free они не ломали. Откуда возьмется неблокирующий malloc?

     
     
  • 7.28, Anton (??), 17:21, 06/04/2010 [^] [ответить]    [к модератору]  
  • –1 +/
    а вы внимательней почитайте
     
  • 7.30, demo (??), 17:56, 06/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Очевидно, что некоторое приближение к неблокирующему malloc-у можно получить тол... весь текст скрыт [показать]
     
  • 6.32, аноним (?), 18:45, 06/04/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    > потому что запрос будет неблокирующий

    Решение предлагается как drop-in замена обычному malloc. Вопрос - что вернет ваш "неблокирующий malloc"?

     
     
  • 7.46, pavlinux (ok), 21:23, 06/04/2010 [^] [ответить]     [к модератору]  
  • –1 +/
    указатель на начало сегмента памяти ... весь текст скрыт [показать]
     
     
  • 8.49, Аноним (-), 22:09, 06/04/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    и когда он выдалять будет и в каком порядке?

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

     
     
  • 9.50, pavlinux (ok), 23:24, 06/04/2010 [^] [ответить]     [к модератору]  
  • –1 +/
    В пространстве пользователя это должны быть линейные адреса А как их сегментиру... весь текст скрыт [показать]
     
  • 8.59, sluge (ok), 14:02, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    в с нет ниаких сегментов памяти
     
     
  • 9.61, pavlinux (ok), 19:39, 07/04/2010 [^] [ответить]     [к модератору]  
  • +/
    Ещё один иди всю Википедию выучи или хотя бы Ожегова, тогда возвращайся И п... весь текст скрыт [показать]
     
  • 8.64, аноним (?), 05:32, 08/04/2010 [^] [ответить]    [к модератору]  
  • +/
    И во что это выльется? Я так могу sbrk вместо маллока использовать.
     
     
  • 9.67, pavlinux (ok), 11:54, 08/04/2010 [^] [ответить]    [к модератору]  
  • +/
    в то, что можно начать использовать до конца не выделенную память. По аналогии с CoW
     
  • 3.17, pazke (?), 14:53, 06/04/2010 [^] [ответить]    [к модератору]  
  • +3 +/
    С выделением памяти действительно непонятно, но вот free() должно выноситься в отдельный тред без проблем.
     
     
  • 4.20, IGX (?), 15:06, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Поддерживаю.
     
  • 4.26, letsmac (?), 15:33, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Ну это уже, наверно, во всех сборщиках мусора реализовано.
     
  • 1.24, DFX (ok), 15:28, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ну пускай вот в glibc добавят, чтож...
     
     
  • 2.25, IGX (?), 15:33, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Спорно, т.к. приведенный метод ускорения будет в каких-то случаях немного ускорять, а в каких-то очень замедлять выделение/освобождение пямяти.
     
     
  • 3.29, Anton (??), 17:49, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Нда?! И в каких он будет замедлять?
     
     
  • 4.33, аноним (?), 18:47, 06/04/2010 [^] [ответить]     [к модератору]  
  • +3 +/
    Если не использовать preallocation, то во всех А если использовать, то оно буде... весь текст скрыт [показать]
     
     
  • 5.39, IGX (?), 20:30, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    И хорошо еще, если ядро свободное найдется на работу потока выделения/освобождения памяти. Потому как если не найдется, то, наверно:
    1) память в лучшем случае будет освобождаться с задержкой, что грозит либо большим перерасходом памяти, либо выделение памяти станет нереально медленным.
    2) выделение памяти во многих случаях станет оооччень медленным по многим причинам.
     
     
  • 6.42, XoRe (ok), 20:50, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >И хорошо еще, если ядро свободное найдется на работу потока выделения/освобождения памяти.
    >Потому как если не найдется, то, наверно:
    >1) память в лучшем случае будет освобождаться с задержкой, что грозит либо
    >большим перерасходом памяти, либо выделение памяти станет нереально медленным.
    >2) выделение памяти во многих случаях станет оооччень медленным по многим причинам.
    >

    Могу предположить, что все ядра, кроме первого, обычно загружены чуть меньше.
    Исходя из той же идеи, что далеко не все программы ещё true smp =)
    Ну и сам по загрузке ядер вижу такую картину.
    Что на сервере, что на десктопе.

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

     
     
  • 7.47, pavlinux (ok), 21:27, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >>И хорошо еще, если ядро свободное найдется на работу потока выделения/освобождения памяти.
    >>Потому как если не найдется, то, наверно:
    >>1) память в лучшем случае будет освобождаться с задержкой, что грозит либо
    >>большим перерасходом памяти, либо выделение памяти станет нереально медленным.
    >>2) выделение памяти во многих случаях станет оооччень медленным по многим причинам.
    >>
    >
    >Могу предположить, что все ядра, кроме первого, обычно загружены чуть меньше.
    >Исходя из той же идеи, что далеко не все программы ещё true
    >smp =)

    Предлагаешь замутить sleep(), wait(), delay() и т.п., c поддержкой SMP
    Если процесс спит, так пущай спит на всех процах сразу?  

     
     
  • 8.52, XoRe (ok), 00:29, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >Предлагаешь замутить sleep(), wait(), delay() и т.п., c поддержкой SMP
    >Если процесс спит, так пущай спит на всех процах сразу?

    =)
    Я просто указываю на то, что нет true smp.
    Да и не думаю, что будет.
    Из этого и исходит мое предположение, что ещё долгое время первое ядро будет более нагружено, чем остальные.
    Особенно на десктопе.

     
     
  • 9.62, Dvorkin (??), 20:16, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    вот мой десктоп (коре квад) секундное измерение:
    cpu 0 usage: 0%
    cpu 1 usage: 2%
    cpu 2 usage: 28%
    cpu 3 usage: 7%

    [dv@dvpc ~]$ uname -r
    2.6.31.12-server-3mnb

     
  • 7.48, IGX (?), 21:42, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    Хотя средняя загрузка процессора не велика, но это не означает, что на каждом участке веремени есть хотя бы одно свободное ядро. Т.е. при небольшом количестве ядер ситуация, когда в конкретный момент времени загружены все ядра велика, что означает огромный лаг (по меркам процессорного времени) при выделении и освобождении памяти, т.е. пауза до тех пор, пока планировщик потоков не даст время потоку выделения/освобождения памяти, а потом, пока планировщик потоков не даст время потоку, которому требовалась память. В Win у вас может уйти на такую операцию 15+15=30 мс (нехилый такой лаг). А если операция выделения/освобождения памяти слишком частые (что говорит лишь о кривой архитектуре программы), то лаги могут быть не только наблюдаемые визуально, но и нехило досаждающие. Не думаю, что вам будет приятно листать страницу в браузере во время упаковки каких-то данных многопоточным 7zip'ом.

    Ну, а если у вас процессор свободен, то никакие ускорения malloc вам не нужны. Тем более 19% для malloc/free, о которых идет речь в данной новости, т.к. в лучшем случае в конечном счете вы получите пару процентов улучшения общей производительности, и то не факт.

     
     
  • 8.53, XoRe (ok), 00:30, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >Хотя средняя загрузка процессора не велика, но это не означает, что на
    >каждом участке веремени есть хотя бы одно свободное ядро. Т.е. при
    >небольшом количестве ядер ситуация, когда в конкретный момент времени загружены все
    >ядра велика, что означает огромный лаг (по меркам процессорного времени) при
    >выделении и освобождении памяти, т.е. пауза до тех пор, пока планировщик
    >потоков не даст время потоку выделения/освобождения памяти, а потом, пока планировщик
    >потоков не даст время потоку, которому требовалась память. В Win у
    >вас может уйти на такую операцию 15+15=30 мс (нехилый такой лаг).

    Если переход с текущей реализации на предлагаемую может вызвать такие лаги, то напрашивается вопрос - а в текущей реализации нет таких лагов?

     
     
  • 9.54, IGX (?), 01:10, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >[оверквотинг удален]
    >>каждом участке веремени есть хотя бы одно свободное ядро. Т.е. при
    >>небольшом количестве ядер ситуация, когда в конкретный момент времени загружены все
    >>ядра велика, что означает огромный лаг (по меркам процессорного времени) при
    >>выделении и освобождении памяти, т.е. пауза до тех пор, пока планировщик
    >>потоков не даст время потоку выделения/освобождения памяти, а потом, пока планировщик
    >>потоков не даст время потоку, которому требовалась память. В Win у
    >>вас может уйти на такую операцию 15+15=30 мс (нехилый такой лаг).
    >
    >Если переход с текущей реализации на предлагаемую может вызвать такие лаги, то
    >напрашивается вопрос - а в текущей реализации нет таких лагов?

    В текущей реализации таких лагов нет, т.к. память выделяется/освобождается в том же потоке, которому она требуется, а описанная возможная ситуация (когда поток выделения/освобождения памяти имеет наивысший приоритет в системе, и других потоков с таким приоритетом в системе нет) возникает исключительно из-за многопоточности. Сейчас ядро любой ОС учитывает ситуации одновременного обращения к нему нескольких потоков, которые требуют выделить/освободить для них память или другие объекты ядра.

     
     
  • 10.55, XoRe (ok), 11:11, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >В текущей реализации таких лагов нет, т.к. память выделяется/освобождается в том же
    >потоке, которому она требуется, а описанная возможная ситуация (когда поток выделения/освобождения
    >памяти имеет наивысший приоритет в системе, и других потоков с таким
    >приоритетом в системе нет) возникает исключительно из-за многопоточности. Сейчас ядро любой
    >ОС учитывает ситуации одновременного обращения к нему нескольких потоков, которые требуют
    >выделить/освободить для них память или другие объекты ядра.

    Т.е. лаги могут быть, если много программ одновременно потребуют память?
    Кстати, в винде такое врядли будет реализовываться, так что на её лаги пофиг)

     
  • 1.34, аноним (?), 18:49, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    > Using the new technique, when a memory-management function needs to be performed, “the computational thread notifies the memory-management thread – effectively telling it to allocate data storage and to notify the computational thread of where the storage space is located,” says Devesh Tiwari, a Ph.D. student at NC State and lead author of the paper. “By the same token, when the computational thread no longer needs certain data, it informs the memory-management thread that the relevant storage space can be freed.”

    Бгыгы, и что, computational thread не заблокирована на это время? Бред какой-то.

     
     
  • 2.36, Andrey Mitrofanov (?), 19:05, 06/04/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    >Бгыгы, и что, computational thread не заблокирована на это время? Бред какой-то. >

    Это _академический опен-сорс такой. Диссертация про коня в вакууме, потом, если повезёт, закрытые тесты-реализации-бенчмарки (как щас вижу - на win* или *BSD) с ещё более громкими заголовками, потом продажа венчурным капиталистам =>профит. А ускоряет оно маллок в глибц, не ускоряет... __Так_и_не_обещал_же_никто.__

     
     
  • 3.41, fresco (??), 20:45, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    не исключено
     
  • 3.65, аноним (?), 05:34, 08/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >Это _академический опен-сорс такой. Диссертация про коня в вакууме, потом, если повезёт, закрытые тесты-реализации-бенчмарки (как щас вижу - на win* или *BSD) с ещё более громкими заголовками, потом продажа венчурным капиталистам =>профит. А ускоряет оно маллок в глибц, не ускоряет... __Так_и_не_обещал_же_никто.__

    На win* или *nux. На BSD как раз самых эффективный аллокатор из существующих.

     
     
  • 4.66, Andrey Mitrofanov (?), 09:34, 08/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >>Это _академический опен-сорс такой
    >>закрытые тесты-реализации-бенчмарки (как щас вижу - на win* или *BSD)
    >>__Так_и_не_обещал_же_никто.__
    >На win* или *nux. На BSD как раз самых эффективный аллокатор из существующих.

    Так-так!? Что зироты BSD имеют сказать за борьбу с академ-пен-сорсом и мировой иссследовательскай наукай?!

     
  • 1.38, funky_dennis (?), 20:22, 06/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    http://www.google.ru/search?q=tcmalloc
    чем не понравился им?
     
     
  • 2.43, XoRe (ok), 20:53, 06/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >http://www.google.ru/search?q=tcmalloc
    >чем не понравился им?

    Возможно, лицензией.
    А может просто, своя велосипеда ближе к телу)

     
  • 2.51, pavlinux (ok), 00:26, 07/04/2010 [^] [ответить]    [к модератору]  
  • +/
    >http://www.google.ru/search?q=tcmalloc
    >чем не понравился им?

    О, это такая клёвая хрень...

    # svn checkout http://google-perftools.googlecode.com/svn/trunk/ google-perftools
    # cd google-perftools
    # ./autogen.sh
    # ./configure
    # make
    # make check
    ...
    ...
    ======================================
    8 of 25 tests failed
    Please report to opensource@google.com
    ======================================
    make[1]: *** [check-TESTS] Ошибка 1
    make[1]: Leaving directory '/usr/src/google-perftools'
    make: *** [check-am] Ошибка 2


    # LD_PRELOAD=./.libs/libtcmalloc.so firefox
    Ошибка сегментирования

     
  • 1.58, sluge (ok), 14:01, 07/04/2010 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    звучит заманчиво
    но не поверю пока сам не попробую
     
  • 1.63, Аноним (-), 23:01, 07/04/2010 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Прогресс такой прогресс Сначала напридумывают языков с динамической типизацией,... весь текст скрыт [показать]
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor