[procopus 0]

Кто-нибудь подскажет? Какой будет эффект при использовании двух процессоров (например AMD 1.6 МГц) по сравнению с одним процессором (например самого быстрого из доступных сейчас) под WinXP при выполнении приложений типа Matlab'а?

И вообще, какой должна быть программа, чтобы использования многопроцессорности дало ощутимый выигрыш без использования специальных средств ручного распределения задач?

[Harbour 0]

Не знаю как сделан matlab, но программа, которая реально покажет прирост на MP (70-100%) должна использовать нити. Если нет - то есть слабый выигрыш за счет того что kernel threads могут счедулится на одном проце, а прога на другом. Ну и если ос умеет - то еще распределяются прерывания между процами. Про "ручное распределения задач" непонятно. - имеется ввиду cpu affinity ?

[olefil 0]

Во-первых если речь идет про Opteron, так на нем только RedHat работает. На сколько я знаю винды пока не сделали под него. А сравнивать производительность WinXP и RedHat давольно сложно, хотя такие попытки делаются. Мне кажется, чтобы программа могла реально работать на 2-х процах или более она должна быть специально откомпилирована для этого, а иначе я думаю, что прирост если и будет, то такой мизирный, что о нем и говорить не стоит.

[Harbour 0]

Хотя товарищ про Opteron ничего не говорил, стоит отметить, что данный CPU в 32-битном режиме такой же как и остальные его собратья.

[procopus 0]

Да, нити можно предусмотреть. Просто есть опасение, что будет потеря на обмене данными между ними (т.е.синхронизация данных в кэшах), который пока трудно прогнозировать.

[olefil 0]

Похоже даже тормознее...

[olefil 0]

Прирост производительности если и будет, то процентов 3-8 не более - это правило практически для всех систем справедливо, хотя конечно бывает и больше и подругому. Я помню когда делали прогу на 2-х процессорный вариант, так получили не прирост, а убыль скорости как раз при синхронизации потоков.

[v_mirgorodsky 0]

Если задача по своей натуре однопоточная, то ее никак не разогнать на два процессора - нечего делить между процессорами, окромя системных нитей, прерываний и прочей ерунды. Однако в современных системах housekeeping очень оптимизирован, и получить существенный выигрыш (даже 2-3%) за счет введения двух- (много-) процессорнисти не поможет. Проверено с Dual-Xeon P4 2.4GHz.

 

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

 

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

 

Из практики. Писал многопоточный драйвер под USB. Получил реальный прирост производительности на двух-процессорной системе. Ручным расставлением affinity mask не занимался - 2k и XP с этим справляются и так хорошо.

[olefil 0]

А под Linux на проца писали?