Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Многопроцессорность
Форум разработчиков электроники ELECTRONIX.ru > Цифровая обработка сигналов - ЦОС (DSP) > Алгоритмы ЦОС (DSP)
procopus
Кто-нибудь подскажет? Какой будет эффект при использовании двух процессоров (например AMD 1.6 МГц) по сравнению с одним процессором (например самого быстрого из доступных сейчас) под WinXP при выполнении приложений типа Matlab'а?
И вообще, какой должна быть программа, чтобы использования многопроцессорности дало ощутимый выигрыш без использования специальных средств ручного распределения задач?
Harbour
Не знаю как сделан matlab, но программа, которая реально покажет прирост на MP (70-100%) должна использовать нити. Если нет - то есть слабый выигрыш за счет того что kernel threads могут счедулится на одном проце, а прога на другом. Ну и если ос умеет - то еще распределяются прерывания между процами. Про "ручное распределения задач" непонятно. - имеется ввиду cpu affinity ?
olefil
Во-первых если речь идет про Opteron, так на нем только RedHat работает. На сколько я знаю винды пока не сделали под него. А сравнивать производительность WinXP и RedHat давольно сложно, хотя такие попытки делаются. Мне кажется, чтобы программа могла реально работать на 2-х процах или более она должна быть специально откомпилирована для этого, а иначе я думаю, что прирост если и будет, то такой мизирный, что о нем и говорить не стоит.
Harbour
Хотя товарищ про Opteron ничего не говорил, стоит отметить, что данный CPU в 32-битном режиме такой же как и остальные его собратья.
procopus
Да, нити можно предусмотреть. Просто есть опасение, что будет потеря на обмене данными между ними (т.е.синхронизация данных в кэшах), который пока трудно прогнозировать.
olefil
Похоже даже тормознее...
olefil
Прирост производительности если и будет, то процентов 3-8 не более - это правило практически для всех систем справедливо, хотя конечно бывает и больше и подругому. Я помню когда делали прогу на 2-х процессорный вариант, так получили не прирост, а убыль скорости как раз при синхронизации потоков.
v_mirgorodsky
Если задача по своей натуре однопоточная, то ее никак не разогнать на два процессора - нечего делить между процессорами, окромя системных нитей, прерываний и прочей ерунды. Однако в современных системах housekeeping очень оптимизирован, и получить существенный выигрыш (даже 2-3%) за счет введения двух- (много-) процессорнисти не поможет. Проверено с Dual-Xeon P4 2.4GHz.

Синхронизация данных в кешах процессоров - это даже не проблема. Если я не ошибаюсь, то кеш-контроллер P4 поддерживает то ли кеш-спуффинг, то ли кеш-снарфинг, короче - когерентность кешей поддерживается вне зависимости от распределения памяти и не приводит к лишним тактам ожидания - если верить тех. документации Intel smile.gif Не знаю как обстоят дела у AMD в этом вопросе.

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

Из практики. Писал многопоточный драйвер под USB. Получил реальный прирост производительности на двух-процессорной системе. Ручным расставлением affinity mask не занимался - 2k и XP с этим справляются и так хорошо.
olefil
А под Linux на проца писали?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.