https://www.opennet.me/openforum/vsluhforumID9/8684.html Здравствуйте!<br>Вопрос о многопоточном приложении. Задача параллелиться путем разделения на очень много очень мелких подзадач (200-1000 умножений/суммирований), которые выплняються практически независимо. Для синхронизации есть ячейка памяти типа int, с которой надо значение считать (id фрагмента для обработки) и увеличить на 1 (пока меньше некоторого значения). Сначала использовал для синхронизации доступа семафор и все работало. Но реально скорость росла до 6 процессоров (SMP), дальше выполнение замедлялось, вероятно из-за малости параллельных фрагментов для обработки (нельзя увеличить) и дороговизны синхронизации семафорами. Потому я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). Теперь код &#171;проскакивает&#187; значения т.е. не останавливаеться при достижении заданого количества счетчика фрагментов. Может, это конечно проблемы с отладкой, но все работает с семафорами, и при замедлении (пересчитать все 10 раз), и в 1-потоковом режиме. Вот я и подумал, может это процессор не успевает п https://www.opennet.me/openforum/vsluhforumID9/8684.html#8 Mon, 12 Apr 2010 05:35:46 GMT &gt; не могу понять как такое может быть <br>&gt;впринципе... <br><br>Шансы что ты распараллелишь лучше openmp - крайне малы. OpenMP использует пул потоков, который намного эффективнее создания потоков. С ним вероятность сделать ошибку, приводящую к неправильным результатам или падению производительности намного ниже.<br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#7 Sat, 10 Apr 2010 00:25:00 GMT &gt;Интереснее было бы узнать какой результат показал на этой задаче OpenMP. <br>&gt;Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку. <br>&gt;<br><br>Ваше сообщение поставило меня в тупик :). Не могли бы Вы тезисно пояснить как некая надстройка может быть быстрее прямого взаимодействия нитей? Тоесть я Вас ни в коем случае не критикую ибо не имею практики с OpenMP, но не могу понять как такое может быть впринципе... <br><br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#6 Fri, 09 Apr 2010 12:59:36 GMT Интереснее было бы узнать какой результат показал на этой задаче OpenMP.<br>Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.<br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#5 Thu, 08 Apr 2010 23:08:53 GMT Всем спасибо, ошибка нашлась в коде (были гонки с main потоком по включению/засыпанию расчетных потоков при переходе к параллельным вычислениям и назад). <br>Да, о pthread_mutex в NPTL я и говорил (честно говоря с чистыми фьютексами чувствую себя некомфортно и как-то запутанно). <br>П.С. Если кому интересно подобный опыт, то код с скмафорами на 16-ядерном SMP Xeon E7340 @2.4GHz, Linux 2.6.9-55 забирал 600-800% по top, а теперь 1550-1570% (почти случайные франменты данных из 30Mb процесса). Это для параллельного расчета подзадач на 200-1000 умножений/суммирований, общий ресурс - из 1 ячейка int считываеться и увеличиваеться на 1. Это я к тому что для числодробилок вообще штатная ситуация когда многие, но весьма маленькие куски можно расчитывать независимо (тратить 1 поток на сборку кусков и подготовку нових пока все остальные их перемалывают) ну и так, если не дергать ядро, можно вполне эффективно распараллелить код для алгоритма, который вообще-то не параллелиться. Вывод: не зря шумели вокруг фьютексов :).<br> <br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#4 Thu, 08 Apr 2010 08:27:40 GMT &gt;видимо используются fast userspace mutexes <br><br>Его и использует pthread_mutex в NPTL.<br><br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#3 Thu, 08 Apr 2010 06:53:27 GMT &gt;&gt;я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).<br>&gt;<br>&gt;pthread_mutex? <br>&gt;<br><br>видимо используются fast userspace mutexes <br><br>int sys_futex (void *futex, int op, int val, const struct timespec *timeout); <br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#2 Wed, 07 Apr 2010 06:48:44 GMT &gt;я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые).<br><br>pthread_mutex?<br><br>&gt;&#171;проскакивает&#187; значения т.е. не останавливаеться при достижении заданого количества <br><br>Где-то забыл блокировку. Вероятно на проверке этого самого значения.<br><br> https://www.opennet.me/openforum/vsluhforumID9/8684.html#1 Wed, 07 Apr 2010 02:07:54 GMT &gt;Вот я и подумал, может это процессор не успевает перенести из <br>&gt;кеша в память новое значение счетчика, пока его считает второй процессор <br>&gt;(ведь мьютекс защищает только на время считывания и арифметики первого CPU)? <br><br>У многоядерного камня кэш один на все ядра, у многопроцессорной системы принимаются специальные меры, чтобы кэш был "когерентный" между всеми процессорами. Это одна из причин, почему многоголовые матери такие дорогие. Хотя баг в чипсете возможен, но маловероятен. Что вероятнее - дешёвая мать _вообще без_ когерентного кэша. При таком раскладе попробуй включить режим кэша write-through.<br><br>Уточни - что за процессоры, что за чипсет, что за мать. Может кто слышал про грабли именно с ними.<br><br>