| |
| 2.31, XoRe (ok), 18:11, 06/04/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>На какой ОС? На виндовс?)
От них дождешься =)
Там если явно самому в своей программе накодить.
А на любой нормальной ОС, где можно подсовывать разные реализации malloc, возможно все перевести на ту реализацию, которая больше нравится.
| | |
| |
| 3.37, Damon (??), 19:11, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > Там если явно самому в своей программе накодить.
Да, как бы не сверх проблема. На C++ (в первом приближении!), пишете обертку и перегружаете глобальный оператор new. STL, по дефолту, использует глобальный оператор, но позволяет указать одним из параметров шаблона свой аллокатор (еще один путь)...
Ну а "чисто" на C, под вындос вряд ли сейчас кто пишет, впрочем, там можно по шаманить с опциями линкера, попытаться заставить его слинковать нужную либу и использовать именно нужную ф-цию. Когда-то давно читал, что new из библиотек VS6 пользует malloc (понятия не имею, как сейчас), т.ч. данный путь может оказаться универсальным.
Ну а шарписты, видимо, в пролете...
| | |
| |
| 4.40, XoRe (ok), 20:44, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Там если явно самому в своей программе накодить.
>
>Да, как бы не сверх проблема.
Согласен.
Свой код - своя вольница.
Но я про то, что в нормальных ОС можно задавать реализацию malloc для всех программ.
Я имею в виду для всех уже скомпиленных программ.
Ну кроме статически скомпиленных)
А попробуйте такой же трюк проделать в винде.
Я так понимаю, там и статическая компиляция практикуется куда чаще.
| | |
| |
| 5.45, Damon (??), 21:13, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Но я про то, что в нормальных ОС можно задавать реализацию malloc
>для всех программ.
>Я имею в виду для всех уже скомпиленных программ.
>Ну кроме статически скомпиленных)
Ну, согласно закону Мерфи -- "Если высказывание может быть не понято, непременно найдется тот, кто его не поймет!" ((С) как-то так :-), ну а я человек маленький и законопослушный... :-)
Вобщем, извиняюсь, не так понял.
| | |
|
| 4.57, sluge (ok), 13:59, 07/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
new то тут причем?
вызвал я скажем strdup-где тут new? все идет от malloc и собратьев, даже new!
| | |
| |
| 5.60, Damon (??), 15:06, 07/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
>new то тут причем?
>вызвал я скажем strdup-где тут new?
Я же написал -- "в первом приближении", я же не предлагал, как нихрена не делая, поиметь кучу выгод, так только МММ в свое время делала, где она теперь, Вы (думаю) в курсе...
Вместо char*, пользуйте std::string, там используется new, или, вообще, свой аллокатор указать можно...
>все идет от malloc и собратьев,
>даже new!
"Анатомия C Run-Time, или Как сделать программу немного меньшего размера" ( http://www.rsdn.ru/article/cpp/crt.xml ):
"Обычно C/C++-программа опирается на мощную поддержку С Run-Time Library - библиотека времени исполнения языка C, далее - CRT; более редкое название - RTL (Run-Time Library). Многим функциям этой библиотеки для правильной работы требуется дополнительная инициализация (CRT startup code). В частности, для вывода текста на консоль с помощью функции printf необходимо, чтобы дескриптор стандартного вывода stdout был предварительно связан с устройством вывода операционной системы (например, стандартным выводом и консолью Win32). То же самое справедливо и для функций работы с кучей - таких, как malloc для C и оператора new для C++.
...
А сам код CRT находится в динамической библиотеке MSVCRT.DLL в системном каталоге Windows. Эта многопоточная библиотека используется и некоторыми бесплатными компиляторами C/C++ для Windows, например, MinGW."
Пишите свою dll, где делаете форвардинг всех ф-ций на оригинал, кроме malloc/free, ну и еще чего-нить, навроде realloc... При линковке линкуете со своей либой.
По мойму, не так уж и офигенно сложно...
| | |
|
|
|
|
| 1.3, Konstantin (??), 13:55, 06/04/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно в PDF-е и в новости написано про прототип динамической библиотеки! Кто нибудь видел link на эту библиотеку?
| | |
| 1.5, iZEN (ok), 14:03, 06/04/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Это будет хорошо дополнять ZFS prefetch и другие техники файлового кэширования. Правда, при этом, оперативка будет загружена на 100% (однако, память на то и покупается, чтобы использоваться не на 20%, а на полную свою длину).
| | |
| |
| 2.18, аноним (?), 14:53, 06/04/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да, жависты любят эту ересь нести. Только память всегда гораздо лучше пустить под дисковые кэши, чем под забитие бесполезным мусором, как в случае с java.
| | |
|
| 1.7, sergej (??), 14:17, 06/04/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Чето я не понял за счет чего ускорение. malloc все равно будет ждать завершения выделения памяти в этом потоке
| | |
| |
| 2.9, Аноним (-), 14:27, 06/04/2010 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Чето я не понял за счет чего ускорение. malloc все равно будет ждать завершения выделения памяти в этом потоке
Аналогично, какая разница в каком потоке выполняется код malloc, если ему всё равно нужно блокироваться от конкурентных запросов?
| | |
| |
| 3.44, pavlinux (ok), 21:07, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
По сути, для начал использования памяти, достаточно получить указатель
на начало сегмента.
int A[ULONG_LONG_MAX];
int *prt;
if ( (pid = fork()) == 0 ) {
ptr = super_malloc(ULONG_LONG_MAX);
exit 0;
}
if ( pid > 0 ) {
memcpy(ptr, A, ULONG_LONG_MAX * sizeof (int));
}
...
...
В общем, пока второй делает маллоку, первый начинает её юзать.
Если ядро дробит память на страницы, то по мере доступности всего
запрашиваемого размера, можно ставить мутексы, спинлоки.
Но тогда уже memcpy должен отрабатывать ожидание в очереди на выделение.
| | |
|
|
| 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 +/– |
>Поток с выделением будет выполнятся на другом ядре(процессоре) ,
>а поток из которого был запрос на выделение будет ждать , не
>занимая ядро(процессор).
И откуда тут выигрыш по сравнению с обычным подходом?
| | |
| |
| |
| 6.23, IGX (?), 15:20, 06/04/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Специально для особо одарённых танкистов: http://www.ece.ncsu.edu/arpers/Papers/MMT_IPDPS10.pdf
Простейший подход к многопоточному выделению/освобождению памяти приводит к замедлению выделения/освобождения памяти в несколько раз. В представленном решении приведены техники по преодолению замедляющих факторов.
Моё мнение: большинство из этих техник, а также более продвинутые техники, способны дать выигрыш гораздо больший при организации программы без многопоточности.
| | |
| 6.27, sergej (??), 16:11, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>> потому что запрос будет неблокирующий
в пдфке вроде говорят, что интерфейс malloc/free они не ломали. Откуда возьмется неблокирующий malloc?
| | |
| |
| 7.30, demo (??), 17:56, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
Очевидно, что некоторое приближение к неблокирующему malloc-у можно получить только посредством preallocation и организации нескольких "маленьких куч" - по одной на поток; или если потоков много больше чем процессорных ядер - то можно организовать несколько "коммунальных" куч с диспетчеризацией malloc-ов по правилу "round robin". Получается почти-неблокирующий-malloc. Коллеги в tbsoft когда-то экспериментировали с такими аллокаторами и достигли заметных успехов.
| | |
|
| 6.32, аноним (?), 18:45, 06/04/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> потому что запрос будет неблокирующий
Решение предлагается как drop-in замена обычному malloc. Вопрос - что вернет ваш "неблокирующий malloc"?
| | |
| |
| 7.46, pavlinux (ok), 21:23, 06/04/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> потому что запрос будет неблокирующий
>
>Решение предлагается как drop-in замена обычному malloc. Вопрос - что вернет ваш
>"неблокирующий malloc"?
указатель на начало сегмента памяти.
:)
| | |
| |
| 8.49, Аноним (-), 22:09, 06/04/2010 [^] [^^] [^^^] [ответить] | +1 +/– | и когда он выдалять будет и в каком порядке если он к моменту возвращения еще н... текст свёрнут, показать | | |
|
|
|
|
|
| 3.17, pazke (?), 14:53, 06/04/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
 С выделением памяти действительно непонятно, но вот free() должно выноситься в отдельный тред без проблем.
| | |
|
|
| |
| 2.25, IGX (?), 15:33, 06/04/2010 [^] [^^] [^^^] [ответить]
| +/– |
Спорно, т.к. приведенный метод ускорения будет в каких-то случаях немного ускорять, а в каких-то очень замедлять выделение/освобождение пямяти.
| | |
| |
| |
| 4.33, аноним (?), 18:47, 06/04/2010 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Нда?! И в каких он будет замедлять?
Если не использовать preallocation, то во всех. А если использовать, то оно будет жрать лишнюю память. Лучше просто головой подумать, перед тем как в inner loop маллочить четыре байта.
| | |
| |
| 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 [^] [^^] [^^^] [ответить] | +/– | Я просто указываю на то, что нет true smp Да и не думаю, что будет Из этого... текст свёрнут, показать | | |
|
| 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 [^] [^^] [^^^] [ответить] | +/– | Если переход с текущей реализации на предлагаемую может вызвать такие лаги, то н... текст свёрнут, показать | | |
| |
| 9.54, IGX (?), 01:10, 07/04/2010 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален В текущей реализации таких лагов нет, т к память выделя... текст свёрнут, показать | | |
| |
| 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.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 имеют сказать за борьбу с академ-пен-сорсом и мировой иссследовательскай наукай?!
| | |
|
|
|
| |
| 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.63, Аноним (-), 23:01, 07/04/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прогресс такой прогресс. Сначала напридумывают языков с динамической типизацией, сборщиками мусора, безграничными строками. Ересь. Для критических приложений есть С, каждый поток со своим стеком, стоимость выделения минимальна. Размером управляется железом. Да, может не так оптимально, но память физически жрётся приемлемо. malloc/free в хорошо спроектированной программе нужны в начале и конце обработки. Всё остальное от лукавого.
| | |
|
