 синхронизация с быстрым мьютексом,  ghost_in_machine, 07-Апр-10, 05:29 [смотреть все]Здравствуйте!
Вопрос о многопоточном приложении. Задача параллелиться путем разделения на очень много очень мелких подзадач (200-1000 умножений/суммирований), которые выплняються практически независимо. Для синхронизации есть ячейка памяти типа int, с которой надо значение считать (id фрагмента для обработки) и увеличить на 1 (пока меньше некоторого значения). Сначала использовал для синхронизации доступа семафор и все работало. Но реально скорость росла до 6 процессоров (SMP), дальше выполнение замедлялось, вероятно из-за малости параллельных фрагментов для обработки (нельзя увеличить) и дороговизны синхронизации семафорами. Потому я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). Теперь код «проскакивает» значения т.е. не останавливаеться при достижении заданого количества счетчика фрагментов. Может, это конечно проблемы с отладкой, но все работает с семафорами, и при замедлении (пересчитать все 10 раз), и в 1-потоковом режиме. Вот я и подумал, может это процессор не успевает перенести из кеша в память новое значение счетчика, пока его считает второй процессор (ведь мьютекс защищает только на время считывания и арифметики первого CPU)? Вопрос, может ли такое быть и, если да, то как с этим максимально эффективно бороться в Linux.
Спасибо.
|
- синхронизация с быстрым мьютексом, ACCA, 06:07 , 07-Апр-10 (1)
>Вот я и подумал, может это процессор не успевает перенести из
>кеша в память новое значение счетчика, пока его считает второй процессор
>(ведь мьютекс защищает только на время считывания и арифметики первого CPU)? У многоядерного камня кэш один на все ядра, у многопроцессорной системы принимаются специальные меры, чтобы кэш был "когерентный" между всеми процессорами. Это одна из причин, почему многоголовые матери такие дорогие. Хотя баг в чипсете возможен, но маловероятен. Что вероятнее - дешёвая мать _вообще без_ когерентного кэша. При таком раскладе попробуй включить режим кэша write-through. Уточни - что за процессоры, что за чипсет, что за мать. Может кто слышал про грабли именно с ними. - синхронизация с быстрым мьютексом, svn, 10:48 , 07-Апр-10 (2)
>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).pthread_mutex? >«проскакивает» значения т.е. не останавливаеться при достижении заданого количества Где-то забыл блокировку. Вероятно на проверке этого самого значения.
- синхронизация с быстрым мьютексом, Kane, 10:53 , 08-Апр-10 (3)
>>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).
>
>pthread_mutex?
>видимо используются fast userspace mutexes int sys_futex (void *futex, int op, int val, const struct timespec *timeout);
- синхронизация с быстрым мьютексом, svn, 12:27 , 08-Апр-10 (4)
>видимо используются fast userspace mutexes Его и использует pthread_mutex в NPTL.
- синхронизация с быстрым мьютексом, ghost_in_machine, 03:08 , 09-Апр-10 (5)
Всем спасибо, ошибка нашлась в коде (были гонки с main потоком по включению/засыпанию расчетных потоков при переходе к параллельным вычислениям и назад).
Да, о pthread_mutex в NPTL я и говорил (честно говоря с чистыми фьютексами чувствую себя некомфортно и как-то запутанно).
П.С. Если кому интересно подобный опыт, то код с скмафорами на 16-ядерном SMP Xeon E7340 @2.4GHz, Linux 2.6.9-55 забирал 600-800% по top, а теперь 1550-1570% (почти случайные франменты данных из 30Mb процесса). Это для параллельного расчета подзадач на 200-1000 умножений/суммирований, общий ресурс - из 1 ячейка int считываеться и увеличиваеться на 1. Это я к тому что для числодробилок вообще штатная ситуация когда многие, но весьма маленькие куски можно расчитывать независимо (тратить 1 поток на сборку кусков и подготовку нових пока все остальные их перемалывают) ну и так, если не дергать ядро, можно вполне эффективно распараллелить код для алгоритма, который вообще-то не параллелиться. Вывод: не зря шумели вокруг фьютексов :).
- синхронизация с быстрым мьютексом, svn, 16:59 , 09-Апр-10 (6)
Интереснее было бы узнать какой результат показал на этой задаче OpenMP.
Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.
- синхронизация с быстрым мьютексом, ghost_in_machine, 04:25 , 10-Апр-10 (7)
>Интереснее было бы узнать какой результат показал на этой задаче OpenMP.
>Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.
>Ваше сообщение поставило меня в тупик :). Не могли бы Вы тезисно пояснить как некая надстройка может быть быстрее прямого взаимодействия нитей? Тоесть я Вас ни в коем случае не критикую ибо не имею практики с OpenMP, но не могу понять как такое может быть впринципе...
- синхронизация с быстрым мьютексом, svn, 09:35 , 12-Апр-10 (8)
> не могу понять как такое может быть
>впринципе... Шансы что ты распараллелишь лучше openmp - крайне малы. OpenMP использует пул потоков, который намного эффективнее создания потоков. С ним вероятность сделать ошибку, приводящую к неправильным результатам или падению производительности намного ниже.
|
Версия для распечатки
