vs C

[ufm]

Интересно, это я «не умею их готовить», или с pthread действительно так всё плохо?
Приблизительно 2.5М
Впрочем — было так:

0000000 83 86 77 15 93 35 86 92 49 21 62 27 90 59 63 26 40 26 72 36 = 1138
2578416 45 68 50 62 67 61 57 54 51 64 47 53 61 67 63 67 54 39 66 42 = 1138
5917909 14 80 68 49 56 55 69 44 68 32 77 42 74 63 74 49 54 20 63 87 = 1138
4503224 40 69 58 55 55 56 53 52 54 54 49 53 48 59 49 62 74 73 72 53 = 1138
2627799 79 71 60 53 56 102 45 21 67 32 41 46 56 38 49 73 55 61 78 55 = 1138
2611552 49 48 49 57 51 72 46 53 56 38 52 47 63 79 69 68 49 70 71 51 = 1138

Так что я допускаю, что я действительно не умею готовить.
код — http://pastebin.com/WHfi7hvQ
компилировал так: gcc -O3 -pthread c2.c -o c2
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)

Originally published at U.F.M's Homepage. You can comment here or there.

Comments

[http://users.livejournal.com/_slw/]

кстати, довольно забавные результаты получаются если давать go только одно ядро использовать

[ufm.livejournal.com]

1000 3284124 3817996 7215540 [97 86 11 347 43 0 146 26 13 58 25 23 2 22 12 1 6 0 9 73]
1000 3767603 3759164 7277785 [50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50]
1000 3177429 3669937 7206049 [0 13 1 57 154 28 84 32 48 5 11 2 27 27 149 191 34 2 51 84]
1000 2471496 4727249 7205005 [44 44 13 3 104 9 1 9 0 0 1 46 32 293 32 46 29 256 14 24]
1000 3455113 4000621 7236346 [50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50]

Если ты про 50 50 50 50 - то это понятно.
Что бы такого небыло - надо добавить runtime.Gosched() в transfer(...) в конец добавить. Но тогда скорость упадёт (у меня до 4M).

[http://users.livejournal.com/_slw/]

нет, я про другое.
(а что такое 50 50 50 50? я вообще в программу не вникал)
возможно дольше надо погонять

1000 2871860 2540920 5043204  [6 1 90 12 127 2 43 2 24 5 89 100 63 59 87 63 117 75 19 16]
1000 5399054      0 5132166  [50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50]
1000 5246015 115855 5178107  [74 70 118 0 187 1 15 34 1 53 7 82 31 34 25 135 11 55 4 63]

я про ноль во второй колонке (хотя я и не знаю что он должен означать, но глаз режет)

[ufm.livejournal.com]

Собственно задача простая.
Есть массив.
Есть три треда.
Первый - берет два значения из массива и методом отнимания от одного и прибавления другому - старается выравнять все значения.
Второй - вносит хаос. Т.е. берет сколько нибудь у одного значения и присваевает другому.
Третий - время от времени показывает текущее состояние этого массива.
0 во втором столбце - это значит за секунду отработало 0 циклов хаоса (из-за этого-же "50 50 50 ..." - оно успело выровнять все значения). Т.е. без ввода/вывода, без работы с каналами (я не помню когда еще в go шедулер треды переключает, но эти две причины - точно) и на одном ядре зелёные треды у GO достаточно фигово переключаются.