Есть код :
-module(tut18).
-export([start/0,sum/3,ping/2,pong/3]).

sum(X,X,S) -> S+1/X;
sum(X,Y,S) ->S+1/Y+sum(X,Y-1,S).

pong(Ping_ID,X,Y)->
S=sum(X,Y,0),
Ping_ID ! {pong,S},
self() ! finished,
receive
finished ->
io:format("Понг завершил работу ~p ~n", [S])
end.

ping(0, S) ->
io:format("Сумма равна ~p ", [S]),
{TotalRunTime,TimeSinceLastCall} = statistics(runtime),
io:format("Time: ~w~n", [TimeSinceLastCall]);

ping(N,X) ->
receive
{pong, S} ->
io:format("сумма ~p ~n", [X+S]),
ping(N — 1, X+S)
end.
start() ->
statistics(runtime),
Ping_ID= spawn(tut18, ping, [2,0]),
Pong_ID1 = spawn(tut18, pong, [Ping_ID,1,5000000]),
Pong_ID2 = spawn(tut18, pong, [Ping_ID,5000000,10000000]).

Запускаю без -smp(werl -smp disable ) и с smp (werl -smp enable +S 2).
Получаю следующие результаты
с +S 2 время 6531,7219,7172
с -smp disable время 4660,4782,4578.
В чем причина что при включеном -smp происходит замедление?
Система Windows 2003, проц пентиум 4 3.2 ГГц.

Здравствуйте, Аноним, Вы писали:

А>Запускаю без -smp(werl -smp disable ) и с smp (werl -smp enable +S 2).
А>Получаю следующие результаты
А>с +S 2 время 6531,7219,7172
А>с -smp disable время 4660,4782,4578.
А>В чем причина что при включеном -smp происходит замедление?
А>Система Windows 2003, проц пентиум 4 3.2 ГГц.

Хз. Скорее всего — в оверхэде на синхронизационных блокировках, который не компенсируется ускорением на дохлом гипертрединге P4. Надо на настоящем двухядерном проце пробовать.

Здравствуйте, Аноним, Вы писали:

А>В чем причина что при включеном -smp происходит замедление?
А>Система Windows 2003, проц пентиум 4 3.2 ГГц.
Забудь. Hyper-Threading — это сам по себе тормоз в большинстве случаев.

Erlang часто при включеном SMP тормозит и на нормальных двухядерниках. Например, у меня ejabberd работает медленнее с SMP на Quad Core, чем в конфигурациями с четырьмя связаными не-SMP нодами.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Запускаю без -smp(werl -smp disable ) и с smp (werl -smp enable +S 2).
А>>Получаю следующие результаты
А>>с +S 2 время 6531,7219,7172
А>>с -smp disable время 4660,4782,4578.
А>>В чем причина что при включеном -smp происходит замедление?
А>>Система Windows 2003, проц пентиум 4 3.2 ГГц.

G>Хз. Скорее всего — в оверхэде на синхронизационных блокировках, который не компенсируется ускорением на дохлом гипертрединге P4. Надо на настоящем двухядерном проце пробовать.


Попробовал сделать на четырех ядернике (два двух-ядерных процесора с хипертренингом), таже петрушка.
Хотя замедление меньше но оно есть !!!
Когда я убрал разбиение на потоки в модуле (то есть сделал модуль последовательным) разницы есть или нет smp практически исчезла.
Причем тот же результат вычислился быстреее чем когда я вычислял
с разбиением.
По существу я попробовал сумирование ряда разбить на два потока.
При этом произошло,только замедление вычислений.
Без разбиения на потоки получилось быстрее.
При этом smp только замедлил работу почему это так???

Другой модуль:
-module(testSMP1).
-export([main/2,fib/3,fib/1,wait_n/1]).

fib(2,X,Y) ->X+Y;
fib(N,X,Y) -> fib(N-1,X+Y,X).

%fib(0) -> 1;
%fib(1) -> 1;
%fib(N) -> fib(N-1) + fib(N-2).

fib(0) -> 1;
fib(1) -> 1;
fib(N) -> fib(N,1,1).
wait_n(0) -> done;
wait_n(N) -> receive _ -> wait_n(N-1) end.

main(N,F) ->
S = self(),
[spawn(fun () -> fib(F), S ! i_am_ready end) || _ <- lists:seq(1, N)],
wait_n(N).
Аналогичная ситуауция.
timer:tc(testSMP1, main, [1000000, 30]).
причем идет заметный рост когда я увелиичиваю число smp.
на 1,426637886 при добавлении новых, за счет чего это происходит?

Что интересно примеры очень простые что же тогда в сложных.
Возможно я что то не так делаю, например не правильно мерю время ...???

Если кто то может повторить тесты и потвердить или оправергнуть
замедление,просьба сделать это.

Здравствуйте, Аноним, Вы писали:
А>Попробовал сделать на четырех ядернике (два двух-ядерных процесора с хипертренингом), таже петрушка.
А>Хотя замедление меньше но оно есть !!!

Попробуйте отключить гипертрединг в биосе.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:
А>>Попробовал сделать на четырех ядернике (два двух-ядерных процесора с гипертренингом), таже петрушка.
А>>Хотя замедление меньше но оно есть !!!

G>Попробуйте отключить гипертрединг в биосе.
Врят ли это получится это сервер, и я на нем постояно работают хотя загружен он не сильно.
А что гипертрединг может мешать настолько, что разные процессоры мешают друг другу?
Я думаю что если даную задачу разбить на ноды то такой проблеммы не будет... или как ?
Все же в данных примерах нет ничего сложного.
Результаты замеров tut18 на на системе с двумя двух-ядерными процесора с гипертренингом(под Windows 2003).
среднее
smp disable 4846 4656 4735 4906 4785,75
smp 2 5797 5562 6172 5652 5795,75
smp 4 5594 5781 6375 5438 5797
замедление от smp 1,211043201 то есть 20%.
Попробуйте сделать вы может у вас результат будет лучше.

Здравствуйте, Аноним, Вы писали:

А>Врят ли это получится это сервер, и я на нем постояно работают хотя загружен он не сильно.
А>А что гипертрединг может мешать настолько, что разные процессоры мешают друг другу?
Гипертрединг тормозит на каждом процессоре.

Но и без него тоже тормозит всё: 3080 на SMP против 2330 без SMP.

А>Я думаю что если даную задачу разбить на ноды то такой проблеммы не будет... или как ?
А>Все же в данных примерах нет ничего сложного.
Тут у нас проблема в том, что оверхеды на блокировки слишком большие. Проще использовать явные отдельные однопоточные ноды.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>Врят ли это получится это сервер, и я на нем постояно работают хотя загружен он не сильно.
А>>А что гипертрединг может мешать настолько, что разные процессоры мешают друг другу?
C>Гипертрединг тормозит на каждом процессоре.

C>Но и без него тоже тормозит всё: 3080 на SMP против 2330 без SMP.
3080 на SMP против 2330 без SMP это результат вашего замера ?

А>>Я думаю что если даную задачу разбить на ноды то такой проблеммы не будет... или как ?
А>>Все же в данных примерах нет ничего сложного.
C>Тут у нас проблема в том, что оверхеды на блокировки слишком большие. Проще использовать явные отдельные однопоточные ноды.
Что такое оверхеды на блокировки? Как возникают оверхеды на блокировки?
Как их избежать?
То что проще явные отдельные однопоточные ноды это понятно,
но кто сказал что мы ищим легкие пути ?

С уважение Аноним.

Здравствуйте, Аноним, Вы писали:

А>То что проще явные отдельные однопоточные ноды это понятно,
А>но кто сказал что мы ищим легкие пути ?

Дело ёжиков бессмертно

Здравствуйте, Аноним, Вы писали:

А>Другой модуль:
А>-module(testSMP1).
А>-export([main/2,fib/3,fib/1,wait_n/1]).

А>fib(2,X,Y) ->X+Y;
А>fib(N,X,Y) -> fib(N-1,X+Y,X).

А>%fib(0) -> 1;
А>%fib(1) -> 1;
А>%fib(N) -> fib(N-1) + fib(N-2).

А>fib(0) -> 1;
А>fib(1) -> 1;
А>fib(N) -> fib(N,1,1).
А>wait_n(0) -> done;
А>wait_n(N) -> receive _ -> wait_n(N-1) end.

А>main(N,F) ->
А> S = self(),
А> [spawn(fun () -> fib(F), S ! i_am_ready end) || _ <- lists:seq(1, N)],
А> wait_n(N).
А>Аналогичная ситуауция.
А>timer:tc(testSMP1, main, [1000000, 30]).
А>причем идет заметный рост когда я увелиичиваю число smp.
А>на 1,426637886 при добавлении новых, за счет чего это происходит?

В данном тесте вы создаете очень много (миллион) короткоживущих процессов (fib 30). Таким образом, вы должны довольно много времени тратить в spawn. Я подозреваю, что создание нового процесса блокирует многопоточный шедулер, и из-за этого мы получаем замедление.

Чтобы подтвердить это или опровергнуть, попробуйте сделать наоборот — задайте небольшое количество процессов, но долгоживущих.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Другой модуль:
А>>-module(testSMP1).
А>>-export([main/2,fib/3,fib/1,wait_n/1]).

А>>fib(2,X,Y) ->X+Y;
А>>fib(N,X,Y) -> fib(N-1,X+Y,X).

А>>%fib(0) -> 1;


А>>%fib(1) -> 1;
А>>%fib(N) -> fib(N-1) + fib(N-2).

А>>fib(0) -> 1;
А>>fib(1) -> 1;
А>>fib(N) -> fib(N,1,1).
А>>wait_n(0) -> done;
А>>wait_n(N) -> receive _ -> wait_n(N-1) end.

А>>main(N,F) ->
А>> S = self(),
А>> [spawn(fun () -> fib(F), S ! i_am_ready end) || _ <- lists:seq(1, N)],
А>> wait_n(N).
А>>Аналогичная ситуауция.
А>>timer:tc(testSMP1, main, [1000000, 30]).
А>>причем идет заметный рост когда я увелиичиваю число smp.
А>>на 1,426637886 при добавлении новых, за счет чего это происходит?

G>В данном тесте вы создаете очень много (миллион) короткоживущих процессов (fib 30). Таким образом, вы должны довольно много времени тратить в spawn. Я подозреваю, что создание нового процесса блокирует многопоточный шедулер, и из-за этого мы получаем замедление.

G>Чтобы подтвердить это или опровергнуть, попробуйте сделать наоборот — задайте небольшое количество процессов, но долгоживущих.

А в чем проблема с module(tut18).
Создается всего три процесса, считают два а замедление происходит почему ???

Здравствуйте, Аноним, Вы писали:

А>А в чем проблема с module(tut18).
А>Создается всего три процесса, считают два а замедление происходит почему ???

Ты ведь его с гипертредингом тестировал . Попробуй прогнать этот пример с выключенным гипертредингом на настоящей двухядерной машине.

Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Аноним, Вы писали:
А>>А в чем проблема с module(tut18).
А>>Создается всего три процесса, считают два а замедление происходит почему ???
G>Ты ведь его с гипертредингом тестировал . Попробуй прогнать этот пример с выключенным гипертредингом на настоящей двухядерной машине.
Я уже пилал что тестировал на настоящей двухядерной машине и результаты были близкими,хотя замедление было меньше.
Результаты тестирования на двухядерной машине:
+S 2 -smp disable
5312 4422
5321 4484
4922 5000
5750 4734
---------------------
сред= сред=
5326,25 4660
Замедление 1,142972103 то есть 15%.
Это конечно меньше чем 1,49 то есть 50% как в первоначальном случае, но все же.
Такое ощущение что он распределяет задачу попотокам как захочет и совсем не смотрит что
в есть два реальных потока в самой задаче?
Возможно если бы в задаче было ровно два потока он бы догадался, но я не уверен.
(если кто то знает потвердите или опровергните эту причину)
Все происходит в моем понимании на ровном месте, задача очень простая (есть два основных потока в которых идут вычисления и один который ждет результатов,в чем сложность разбросать между ними процессоры ?).
Таким образом об SMP стоит пока забыть и запускать на разных нодах,
либо все же выяснить в чем причина замедления в tut18.
Возможно стоит как то переписать пример или как то по другому настроить систему ...???

Возник другой глюк ???
Если запустить пример:
-module(testSMP2).
-export([main/2,sum/3,wait_n/2]).
sum(X,X,S) ->S+1/X;
sum(X,Y,S) ->S+1/Y+sum(X,Y-1,S).
wait_n(0,S) -> {TotalRunTime,TimeSinceLastCall} = statistics(runtime),
io:format("Сумма равна ~p~n ", [S]),
io:format("Time: ~w~n", [TimeSinceLastCall]),
done;
% io:format("Сумма равна ~p~n ", [S]),
wait_n(N,S) -> receive {i_am_ready,S1} ->wait_n(N-1,S+S1) end.
main(N,F) ->
statistics(runtime),
S = self(),
[spawn(fun () ->S ! {i_am_ready,sum(1+F*(Z-1),F*Z,0)} end)|| Z <- lists:seq(1, N)],
wait_n(N,0).

на длительное время (более 10 секунд) то он сперва считает а потом перестает ... хотя и не завершает ...то есть он продалжает
на пример
testSMP2:main(2, 5000000) считает нормально 7 секунд .

testSMP2:main(2, 50000000) уже пишет abnormal terminations почему не понятно ???

Здравствуйте, Аноним, Вы писали:

А>>>А в чем проблема с module(tut18).
А>>>Создается всего три процесса, считают два а замедление происходит почему ???
G>>Ты ведь его с гипертредингом тестировал . Попробуй прогнать этот пример с выключенным гипертредингом на настоящей двухядерной машине.
А>Я уже пилал что тестировал на настоящей двухядерной машине и результаты были близкими,хотя замедление было меньше.
А>Результаты тестирования на двухядерной машине:
А>+S 2 -smp disable
Ты гипертрединг в биосе точно отключил? Ты писал, что эта машина у тебя тоже с гипертредингом.

А вообще — я посмотрел, у них там реально тормозить начинает в SMP режиме. Медленнее работает message passing, в четверо медленнее создание процесса, и вообще. Они говорят, что внутри шедулера много блокировок, и они типа оптимизируют его из релиза в релиз. Последний, 12-й релиз должен быть лучше.

Проверить, как оно работает, я к сожалению не могу — пока не поставил Эрланг. Попробую на неделе. Если реально в вычислительных задачах будет замедление — надо им выписать баг. То, что так тормозит на ровном месте SMP — свинство с их стороны.

Здравствуйте, Аноним, Вы писали:

C>>Но и без него тоже тормозит всё: 3080 на SMP против 2330 без SMP.
А>3080 на SMP против 2330 без SMP это результат вашего замера ?
Наоборот. 2330 без SMP и 3080 с SMP.

C>>Тут у нас проблема в том, что оверхеды на блокировки слишком большие. Проще использовать явные отдельные однопоточные ноды.
А>Что такое оверхеды на блокировки? Как возникают оверхеды на блокировки?
В случае без SMP у нас весь интерпретатор работает в одном потоке. Так что не нужно брать блокировки при доступе к разделяемым структурам (очередям сообщений, планировщику, и т.п.) — конфликт с другими потоками невозможен по причине их отсутствия.

А>Как их избежать?
Переписать интерпретатор.

Здравствуйте, Gaperton, Вы писали:

G>Ты гипертрединг в биосе точно отключил? Ты писал, что эта машина у тебя тоже с гипертредингом.
На честном SMP оно тоже тормозит, я проверил (Erlang 11.b.5).

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Gaperton, Вы писали:

G>>Ты гипертрединг в биосе точно отключил? Ты писал, что эта машина у тебя тоже с гипертредингом.
C>На честном SMP оно тоже тормозит, я проверил (Erlang 11.b.5).

На R12 надо проверять. Я находил информацию, что там профиксили тормоза с блокировками.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

C>>>Но и без него тоже тормозит всё: 3080 на SMP против 2330 без SMP.
А>>3080 на SMP против 2330 без SMP это результат вашего замера ?
C>Наоборот. 2330 без SMP и 3080 с SMP.

Забавный диалог:
А: X и Y
C: Напротив, Y и X

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, Gaperton, Вы писали:

G>>>Ты гипертрединг в биосе точно отключил? Ты писал, что эта машина у тебя тоже с гипертредингом.
C>>На честном SMP оно тоже тормозит, я проверил (Erlang 11.b.5).

G>На R12 надо проверять. Я находил информацию, что там профиксили тормоза с блокировками.
Я тестировал на релизе 5.6.2.
Честно говоря мне без разницы что там происходит почему ...
Меня в первую очередь волнавал вопрос, может я че не так мерю... ???
Если у других тоже и других альтернатив нет то значит будем запускать
на разных нодах и временно забудем об SMP.
А потом суп с котом.
Всем большое спасибо за ответы.

Здравствуйте, Gaperton, Вы писали:

C>>На честном SMP оно тоже тормозит, я проверил (Erlang 11.b.5).
G>На R12 надо проверять. Я находил информацию, что там профиксили тормоза с блокировками.
Проверил. Не пофиксили.