форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (C/C++)
Изначальное сообщение		[ Отслеживать ]

"синхронизация с быстрым мьютексом"		+/–
Сообщение от ghost_in_machine on 07-Апр-10, 05:29
Здравствуйте! Вопрос о многопоточном приложении. Задача параллелиться путем разделения на очень много очень мелких подзадач (200-1000 умножений/суммирований), которые выплняються практически независимо. Для синхронизации есть ячейка памяти типа int, с которой надо значение считать (id фрагмента для обработки) и увеличить на 1 (пока меньше некоторого значения). Сначала использовал для синхронизации доступа семафор и все работало. Но реально скорость росла до 6 процессоров (SMP), дальше выполнение замедлялось, вероятно из-за малости параллельных фрагментов для обработки (нельзя увеличить) и дороговизны синхронизации семафорами. Потому я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). Теперь код «проскакивает» значения т.е. не останавливаеться при достижении заданого количества счетчика фрагментов. Может, это конечно проблемы с отладкой, но все работает с семафорами, и при замедлении (пересчитать все 10 раз), и в 1-потоковом режиме. Вот я и подумал, может это процессор не успевает перенести из кеша в память новое значение счетчика, пока его считает второй процессор (ведь мьютекс защищает только на время считывания и арифметики первого CPU)? Вопрос, может ли такое быть и, если да, то как с этим максимально эффективно бороться в Linux. Спасибо.
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "синхронизация с быстрым мьютексом"		+/–
Сообщение от ACCA (ok) on 07-Апр-10, 06:07
>Вот я и подумал, может это процессор не успевает перенести из >кеша в память новое значение счетчика, пока его считает второй процессор >(ведь мьютекс защищает только на время считывания и арифметики первого CPU)? У многоядерного камня кэш один на все ядра, у многопроцессорной системы принимаются специальные меры, чтобы кэш был "когерентный" между всеми процессорами. Это одна из причин, почему многоголовые матери такие дорогие. Хотя баг в чипсете возможен, но маловероятен. Что вероятнее - дешёвая мать _вообще без_ когерентного кэша. При таком раскладе попробуй включить режим кэша write-through. Уточни - что за процессоры, что за чипсет, что за мать. Может кто слышал про грабли именно с ними.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "синхронизация с быстрым мьютексом"		+/–
Сообщение от svn (??) on 07-Апр-10, 10:48
>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). pthread_mutex? >«проскакивает» значения т.е. не останавливаеться при достижении заданого количества Где-то забыл блокировку. Вероятно на проверке этого самого значения.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от Kane (ok) on 08-Апр-10, 10:53
	>>я переписал на синхронизацию мьютексом (ядро 2.6, мьютексы быстрые). > >pthread_mutex? > видимо используются fast userspace mutexes int sys_futex (void *futex, int op, int val, const struct timespec *timeout);
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от svn (??) on 08-Апр-10, 12:27
	>видимо используются fast userspace mutexes Его и использует pthread_mutex в NPTL.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от ghost_in_machine on 09-Апр-10, 03:08
	Всем спасибо, ошибка нашлась в коде (были гонки с 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 поток на сборку кусков и подготовку нових пока все остальные их перемалывают) ну и так, если не дергать ядро, можно вполне эффективно распараллелить код  для алгоритма, который вообще-то не параллелиться. Вывод: не зря шумели вокруг фьютексов :).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от svn (??) on 09-Апр-10, 16:59
	Интереснее было бы узнать какой результат показал на этой задаче OpenMP. Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от ghost_in_machine on 10-Апр-10, 04:25
	>Интереснее было бы узнать какой результат показал на этой задаче OpenMP. >Вполне вероятно что было бы ещё лучше, и меньше вероятность сделать ошибку. > Ваше сообщение поставило меня в тупик :). Не могли бы Вы тезисно пояснить как некая надстройка может быть быстрее прямого взаимодействия нитей? Тоесть я Вас ни в коем случае не критикую ибо не имею практики с OpenMP, но не могу понять как такое может быть впринципе...
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "синхронизация с быстрым мьютексом"		+/–
	Сообщение от svn (??) on 12-Апр-10, 09:35
	> не могу понять как такое может быть >впринципе... Шансы что ты распараллелишь лучше openmp - крайне малы. OpenMP использует пул потоков, который намного эффективнее создания потоков. С ним вероятность сделать ошибку, приводящую к неправильным результатам или падению производительности намного ниже.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема