To co? Bawimy się? :D

[mariotti]

Rozumiem. Po prostu pomyślałem, że chcesz jednym skryptem shella sprawdzić więcej parametrów na tej samej maszynie ;)
No cóż, zobaczymy, czy nie wywali się na mojej maszynie (przypominam, 4GB RAM + trochę roboty w tle).
Próbowałem jeszcze raz odpalić na wirtualce, dając 8 wątków do dyspozycji, niesety, VB się wywala... (Prawdopodobnie mam za mało pamięci, aby to sprawnie obsłużyć i jeszcze pracować na kompie).

Kurcze powinno działać, jak nie działa, to najbardziej sugeruje błąd w moim programie :/

Obecnie mam nadmiernie skomplikowany kod odpowiedzialny za wielowątkowość. Nie dość
że jest skomplikowany, to prawdopodobnie jest wolniejszy niż inny, całkiem prosty algorytm.
Wkrótce zaimplementuję ten prostszy - jak po tym przestanie się wywalać, to sprawa się wyjaśni, a
jak nie, to nie wiem... opracuję kolejne testy i buga w końcu znajdziemy.

Pozdrawiam

[krzyszp]

Ja jednak stawiam na problem z Virtual Box'em - przypominam, że na Q6600 pod Ubuntu, oraz u innych kolegów się nie wywala - ten problem występuje tylko pod VB...

[sknd]

zapodałem na próbę na e3-1230 v2 3.3ghz:

threadMemPerft2 10 6 32400000 8 7

niech mieli...

zmielił:

nodes:69352859712417 time:11709

[mariotti]

Ja jednak stawiam na problem z Virtual Box'em - przypominam, że na Q6600 pod Ubuntu, oraz u innych kolegów się nie wywala - ten problem występuje tylko pod VB...

Jeśli się wywala tylko w jednym środowisku, to by dobrze wróżyło - debugowanie może
naprawdę zająć masę czasu i opóźnić start projektu.

Wkrótce wypróbujemy kolejną strategię zarządzania danymi w kliencie, czyli łącznie
sprawdzimy 3 strategie (no, chyba że mi przyjdzie do głowy kolejna). Jeśli program
nie będzie się wywalał, to sprawdzimy go jeszcze na dużej ilości różnych układów.
Jeśli nadal poda dobre wyniki i nie wywali się, to pozostanie optymalizacja. Po
optymalizacji klient będzie gotowy, a właściwie to pozostanie jeszcze przeportowanie
na windowsa.

Potem przyjdzie pora na serwer... Szacuję że serwer będzie musiał podać
100mln zadań i przyjąć tyle samo odpowiedzi. Potem drugie tyle w etapie
weryfikacji - prawdopodobnie jeden klient od razu będzie musiał pobierać
100-1000 zadań żeby nie zajeździć bazy danych na serwerze :) Przypuszczam,
że dla głębokości 14-15 serwer może być wąskim gardłem projektu, dopiero
dla głębokości 16 wąskim gardłem staną się obliczenia na klientach. Istnieje
jeszcze możliwość dostosowania serwera osobno do każdej głębokości...
Możliwości jest sporo :)

Te 100mln to na razie szacunki intuicyjne, za jakiś czas oszacuję
to metodą Monte Carlo. Po szacowaniu MC będziemy wiedzieć bardzo
dokładnie jakie będą wymagania co do serwera i ile obliczeń zajmie
cały projekt.

Małymi kroczkami da się to wydzióbać :)


Pozdrawiam

[mariotti]

zapodałem na próbę na e3-1230 v2 3.3ghz:
threadMemPerft2 10 6 32400000 8 7
niech mieli...

zmielił:
nodes:69352859712417 time:11709

To nowy rekord :) Super, dzięki wielkie.

Uaktualniam tabelkę:

Kod [Zaznacz] Rozwiń


---------------------------------------------------------------------------------------------------------
Procesor          | polecenie                                 | wynik            | czas   | user
---------------------------------------------------------------------------------------------------------
Phenom II         | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
Phenom II         | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
Phenom II         | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
Phenom II         | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
e3-1230 v2 3.3ghz | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd
--------------------------------------------------------------------------------------------------------


Czy mógłbyś sprawdzić jeszcze na tej samej maszynie takie polecenie?
threadMemPerft2 10 6 32400000 8 1

Pozdrawiam

[sknd]

sprawdzę, ale to już nie dziś, bo ja jednak jestem z tych, co to im szum kompa przeszkadza przy spaniu  ;)

[mariotti]

sprawdzę, ale to już nie dziś, bo ja jednak jestem z tych, co to im szum kompa przeszkadza przy spaniu  ;)

Rozumiem, bo mnie też kiedyś przeszkadzał. Przyzwyczaiłem się jak sypiałem na biurku w serwerowni :)

[mariotti]

Są dwa nowe testy.

1) Widać że nowy algorytm raczej działa gorzej (i7)
2) Zwiększanie ostatniego parametru z 10mln do 50mln nie zmieniło czasów (Phenom)

Widocznie to pierwsze podejście do zapamiętywania danych jest lepsze niż mi się wydawało :)
Ale i tak będzie jeszcze podejście trzecie.

Kod [Zaznacz] Rozwiń


---------------------------------------------------------------------------------------------------------
Procesor          | polecenie                                 | wynik            | czas   | user
---------------------------------------------------------------------------------------------------------
Phenom II         | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
Phenom II         | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
Phenom II         | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
Phenom II         | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
i7 950 @3.07GHz   | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
e3-1230 v2 3.3ghz | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd
i7 950 @3.07GHz   | threadMemPerft2 10 5 56250000 8 1         | 69352859712417ok | 13667s |
Phenom II         | threadMemPerft 10 8 250000000 8 50000000  | 69352859712417ok | 17781s |
--------------------------------------------------------------------------------------------------------




Pozdrawiam

[krzyszp]

No to kolejny wynik, zwracam uwagę na zmiany w skrypcie startującym testy (ostatnie 3):

Kod [Zaznacz] Rozwiń

#!/bin/sh
mem=5400000
thr=4
depth=9



(
echo threadMemPerft2 $depth $thr $mem 8 1
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 2
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 3
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 4
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 5
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 6
echo quit
) | ./perft >> out.txt


(
echo threadMemPerft2 $depth $thr $mem 8 7
echo quit
) | ./perft >> out.txt

(
echo threadMemPerft $depth $thr 10800000 4 1
echo quit
) | ./perft >> out.txt

(
echo threadMemPerft $depth $thr 10800000 4 2
echo quit
) | ./perft >> out.txt

(
echo threadMemPerft $depth $thr 10800000 4 3
echo quit
) | ./perft >> out.txt


Wyniki:

Kod [Zaznacz] Rozwiń

nodes:2439530234167 time:6921
nodes:2439530234167 time:5976
nodes:2439530234167 time:5691
nodes:2439530234167 time:5633
nodes:2439530234167 time:5512
nodes:2439530234167 time:5551
nodes:2439530234167 time:5546
nodes:2439530234167 time:5560
nodes:2439530234167 time:4355
nodes:2439530234167 time:2209
nodes:2439530234167 time:2013
nodes:2439530234167 time:2007
nodes:2439530234167 time:1963
nodes:2439530234167 time:1944
nodes:2439530234167 time:3041
nodes:2439530234167 time:2972
nodes:2439530234167 time:2110
nodes:2439530234167 time:2053
nodes:2439530234167 time:2027
nodes:2439530234167 time:2004
nodes:2439530234167 time:1981
nodes:2439530234167 time:1977
nodes:2439530234167 time:1986
nodes:2439530234167 time:5148
nodes:2439530234167 time:5140
nodes:2439530234167 time:5138


[sknd]

Czy mógłbyś sprawdzić jeszcze na tej samej maszynie takie polecenie?
threadMemPerft2 10 6 32400000 8 1

zrobione

threadMemPerft2 10 6 32400000 8 1
nodes:69352859712417 time:13085

jak widac czas gorszy troche

[mariotti]

Czy mógłbyś sprawdzić jeszcze na tej samej maszynie takie polecenie?
threadMemPerft2 10 6 32400000 8 1

zrobione
threadMemPerft2 10 6 32400000 8 1
nodes:69352859712417 time:13085
jak widac czas gorszy troche

Dzięki. Jak na taką skalę obliczeń, to czas wiele gorszy, takie różnice
mogą zadecydować o tym, czy dożyjemy końca czy nie :D

Aktualna tabelka:

Kod [Zaznacz] Rozwiń


-----------------------------------------------------------------------------------------------------------------
Wersja | Procesor               | polecenie                                 | wynik            | czas   | user
-----------------------------------------------------------------------------------------------------------------
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd
   0   | i7 950 @3.07GHz        | threadMemPerft2 10 5 56250000 8 1         | 69352859712417ok | 13667s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 50000000  | 69352859712417ok | 17781s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 1         | 69352859712417ok | 13085s | sknd
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 12 10000000 | 69352859712417ok | 18111s |
   1   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 200       | 69352859712417ok | 25889s |
---------------------------------------------------------------------------------------------------------------


Jest nowa wersja programu. Wersji jest kilka, żeby się nie pogubić, nowa dostała numerek 1. W nowej doszło
nowe polecenie, ale z tego co widzę, raczej będzie to niewypał. Za to stare polecenie zostało zmodyfikowane,
czyli inaczej działa:
threadMemPerft depth max_thread hsize hprobe forget

Wcześniej parametr forget mógł przyjmować duże wartości, od 0 do 2^64-1 i trudno było go dobrać.
Teraz sensowe wartości są (prawdopodobnie) w mniejszym przedziale od 20 do 10000.

Na komputerze e3-1230 v2 3.3ghz warto sprawdzić nową komendę z tak dobranymi parametrami, aby
była taka sama ilość pamięci. Czyli np.:

threadMemPerft 10 259200000 8 200
threadMemPerft 10 259200000 8 150
threadMemPerft 10 259200000 8 100

Pozdrawiam i dzięki.

[mariotti]

No to kolejny wynik, zwracam uwagę na zmiany w skrypcie startującym testy (ostatnie 3):

Dzięki :)

Wiążę wyniki z poleceniami tak jak poniżej widać. Czyli wygrało 8 6.

Kod [Zaznacz] Rozwiń


mem=5400000
thr=4
depth=9
threadMemPerft2 $depth $thr $mem 8 1 nodes:2439530234167 time:2110
threadMemPerft2 $depth $thr $mem 8 2 nodes:2439530234167 time:2053
threadMemPerft2 $depth $thr $mem 8 3 nodes:2439530234167 time:2027
threadMemPerft2 $depth $thr $mem 8 4 nodes:2439530234167 time:2004
threadMemPerft2 $depth $thr $mem 8 5 nodes:2439530234167 time:1981
threadMemPerft2 $depth $thr $mem 8 6 nodes:2439530234167 time:1977
threadMemPerft2 $depth $thr $mem 8 7 nodes:2439530234167 time:1986
threadMemPerft $depth $thr 10800000 4 1 nodes:2439530234167 time:5148
threadMemPerft $depth $thr 10800000 4 2 nodes:2439530234167 time:5140
threadMemPerft $depth $thr 10800000 4 3 nodes:2439530234167 time:5138



W tych testach było w pamięci 5400000 * 8 = 43200000 układów
Czyli odpowiednik takich komend:

Kod [Zaznacz] Rozwiń


threadMemPerft 9 4 43200000  8 20
threadMemPerft 9 4 43200000  8 50
threadMemPerft 9 4 43200000  8 80
threadMemPerft 9 4 43200000  8 120
threadMemPerft 9 4 43200000  8 200
threadMemPerft 9 4 43200000  8 300


Wcześniej najlepsza była piątka, więc dajmy też do testów piątkę.

Cały skrypt:

Kod [Zaznacz] Rozwiń


#!/bin/sh
(
echo threadMemPerft 9 4 43200000  8 20
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 50
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 80
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 120
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 200
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 300
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 20
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 50
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 80
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 120
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 200
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 300
echo quit
) | ./perft1 >> out.txt


Jeszcze raz wielkie dzięki za testy :)

Nie mam nowych pomysłów na ulepszenie zarządzania pamięcią, więc teraz spróbuję coś
ulepszyć w zarządzaniu wątkami :)

Pozdrawiam

[sknd]

Jest nowa wersja programu. Wersji jest kilka, żeby się nie pogubić, nowa dostała numerek 1. W nowej doszło
nowe polecenie, ale z tego co widzę, raczej będzie to niewypał. Za to stare polecenie zostało zmodyfikowane,
czyli inaczej działa:
threadMemPerft depth max_thread hsize hprobe forget

Wcześniej parametr forget mógł przyjmować duże wartości, od 0 do 2^64-1 i trudno było go dobrać.
Teraz sensowe wartości są (prawdopodobnie) w mniejszym przedziale od 20 do 10000.

Na komputerze e3-1230 v2 3.3ghz warto sprawdzić nową komendę z tak dobranymi parametrami, aby
była taka sama ilość pamięci. Czyli np.:

threadMemPerft 10 259200000 8 200
threadMemPerft 10 259200000 8 150
threadMemPerft 10 259200000 8 100

Pozdrawiam i dzięki.

powinno być 5 parametrów, podałeś 4, zdaje się że zapomniałeś o ilości wątków. Mógłbyś mi podać przykładowe wartości tak żeby zajmowało to powiedzmy 6 giga ramu (mam 8 ) ?

aha, i w tabelce jest mały błąd - obliczenia robiłem na tym samym procku - e3-1230 v2  ;)

postaram się wieczorem zapuścić jeden a może i dwa testy zależy o której dotrę do domu...

[mariotti]

Jest nowa wersja programu. Wersji jest kilka, żeby się nie pogubić, nowa dostała numerek 1. W nowej doszło
nowe polecenie, ale z tego co widzę, raczej będzie to niewypał. Za to stare polecenie zostało zmodyfikowane,
czyli inaczej działa:
threadMemPerft depth max_thread hsize hprobe forget

Wcześniej parametr forget mógł przyjmować duże wartości, od 0 do 2^64-1 i trudno było go dobrać.
Teraz sensowe wartości są (prawdopodobnie) w mniejszym przedziale od 20 do 10000.

Na komputerze e3-1230 v2 3.3ghz warto sprawdzić nową komendę z tak dobranymi parametrami, aby
była taka sama ilość pamięci. Czyli np.:

threadMemPerft 10 259200000 8 200
threadMemPerft 10 259200000 8 150
threadMemPerft 10 259200000 8 100

Pozdrawiam i dzięki.

powinno być 5 parametrów, podałeś 4, zdaje się że zapomniałeś o ilości wątków. Mógłbyś mi podać przykładowe wartości tak żeby zajmowało to powiedzmy 6 giga ramu (mam 8 ) ?

aha, i w tabelce jest mały błąd - obliczenia robiłem na tym samym procku - e3-1230 v2  ;)
postaram się wieczorem zapuścić jeden a może i dwa testy zależy o której dotrę do domu...

Wszystko pomyliłem :)

1) Tabelka już poprawiona.
2) W poleceniach faktycznie zabrakło ilości wątków.

Chciałem porównać z sobą skuteczność różnych algorytmów w podobnych warunkach. Czyli
pozostawiamy taką samą ilość wątków, taką samą ilość układów w ram, no i ten sam procesor :)

Poprzedni algorytm (threadMemPerft2 w wersji 0) miał w RAM 32400000 * 8 = 259200000 układów.
Chciałbym zobaczyć jak on wypada w porównaniu z algorytmem threadMemPerft w wersji 1.
Więc takie przykładowe polecenia.
threadMemPerft 10 6 259200000 8 200
threadMemPerft 10 6 259200000 8 150
threadMemPerft 10 6 259200000 8 100


Wersja perft1 jest pod linkiem:
http://www.boincatpoland.org/smf/przetwarzanie-rozproszone/to-co-bawimy-sie-d/?action=dlattach;attach=1310

Pozdrawiam

[krzyszp]

Dla:
threadMemPerft 10 5 50000000 8 1000000

Wynik :
nodes:69352859712417 time:42144

Na Q6600

Zabieram się za dalsze testowanie. Zastanawia mnie jednak, czy skaczące obciążenie tej maszyny mocno wpływa na wyniki?

[mariotti]

Dla:
threadMemPerft 10 5 50000000 8 1000000
Wynik :
nodes:69352859712417 time:42144
Na Q6600

Super dzięki. To chyba bardzo ładny wynik jak na tak małą ilość pamięci i procesor Q6600.
Uaktualniam tabelkę. Rozumiem że testowałeś wersję perft, bo jest już wersja perft1 :)

Kod [Zaznacz] Rozwiń


------------------------------------------------------------------------------------------------------------------
Wersja | Procesor               | polecenie                                 | wynik            | czas   | user
------------------------------------------------------------------------------------------------------------------
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd
   0   | i7 950 @3.07GHz        | threadMemPerft2 10 5 56250000 8 1         | 69352859712417ok | 13667s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 50000000  | 69352859712417ok | 17781s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 1         | 69352859712417ok | 13085s | sknd
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 12 10000000 | 69352859712417ok | 18111s |
   1   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 200       | 69352859712417ok | 25889s |
   0   | Q6600                  | threadMemPerft 10 5 50000000 8 1000000    | 69352859712417ok | 42144  | krzyszp
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 200       | 69352859712417ok | 16967  |
------------------------------------------------------------------------------------------------------------------


Zabieram się za dalsze testowanie. Zastanawia mnie jednak, czy skaczące obciążenie tej maszyny mocno wpływa na wyniki?

Trudno powiedzieć, za jakiś czas i to sprawdzimy. Na razie robimy pobieżne testy, wszystkie wyniki analizuję i
ocenię które algorytmy i które zakresy parametrów warto sprawdzić dokładnie.

W dokładnych testach sprawdzimy jaka w ogóle jest powtarzalność wyników na nieobciążonym komputerze. Gdy program
pracuje wielowątkowo, to nawet na nieobciążonym komputerze może podać różne czasy. Czasami ułamki sekund decydują o
tym, że wątek ma gotowe dane i nie musi danego układu przeliczać. Jeśli system uruchomi drugi wątek "za wcześnie" o te ułamki
sekund, to drugi wątek liczy to samo co pierwszy, zamiast odczytać wynik z tablicy. Jeśli uruchomi za późno, to dane które
zapisał pierwszy wątek mogą zostać zamazane. Za jakiś czas i nad tym popracuję, może uda się jeszcze coś przyspieszyć.

Teraz ciekawi mnie algorytm threadMemPerft w wersji nr 1. Na razie mam bardzo niejednoznaczne wyniki. Na małych
głębokościach działa szybciej ten z wersji nr 1, a na dużych chyba działał szybciej ten stary algorytm. Może będę musiał
go przywrócić.

Za jakiś czas postaram się przygotować testy w bardziej profesjonalny sposób. Na razie jest dobrze, jeśli program na wielu
różnych komputerach nie wywala się i podaje dobry wynik. :)

[krzyszp]

Tak, ten test był jeszcze na starej wersji.
Wyniki testu "ze skryptu", który testuje perft1 wg podanych wcześniej przez Ciebie danych do go.sh będą jutro...

[mariotti]

Tak, ten test był jeszcze na starej wersji.
Wyniki testu "ze skryptu", który testuje perft1 wg podanych wcześniej przez Ciebie danych do go.sh będą jutro...

Super fajnie.
--------------------------------------------------------------------------------

Myślę powoli nad dokładnym oszacowaniem czasu jaki będziemy
potrzebowali na głębokości 13, 14, 15 i 16. Robimy zakłady? :)

Moje rokowania:
Obecna wersja programu na komputerze Q6600
depth 13 -> 6lat
depth 14 -> 85 lat
depth 15 -> 1284 lat
depth 16 -> 19263 lat

Trza by go z 50 razy przyspieszyć :D

[Dario666]

Czyli na "dzisiejszych" procesorach będzie 3-4 razy szybciej.

[mariotti]

Czyli na "dzisiejszych" procesorach będzie 3-4 razy szybciej.

Sprawdziłem ile jest unikalnych układów na głębokości 6 ruchów. No i jest
ich 9417683, czyli 12 razy mniej niż wszystkich 119060324.

Na serwerze wystarczy zapamiętać te unikalne. Następnie trzeba 9417683 razy
policzyć na głębokość 9 ruchów i mamy łączną głębokość 15 ruchów.  Na Q6600
schodził na głębokość 9 ruchów np. w 1986 sekund. Czyli tamta
wersja potrzebuje około 9417683 * 1986 / 24 / 3600 / 365 = 600 lat. Ale...

Komputery są szybsze i mają więcej pamięci, więc 600 / 4 = 150.
Mam nadzieję że zoptymalizuję zarządzanie pamięcią, więc 150 / 4 = 37.
Przyspieszenie liniowe nie wiem ile da... może z 10 razy, czyli 37/10 = 4 lata
Klient będzie pobierał do obliczeń 10-100 podobnych układów na raz, a w
podobnych jeszcze lepiej zadziała pamięć, czyli optymistyczna (ale nie szalona!) wersja to
około 2-3 lat :D

Pozdrawiam

[krzyszp]

Wyniki dla:

Kod [Zaznacz] Rozwiń

#!/bin/sh
(
echo threadMemPerft 9 4 43200000  8 20
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 50
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 80
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 120
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 200
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  8 300
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 20
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 50
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 80
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 120
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 200
echo quit
) | ./perft1 >> out.txt
(
echo threadMemPerft 9 4 43200000  5 300
echo quit
) | ./perft1 >> out.txt


Są następujące:

Kod [Zaznacz] Rozwiń

nodes:2439530234167 time:2636
nodes:2439530234167 time:2631
nodes:2439530234167 time:2635
nodes:2439530234167 time:2639
nodes:2439530234167 time:3920
nodes:2439530234167 time:2660
nodes:2439530234167 time:2617
nodes:2439530234167 time:2617
nodes:2439530234167 time:2616
nodes:2439530234167 time:2607
nodes:2439530234167 time:3921
nodes:2439530234167 time:2686


[sknd]

Poprzedni algorytm (threadMemPerft2 w wersji 0) miał w RAM 32400000 * 8 = 259200000 układów.
Chciałbym zobaczyć jak on wypada w porównaniu z algorytmem threadMemPerft w wersji 1.
Więc takie przykładowe polecenia.
threadMemPerft 10 6 259200000 8 200
threadMemPerft 10 6 259200000 8 150
threadMemPerft 10 6 259200000 8 100

Wersja perft1 jest pod linkiem:
http://www.boincatpoland.org/smf/przetwarzanie-rozproszone/to-co-bawimy-sie-d/?action=dlattach;attach=1310

zrobiłem
threadMemPerft 10 6 259200000 8 200
nodes:69352859712417 time:16895

tylko że kurcze mać zapomniałem ściągnąć perft1, robiłem to ostatnią wersją perfta, dopiero teraz patrząc na twojego posta to sobie uświadomiłem  :facepalm2: mam nadzieję że mimo wszystko do czegoś się to przyda może

[Dario666]

Jak się podepnie cała drużyna to w tydzien zabraknie WU. Może liczyć od razu na głąbokość 16.  ;D

[mariotti]

Wyniki dla:
Są następujące:

Kod [Zaznacz] Rozwiń


threadMemPerft2 9 4 5400000 8 1 nodes:2439530234167 time:2110
threadMemPerft2 9 4 5400000 8 2 nodes:2439530234167 time:2053
threadMemPerft2 9 4 5400000 8 3 nodes:2439530234167 time:2027
threadMemPerft2 9 4 5400000 8 4 nodes:2439530234167 time:2004
threadMemPerft2 9 4 5400000 8 5 nodes:2439530234167 time:1981
threadMemPerft2 9 4 5400000 8 6 nodes:2439530234167 time:1977
threadMemPerft2 9 4 5400000 8 7 nodes:2439530234167 time:1986
threadMemPerft 9 4 10800000 4 1 nodes:2439530234167 time:5148
threadMemPerft 9 4 10800000 4 2 nodes:2439530234167 time:5140
threadMemPerft 9 4 10800000 4 3 nodes:2439530234167 time:5138

threadMemPerft 9 4 43200000  8  20 nodes:2439530234167 time:2636
threadMemPerft 9 4 43200000  8  50 nodes:2439530234167 time:2631
threadMemPerft 9 4 43200000  8  80 nodes:2439530234167 time:2635
threadMemPerft 9 4 43200000  8 120 nodes:2439530234167 time:2639
threadMemPerft 9 4 43200000  8 200 nodes:2439530234167 time:3920
threadMemPerft 9 4 43200000  8 300 nodes:2439530234167 time:2660
threadMemPerft 9 4 43200000  5  20 nodes:2439530234167 time:2617
threadMemPerft 9 4 43200000  5  50 nodes:2439530234167 time:2617
threadMemPerft 9 4 43200000  5  80 nodes:2439530234167 time:2616
threadMemPerft 9 4 43200000  5 120 nodes:2439530234167 time:2607
threadMemPerft 9 4 43200000  5 200 nodes:2439530234167 time:3921
threadMemPerft 9 4 43200000  5 300 nodes:2439530234167 time:2686


Dzięki za testy.
Czyli na Q6600 algorytm:
./perft1 threadMemPerft2 9 4 5400000 8 5 nodes:2439530234167 time:1981
działa najlepiej. Myślałem że to kiepska wersja i pójdzie w kosz, ale
będzie trzeba się jej przyjrzeć uważnie :)

Pozdrawiam

[krzyszp]

Dzięki za testy.

Nie ma problemu, dawaj nastépne testy ;)

[mariotti]

zrobiłem
threadMemPerft 10 6 259200000 8 200
nodes:69352859712417 time:16895

Dobrze, przyda się każdy wynik.


Nowa tabelka

Kod [Zaznacz] Rozwiń


------------------------------------------------------------------------------------------------------------------
Wersja | Procesor               | polecenie                                 | wynik            | czas   | user
------------------------------------------------------------------------------------------------------------------
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
   1   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 200       | 69352859712417ok | 25889s |
   2   | Phenom II 1050T 2.4GHz | threadMemPerft5 10 6 250000000 8 1000000  | 69352859712417ok | 24071s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 12 10000000 | 69352859712417ok | 18111s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 50000000  | 69352859712417ok | 17781s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
   0   | Q6600                  | threadMemPerft 10 5 50000000 8 1000000    | 69352859712417ok | 42144s | krzyszp
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 200       | 69352859712417ok | 16967s |
   0   | i7 950 @3.07GHz        | threadMemPerft2 10 5 56250000 8 1         | 69352859712417ok | 13667s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
   2   | i7 950 @3.07GHz        | threadMemPerft5 10 4 450000000 8 10000000 | 69352859712417ok | 12144s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 8 200       | 69352859712417ok | 16895s | sknd
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 1         | 69352859712417ok | 13085s | sknd
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd
------------------------------------------------------------------------------------------------------------------


Więc jest nowa wersja programu: perft2.

Jednak te nowe polecenia albo: na współgrają z procesorem
Phehom, albo jest duża losowość i takie same polecenia będą
się wykonywały w różnym czasie.

Jeśli prawdziwa jest ta pierwsza wersja, to będzie konieczna
inna wersja programu na każdy procesor - w sumie już jest
dużo wersji, wystarczy na danym procesorze wybrać odpowiednie
polecenie.

A jeśli ta druga wersja jest prawdziwa, to w ogóle trudne
będzie ustalenie, który algorytm jest najlepszy.


Na procesorze e3-1230 v2 3.3ghz by pomógł mi test takich poleceń: (oczywiście
już tylko dla wersji perft2)
threadMemPerft5 10 4 259200000 8 10000000
threadMemPerft 10 6 259200000 5 10000000
threadMemPerft4 10 6 259200000 5 64

Na Q6600
threadMemPerft5 10 4 50000000 8 10000000
threadMemPerft2 10 4 6250000 8 6

Pozdrawiam i jeszcze raz dzięki wszystkim za pomoc

[krzyszp]

Wykonuje sié

[patyczak]

Na swoim Q9400 uruchomiłem polecenie:
threadMemPerft2 10 4 6250000 8 6

Przy pierwszym poleceniu (threadMemPerft5 10 4 50000000 8 10000000) otrzymuje komunikat:
using: threadMemPerft5 depth max_thread hsize hprobe forget

Czyżby za mało pamięci?

[mariotti]

Na swoim Q9400 uruchomiłem polecenie:
threadMemPerft2 10 4 6250000 8 6
Przy pierwszym poleceniu (threadMemPerft5 10 4 50000000 8 10000000) otrzymuje komunikat:
using: threadMemPerft5 depth max_thread hsize hprobe forget
Czyżby za mało pamięci?

Powinno działać.

U siebie odpalam, tak jak widać na zrzucie z shella
(zmniejszyłem tylko głębokość z 10 ruchów do 6)

Kod [Zaznacz] Rozwiń


./perft2
threadMemPerft5                                         
using: threadMemPerft5 depth max_thread hsize hprobe forget
threadMemPerft5 6 4 50000000 8 10000000
nodes:119060324 time:3
quit


Prawdopodobnie źle była wpisana/wklejona komenda i wyskoczył taki mini help.
A jeśli była dobrze wpisana, to może jakiś rzadki błąd w się uaktywnił.
Mam prośbę: spróbuj jeszcze kilka razy, bo wszelkie informacje o błędach są
dla mnie najważniejsze :)

Wzór na ilość pamięci w  poleceniu threadMemPerft5 wygląda tak:
50000000 * 24 = 1.200.000.000 bajtów = 1.2 giba bajta.

Pozdrawiam

[patyczak]

Prawdopodobnie źle była wpisana/wklejona komenda i wyskoczył taki mini help.

Rzeczywiście musiałem jakąś literówkę zrobić. Odpaliłem drugi raz i tym razem poszło  :)

[mariotti]

Nowa tabelka

Kod [Zaznacz] Rozwiń


------------------------------------------------------------------------------------------------------------------
Wersja | Procesor               | polecenie                                 | wynik            | czas   | user
------------------------------------------------------------------------------------------------------------------
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 1000000   | 69352859710032!  | 63547s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 1 0         | 69352859712417ok | 41515s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 0         | 69352859712417ok | 30042s |
   1   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 200       | 69352859712417ok | 25889s |
   2[1]| Phenom II 1050T 2.4GHz | threadMemPerft5 10 6 250000000 8 1000000  | 69352859712417ok | 24071s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 12 10000000 | 69352859712417ok | 18111s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 50000000  | 69352859712417ok | 17781s |
   0   | Phenom II 1050T 2.4GHz | threadMemPerft 10 8 250000000 8 10000000  | 69352859712417ok | 17768s |
   2   | Phenom II 1050T 2.4GHz | threadMemPerft5 10 6 250000000 5 1000000  | 69352859712417ok | 15251s |
   2   | Phenom II 1050T 2.4GHz | threadMemPerft5 10 6 250000000 8 1000000  | 69352859712417ok | 15186s |
   0   | Q6600                  | threadMemPerft 10 5 50000000 8 1000000    | 69352859712417ok | 42144s | krzyszp
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 0         | 69352859712417ok | 21051s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 200       | 69352859712417ok | 16967s |
   0   | i7 950 @3.07GHz        | threadMemPerft2 10 5 56250000 8 1         | 69352859712417ok | 13667s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 1000000   | 69352859712417ok | 12173s |
   2   | i7 950 @3.07GHz        | threadMemPerft5 10 4 450000000 8 10000000 | 69352859712417ok | 12144s |
   0   | i7 950 @3.07GHz        | threadMemPerft 10 5 450000000 8 10000000  | 69352859712417ok | 12092s |
   2   | i7 950 @3.07GHz        | threadMemPerft5 10 5 450000000 8 10000000 | 69352859712417ok | 11475s |
   2   | i7 950 @3.07GHz        | threadMemPerft5 10 5 450000000 5 10000000 | 69352859712417ok | 11396s |
   0   | e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 8 200       | 69352859712417ok | 16895s | sknd
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 1         | 69352859712417ok | 13085s | sknd
   2   | e3-1230 v2 3.3ghz      | threadMemPerft5 10 4 259200000 8 10000000 | 69352859712417ok | 12730s | sknd
   0   | e3-1230 v2 3.3ghz      | threadMemPerft2 10 6 32400000 8 7         | 69352859712417ok | 11709s | sknd

------------------------------------------------------------------------------------------------------------------
[1] - z tej wersji prawdopodobnie zapomniałem usunąć asercje i spowolniły program.


[sknd]

Na procesorze e3-1230 v2 3.3ghz by pomógł mi test takich poleceń: (oczywiście
już tylko dla wersji perft2)
threadMemPerft5 10 4 259200000 8 10000000
threadMemPerft 10 6 259200000 5 10000000
threadMemPerft4 10 6 259200000 5 64

threadMemPerft5 10 4 259200000 8 10000000
nodes:69352859712417 time:12730

mam nadzieje że celowo wpisałeś liczbę wątków 4 a nie 6 ;)

[mariotti]

Na procesorze e3-1230 v2 3.3ghz by pomógł mi test takich poleceń: (oczywiście
już tylko dla wersji perft2)
threadMemPerft5 10 4 259200000 8 10000000
threadMemPerft 10 6 259200000 5 10000000
threadMemPerft4 10 6 259200000 5 64

threadMemPerft5 10 4 259200000 8 10000000
nodes:69352859712417 time:12730
mam nadzieje że celowo wpisałeś liczbę wątków 4 a nie 6 ;)

Dziękuję za testy, już dopisuję wynik do tabelki na górze.

Tak, celowo wpisałem. Algorytm threadMemPerft5 ma ulepszone
zarządzanie wątkami  - przynajmniej w teorii. Jeśli się nie mylę,
to najszybciej będzie działał gdy ilość wątków jest równa ilości
fizycznych rdzeni, a na procesorze z hyperthreadingiem... trudno
powiedzieć, zależy ile tak naprawdę daje ten hyperthreding. Być
może na procesorach z hyperthreadingiem opłaci się dodać jeden
wątek więcej.

Pozdrawiam

[AXm77]

Z samej ciekawości, jak twoja aplikacja skaluje na większej ilości wątków, jutro będę miał wolny czas i przeprowadzę testy na serwerze Ubuntu 10.10 z 48 rdzeni @ 2.3GHz (AMD) i 16GB RAM. Jakie byłyby optymalne ustawienia?

Kod [Zaznacz] Rozwiń

threadMemPerft5 10 48 500000000 16 1000000 Czy to jest OK?

[mariotti]

Z samej ciekawości,

Super że się zaciekawiłeś.

jak twoja aplikacja skaluje na większej ilości wątków,

W skrócie to dążę do tego, aby skalowała się liniowo. W szczegółach jest to bardzo
skomplikowane. Każdy algorytm który testowałem skaluje się trochę inaczej. Zadania
często powtarzają się, przy dużej głębokości prawdopodobnie jest tylko 0.1% unikalnych
zadań, pozostałe przynajmniej raz są zduplikowane. Zadania można oznaczyć kolejnymi
literami, weźmy przykładowe siedem zadań: A B C A D B A. Jeśli te zadania uruchomimy
na 7 wątkach, to przy założeniu że każde zadanie jest tak samo pracochłonne, powinny
się wykonać 7 razy szybciej niż na jednym wątku. Ale unikalnych zadań jest tylko 4, więc
aplikacja jednowątkowa może zapamiętać wyniki i potem zamiast obliczeń, może po prostu
odczytać. Czyli w takich warunkach aplikacja 1-wątkowa będzie tylko 4 razy wolniejsza
od 7-wątkowej. Dążę do tego, aby aplikacja jedno zadanie liczyła tylko jeden raz i to w
zasadzie obojętnie czy zostanie uruchomiona w jednym wątku czy w wielu.

Ciekawi mnie na ile w tym problemie można zbliżyć się do liniowej skalowalności. Nie
znam dokładnej odpowiedzi na to pytanie, ale jestem raczej optymistą. Praktycznie
codziennie mam jakiś pomysł na udoskonalenie, nie wszystkie udoskonalenia sprawują się
zgodnie z oczekiwaniami, ale względem pierwszej wersji obecny program działa 4 razy szybciej. To
przyspieszenie wynika tylko i wyłącznie z "ochrony" wątków przed liczeniem kilka razy
tego samego, sam kod jeszcze nie był w żaden sposób optymalizowany.

jutro będę miał wolny czas i przeprowadzę testy na serwerze Ubuntu 10.10 z 48 rdzeni @ 2.3GHz (AMD) i 16GB RAM. Jakie byłyby optymalne ustawienia?

Kod [Zaznacz] Rozwiń

threadMemPerft5 10 48 500000000 16 1000000 Czy to jest OK?

Żeby testy nam coś dały, to trzeba odpalić kilka razy, chociaż 4 razy.

Żeby sprawdzić skalowalność, moja propozycja jest np. taka:
threadMemPerft5 10 1 500000000 8 10000000
threadMemPerft5 10 2 500000000 8 10000000
threadMemPerft5 10 4 500000000 8 10000000
threadMemPerft5 10 8 500000000 8 10000000
threadMemPerft5 10 16 500000000 8 10000000
threadMemPerft5 10 48 500000000 8 10000000
threadMemPerft5 10 52 500000000 8 10000000

Lub tak:
threadMemPerft5 10 1 500000000 5 10000000
threadMemPerft5 10 2 500000000 5 10000000
threadMemPerft5 10 4 500000000 5 10000000
threadMemPerft5 10 8 500000000 5 10000000
threadMemPerft5 10 16 500000000 5 10000000
threadMemPerft5 10 48 500000000 5 10000000
threadMemPerft5 10 52 500000000 5 10000000

Wiem że to zajmie masę czasu, ale żeby zrobić sensowne porównanie, to musimy
mieć materiał do tego porównywania. Można zamiast głębokości 10 dać
głębokość 9 - to nie to samo co 10, ale znacznie przyspieszy. Jeśli nie masz
tyle czasu, to może odpal dwa razy:
threadMemPerft5 10 1 500000000 5 10000000
threadMemPerft5 10 52 500000000 5 10000000
Dzięki temu też się czegoś ważnego dowiemy.


Pracuję nad wersją 6 i 7 tego algorytmu. Ulepszenia będą szły cały czas w
kierunku ochrony przed wielokrotnym liczeniem tego samego - to także
oznacza że aplikacja powinna się lepiej skalować. Jakbyś mógł przetestować
potem tak samo wersję 6 i 7, to byśmy wiedzieli czy skalowanie ( i nie tylko
skalowanie ) jakoś istotnie się poprawiło.

Aplikacja cały czas ma heurystykę do synchronizacji wątków, heurystykę, czyli
coś co zwykle działa, ale nie daje 100% gwarancji że zawsze będzie poprawny
wynik. Test na takim sprzęcie (dużo rdzeni i wątków) powie nam coś nowego na
temat "siły" tej heurystyki - i nie tylko, da nam też ogólny pogląd na stabilność :)

Jeszcze raz dzięki i pozdrawiam.

[AXm77]

Przygotowałem skrypt (apropos: ostatnia wartość ma być milion czy dziesięć milionów?) i przetestowałem z głębokością 7: 52 -12s a 48 - 13s.
Jutro startuję z głębokością 10 na 52, 48, 24, 16, 8, 4, 2, 1 (dokładnie w takiej koleności,zaczynam od 52), przewiduję obciążenie na jakieś dwie doby. 

[mariotti]

Przygotowałem skrypt (apropos: ostatnia wartość ma być milion czy dziesięć milionów?) i przetestowałem z głębokością 7: 52 -12s a 48 - 13s.
Jutro startuję z głębokością 10 na 52, 48, 24, 16, 8, 4, 2, 1 (dokładnie w takiej koleności,zaczynam od 52), przewiduję obciążenie na jakieś dwie doby.

Na razie nie wiem jaka jest optymalna wartość ostatniego parametru. W tych testach ważne jest tylko, aby zawsze była taka sama.
Pozdrawiam i dzięki za testy.

[patyczak]

Polecenie:
threadMemPerft5 10 4 50000000 8 10000000

Wynik:
nodes:69352859712417 time:32666
Q9400

[krzyszp]

Polecenie:

Kod [Zaznacz] Rozwiń

threadMemPerft5 10 4 50000000 8 10000000

Kod [Zaznacz] Rozwiń

nodes:69352859712417 time:37149

Natomiast:

Kod [Zaznacz] Rozwiń

threadMemPerft2 10 4 6250000 8 6
jeszcze się wykonuje na Q6600

[Karlik]

Tylko taka jedna uwaga: fajnie, że optymalizujesz to pod kątem wątków, ale z tego co zrozumiałem to celujemy w BOINC. Jeśli tak to prawdopodobnie będziesz wykorzystywał jeden wątek (liczba projektów wielowątkowych jest naprawdę niewielka) lub musisz pójść w kierunku GPU a tam wątki będą działały na zupełnie innej zasadzie i inaczej się będą skalowały.