To co? Bawimy się? :D

[AXm77]

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.

To znaczy, że BOINC wymaga by aplikacja nie była wielowątkowa??

Pierwszy wynik:  :)

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 52 580000000 8 1000000 - nodes:69352859712417 time:2074



Porównując do wyników twojego Phenoma (moje Opterony to praktycznie ten sam procesor - jakiej prędkości RAM masz zainstalowany w tym systemie?) program skaluje całkiem nieźle: 1984s vs 2074s 2065s

[patyczak]

To znaczy, że BOINC wymaga by aplikacja nie była wielowątkowa??

Wydaje mi się, że nie ma takich wymagań. Zdarzały się projekty, w których jedno WU zajmowało dwa rdzenie.

[mimeq]

Zamknieta AQUA. Dzialajace Yafu, BURP, renderfarm.fi, bylo cos (nie wiem czy jest dalej) w Milce (nbody?), chyba (ale nie daje glowy) Test4Theory pod VM wszystko uzywalo/uzywa wiecej niz 1core. Wiec sam BOINC nie ogranicza applikacji i mozna liczyc mt.

[AXm77]

To chyba Yafu skaluje naprawdę pięknie, próbki które liczyły godzinami na i5, leciały w minutach na Opteronach.

Kolejny wynik:  :)

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 52 580000000 8 1000000 - nodes:69352859712417 time:2074
threadMemPerft5 10 48 580000000 8 1000000 - nodes:69352859712417 time:2065


Jak widać lepiej liczy gdy jest tyle samo wątków co rdzeni. 

[sknd]

zapodałem kompowi:
threadMemPerft 10 6 259200000 5 10000000

mam nadzieję, że to, ze ustawiłem boinca na 25% procesorów, by pozostałe rdzenie się nie nudziły, nie będzie wpływać na wyniki? Bo pewnie jakbym zostawił boinca na 100% to miałoby to wpływ spory? Pytam, bo chcę wyjść na parę godzin a wolałbym żeby komp nie miał pustego przebiegu jak już to policzy...

[AXm77]

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 52 580000000 8 1000000 - nodes:69352859712417 time:2074
threadMemPerft5 10 48 580000000 8 1000000 - nodes:69352859712417 time:2065
threadMemPerft5 10 32 580000000 8 1000000 - nodes:69352859712417 time:2883
threadMemPerft5 10 24 580000000 8 1000000 - nodes:69352859712417 time:3709


[Rysiu]

mam nadzieję, że to, ze ustawiłem boinca na 25% procesorów, by pozostałe rdzenie się nie nudziły, nie będzie wpływać na wyniki?

Może mieć wpływ ale jak duży to już nie wiem. Zależne od procesora i tego co się na nim liczy.

[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 12 1000000 | 69352859712417ok | 15643s |
   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
   2   | Q6600                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 37149s | 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
   2[2]| e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 5 10000000  | 69352859712417ok | 13683s | 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
   2   | Q9400                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 32666s | patyczak
   2   | AMD 48core             | threadMemPerft5 10 52 580000000 8 1000000 | 69352859712417ok | 2074s  | AXm77
   2   | AMD 48core             | threadMemPerft5 10 48 580000000 8 1000000 | 69352859712417ok | 2065s  | AXm77
   2   | AMD 48core             | threadMemPerft5 10 32 580000000 8 1000000 | 69352859712417ok | 2883s  | AXm77
   2   | AMD 48core             | threadMemPerft5 10 24 580000000 8 1000000 | 69352859712417ok | 3709s  | AXm77
   2   | AMD 48core             | threadMemPerft5 10 16 580000000 8 1000000 | 69352859712417ok | 5362s  | AXm77
------------------------------------------------------------------------------------------------------------------
[1] - z tej wersji prawdopodobnie zapomniałem usunąć asercje i spowolniły program.
[2] - dwa rdzenie komputera były obciążone


Polecenie:
threadMemPerft5 10 4 50000000 8 10000000
Wynik:
nodes:69352859712417 time:32666
Q9400

Dzięki, wynik dodany do tabelki.
Jeśli nie masz dosyć testów, to teraz np. takie komendy:
threadMemPerft5 10 4 50000000 8 1000000
threadMemPerft5 10 4 50000000 8 30000000
threadMemPerft5 10 4 50000000 8 100000000

threadMemPerft5 10 4 50000000 8 10000000
nodes:69352859712417 time:37149
Natomiast:
threadMemPerft2 10 4 6250000 8 6
jeszcze się wykonuje na Q6600

Czyli mamy kolejne potwierdzenie że threadMemPerft5 działa szybciej
niż threadMemPerft. Zobaczymy jeszcze jak wypadnie w porównaniu do
threadMemPerft2. Dzięki za testy.

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.

Optymalizacja w kierunku wątków wychodzi przy okazji, ale to chyba dobrze że użytkownik sam będzie
mógł wskazać ilość wątków? W przeciwnym razie ktoś z maszyną która ma 256 rdzeni będzie liczył
na jednym, a 255 będzie się marnowało :D.

Na razie optymalizuję w kierunku ochrony wątków przed wykonywaniem tych samych zadań. Na poziomie
5-ciu ruchów jeden układ powtarza się nawet kilkaset razy, bez optymalizacji program może kilkaset
razy liczyć dokładnie to samo zadanie. Jeśli ta ochrona jest dobra, to program sam z automatu lepiej
się skaluje.

Co do GPU, to tamte rdzenie nie mają stosu jak rdzenie w CPU. Rdzenie liczą wiele szybciej przy
mniejszej ilości tranzystorów, ale kosztem tego że się najlepiej nadają do obliczeń strumieniowych,
np. ciągłe mnożenie i dodawanie. W takim programie jak ten bym musiał zasymulować stos programowo
na jakiejś tabicy. Z tego powodu może się okazać, że na GPU będzie wolniej niż na CPU -
ale pewności na 100% nie mam, może kiedyś pomyślimy nad tym poważniej.

Porównując do wyników twojego Phenoma (moje Opterony to praktycznie ten sam procesor - jakiej prędkości RAM masz zainstalowany w tym systemie?) program skaluje całkiem nieźle: 1984s vs 2074s 2065s

Najlepszy wynik na phenomie 15186s * 6 rdzeni = 91116s
Twój wynik 2074 * 48 = 99552s
Czyli po ośmiokrotnym zwiększeniu łączny czas obliczeń zwiększył
się około 10% - ale to jednak inne warunki testowe :)
(99552 - 91116) / 91116 = 9,26%

Mój procesor jest przetaktowany w dół, a pamięć mam dwóch rodzajów na jednej
płycie - aż dziwne że to działa :D Więc powyższe obliczenia potem zrobimy
jeszcze raz, odwołując się tylko do Twoich wyników :)

To chyba Yafu skaluje naprawdę pięknie, próbki które liczyły godzinami na i5, leciały w minutach na Opteronach.
Kolejny wynik:  :)
threadMemPerft5 10 52 580000000 8 1000000 - nodes:69352859712417 time:2074
threadMemPerft5 10 48 580000000 8 1000000 - nodes:69352859712417 time:2065
Jak widać lepiej liczy gdy jest tyle samo wątków co rdzeni. 

Jeju, śmiga na tym sprzęcie że aż miło :D
Ile dziś trzeba zapłacić żeby mieć taki w domu?

zapodałem kompowi:
threadMemPerft 10 6 259200000 5 10000000
mam nadzieję, że to, ze ustawiłem boinca na 25% procesorów, by pozostałe rdzenie się nie nudziły, nie będzie wpływać na wyniki? Bo pewnie jakbym zostawił boinca na 100% to miałoby to wpływ spory? Pytam, bo chcę wyjść na parę godzin a wolałbym żeby komp nie miał pustego przebiegu jak już to policzy...

Obawiam się że będzie miało wpływ te 25%, ale to nic nie szkodzi, zobaczymy
dzięki temu w kolejnych warunkach czy aplikacja poda dobry wynik i czy się nie wywali.


Dzięki wszystkim i pozdrawiam.

P.S.
Testuję kolejną wersję programu, na małych głębokościach nie widzę przyspieszenia.
Jeśli na dużych głębokościach będą u mnie wyniki podobne lub lepsze, to wrzucę
kolejną wersję do przetestowania.

P.S 2
Widać że na razie wygrywa wersja threadMemPerft5, ale od czasu do czasu
wersja threadMemPerft2 też działa ładnie. Może da się zrobić hybrydę z
tych dwóch wersji - zobaczymy czy hybryda będzie miała zalety czy wady
swoich protoplastów :)

[krzyszp]

Następny wynik dla

Kod [Zaznacz] Rozwiń

threadMemPerft2 10 4 6250000 8 6

Wynosi

Kod [Zaznacz] Rozwiń

nodes:69352859712417 time:41457

Komputer stale obciążony...

Wykonam te testy jeszcze raz przy wstrzymanym liczeniu BOINC - zobaczymy, jak bardzo skróci to obliczenia...

[AXm77]

...
Jeju, śmiga na tym sprzęcie że aż miło :D
Ile dziś trzeba zapłacić żeby mieć taki w domu?
....

Mniej niż by się mogło wydawać. :)

Koleny wynik:

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 52 580000000 8 1000000 - nodes:69352859712417 time:2074
threadMemPerft5 10 48 580000000 8 1000000 - nodes:69352859712417 time:2065
threadMemPerft5 10 32 580000000 8 1000000 - nodes:69352859712417 time:2883
threadMemPerft5 10 24 580000000 8 1000000 - nodes:69352859712417 time:3709
threadMemPerft5 10 16 580000000 8 1000000 - nodes:69352859712417 time:5362


[mariotti]

Następny wynik dla

Kod [Zaznacz] Rozwiń

threadMemPerft2 10 4 6250000 8 6
Wynosi

Kod [Zaznacz] Rozwiń

nodes:69352859712417 time:41457
Komputer stale obciążony...
Wykonam te testy jeszcze raz przy wstrzymanym liczeniu BOINC - zobaczymy, jak bardzo skróci to obliczenia...

Jeśli stale jest obciążony to możliwe że spowalnia każdy test w podobnym stopniu. Jeśli w
podobnym, to można porównywać.

Zastanawiam się jakie przyspieszenia są ważne dla tego projektu, a jakie należy zignorować. Wydaj mi
się, że przyspieszenie o 5% jest jeszcze warte zachodu. Dokładność pomiaru +-3% w zupełności
wystarczy, a +-5% też da jakiś pogląd.

Teraz z inne beczki.
Będę musiał zoptymalizować aplikację liniowo - przypuszczam że to się bardzo opłaci. Pomysły na
optymalizacje algorytmiczne powoli mi się wyczerpują i już niewiele dają. Optymalizacja liniowa
zajmie mi sporo czasu, to żmudna robota. Zastanawiam się, żeby odpalić już jakąś namiastkę
docelowego serwera, może na razie coś przez interfejs www. W czasie gdy ja bym pracował na
optymalizacją liniową, to na kilku kompach byśmy mogli sprawdzać jak sprawuje się całość.

Na głębokości 4 ruchów jest 8902 liści, a tym tylko 5362 unikalnych. Można te unikalne wgrać na
jakiś serwer. Klient może pobierać jednorazowo 20 zadań, następnie je przeliczać na głębokość 9-ciu
ruchów i wyniki odsyłać. Przed obliczeniami klient będzie musiał nadać sobie losowe wartości
kluczy zobrista. W celu weryfikacji, każdy układ powinien być dwa razy przeliczony. Czasochłonność
przeliczenia 20 zadań na głębokość 9 ruchów powinna być podobna do jednego na 10 ruchów. Możemy
się spodziewać że jeden taki task będzie trwał 4-10h (przed optymalizacją, na zwykłych
komputerach). 5362/20 daje 268 tasków. Na 10 komputerach po jednym tasku na dobę policzymy w
miesiąc. Uzyskamy w ten sposób wynik dla głębokości 13 ruchów. Zobaczymy czy wynik jest
prawidłowy, jeśli nie będzie prawidłowy, to zrobimy drugą rundę i sprawdzimy czy działa weryfikacja.

Jeśli wszystko zadziała, to sprawdzimy jeszcze pobieżnie wersję zoptymalizowaną - do tego czasu
powinienem mieć gotową.  Wtedy będziemy gotowi na większe głębokości i na sprzężenie tego wszystkiego
z siecią BOINC.

Co myślicie?

[krzyszp]

Jak najbardziej za :)

natomiast pomyślałbym już o stawianiu serwera pod boinc - w końcu możesz wygodnie wysyłać za jego pomocą próbki do znacznie większej ilości komputerów z różną konfiguracją, a i wyniki testów będziesz miał szybciej...
Może TJM mógłby Ci pomóc postawić serwer? Oczywiście, musiałbyś zrobić zamknięte testy próbek, bo bez sensu by było na tę chwilę marnować czas na tłumaczenia "co i jak" światu... A i wprawy w zarządzaniu serwerem mógłbyś nabrać.

[Karlik]

Optymalizacja w kierunku wątków wychodzi przy okazji, ale to chyba dobrze że użytkownik sam będzie mógł wskazać ilość wątków? W przeciwnym razie ktoś z maszyną która ma 256 rdzeni będzie liczył na jednym, a 255 będzie się marnowało :D.

Co do GPU, to tamte rdzenie nie mają stosu jak rdzenie w CPU. Rdzenie liczą wiele szybciej przy
mniejszej ilości tranzystorów, ale kosztem tego że się najlepiej nadają do obliczeń strumieniowych,
np. ciągłe mnożenie i dodawanie. W takim programie jak ten bym musiał zasymulować stos programowo
na jakiejś tabicy. Z tego powodu może się okazać, że na GPU będzie wolniej niż na CPU -
ale pewności na 100% nie mam, może kiedyś pomyślimy nad tym poważniej.

Ja tylko rzucam pomysłami, sam musisz ocenić dopasowanie do swojego algorytmu, bo ja go nie znam :D Co do liczby wątków to przy 255 rdzeniach już zmieni Ci się sposób skalowania ze względu na dość spore odległości pomiędzy skrajnymi rdzeniami i rdzeniami a pamięcią. Dopóki masz 1-2 procesory możesz się tym praktycznie nie przejmować, ale przy większej liczbie musisz się zastanowić czy czasy "transportu danych" i synchronizacji pamięci (cache<->RAM) nie spowodują jakichś dodatowych problemów.
Poza tym nie wiem jak sobie wyobrażasz opcje konfiguracyjne dla klienta. Miałby po jednym profilu dla każdego komputera, żeby mógł sobie ustawić ile rdzeni chce przeznaczyć na obliczenia? Albo będziesz procentową liczbę dostępnych brał (nie wiem jak rozróżnisz fizyczne od wirtualnych - chyba musiałbyś sobie zrobić katalog wszystkich procesorów z HT). Tylko wtedy wymuszasz na użytkowniku: albo liczysz moje albo cudze, jednocześnie nie pozwalam. :/ Nie chcę bombardować pomysłu, ale jakoś nie potrafię znaleźć rozwiązania optymalnego tej sytuacji.

[sknd]

threadMemPerft 10 6 259200000 5 10000000
nodes:69352859712417 time:13683

zrobione na e3-1230 v2 przy dwóch rdzeniach boincujących ;)

[mariotti]

Ja tylko rzucam pomysłami, sam musisz ocenić dopasowanie do swojego algorytmu, bo ja go nie znam :D

Mnie też jest trudno ocenić, poza oczywistymi sprawami, muszę napisać i zmierzyć czas; a w tych oczywistych
czasami też mi oczy wyłażą ze zdziwienia :) Dobra aplikacja na GPU to masakryczna ilość roboty i potem test -
albo działa szybciej, albo wolniej.

Co do liczby wątków to przy 255 rdzeniach już zmieni Ci się sposób skalowania ze względu na dość spore odległości pomiędzy skrajnymi
rdzeniami i rdzeniami a pamięcią. Dopóki masz 1-2 procesory możesz się tym praktycznie nie przejmować, ale przy większej liczbie musisz
się zastanowić czy czasy "transportu danych" i synchronizacji pamięci (cache<->RAM) nie spowodują jakichś dodatowych problemów.

Jeśli mamy dużą ilość rdzeni, np. te 256, to w celu pełnego wykorzystania, mamy dwie możliwości:
1) odpalić kilka aplikacji niezależnie.
2) odpalić jedną na 256 wątkach.

Zalety 1)
  -każda aplikacja działa na lokalnych danych, nie ma kosztów transferów, jest więcej trafień w cache.

Zalety 2)
- aplikacja ma do dyspozycji ogromną ilość RAM - można lepiej ochronić przed liczeniem tych samych pod-zadań,
- w ogóle można znaleźć i odrzucić więcej takich samych pod-zadań.

Co się opłaci? Oczywiście zależy od kosztów transferów. Jednak ogromna pamięć tak mocno
przyspiesza, że ja choć nie wiem, to mocno obstawiam wersję drugą.

Poza tym nie wiem jak sobie wyobrażasz opcje konfiguracyjne dla klienta. Miałby po jednym profilu dla każdego komputera, żeby
mógł sobie ustawić ile rdzeni chce przeznaczyć na obliczenia? Albo będziesz procentową liczbę dostępnych brał (nie wiem jak
rozróżnisz fizyczne od wirtualnych - chyba musiałbyś sobie zrobić katalog wszystkich procesorów z HT). Tylko wtedy wymuszasz
na użytkowniku: albo liczysz moje albo cudze, jednocześnie nie pozwalam. :/ Nie chcę bombardować pomysłu, ale jakoś nie potrafię
znaleźć rozwiązania optymalnego tej sytuacji.

Nie wiem jak to wygodnie rozwiązać.  Najlepiej jakby użytkownik się znał i wpisał ręcznie sam :D Można też zrobić benchmark. W benchmarku
program będzie zwiększał sobie ilość rdzeni i pamięci tak długo, aż zacznie spowalniać - ale to też jest związane z problemami.

Pozdrawiam i dzięki.

[mariotti]

threadMemPerft 10 6 259200000 5 10000000
nodes:69352859712417 time:13683
zrobione na e3-1230 v2 przy dwóch rdzeniach boincujących ;)

Dzięki, dodane do tabelki.

[mariotti]

Jak najbardziej za :)
natomiast pomyślałbym już o stawianiu serwera pod boinc - w końcu możesz wygodnie wysyłać za jego pomocą próbki do znacznie większej ilości komputerów z różną konfiguracją, a i wyniki testów będziesz miał szybciej...

No cóż, to już są powalające argumenty, a są jeszcze inne za BOINC...
Będzie trzeba tak zrobić. Najgorzej z konfiguracją, poprzednio mi się nie udało :/
Spróbuję jeszcze raz.

Może TJM mógłby Ci pomóc postawić serwer? Oczywiście, musiałbyś zrobić zamknięte testy próbek, bo bez sensu by było na tę chwilę marnować czas na tłumaczenia "co i jak" światu... A i wprawy w zarządzaniu serwerem mógłbyś nabrać.

Muszę się nauczyć.
Więc przygotujcie się, że zasypię was wkrótce masą lamerskich pytań :D

Pozdrawiam
P.S.
Jaki dział forum jest na pytania o konfigurację serwera?

[Rysiu]

Ja mogę udostępnić kawałek OProject@Home. Aplikacja jednak musi być raczej jednowątkowa. Nie wiem też jak z dostosowywaniem jej do BOINC - większością spraw mogę się zająć ale częścią już nie.

Nowy admin by się przydał  :parrrty:

[mariotti]

Ja mogę udostępnić kawałek OProject@Home. Aplikacja jednak musi być raczej jednowątkowa. Nie wiem też jak z dostosowywaniem jej do BOINC - większością spraw mogę się zająć ale częścią już nie.
Nowy admin by się przydał  :parrrty:

Przy dostosowywaniu aplikacji do BOINC będę miał problemy, ale raczej małe, raczej dam radę.
Ilość wątków się ustawia, można ustawić jeden lub sto, można ustawić na stałe, może użytkownik ustawiać, obojętnie.
Boję się tej całej instalacji i konfiguracji, tutaj mogę potrzebować dużo pomocy.
Pozdrawiam

[AXm77]

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 8 580000000 8 1000000 - nodes:69352859712417 time:10352


[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 12 1000000 | 69352859712417ok | 15643s |
   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 |
   3   | Phenom II 1050T 2.4GHz | threadMemPerft6 10 6 250000000 8  1000000 | 69352859712417ok | 13618s |
   3   | Phenom II 1050T 2.4GHz | threadMemPerft6 10 6 250000000 8 10000000 | 69352859712417ok | 13599s |

   0   | Q6600                  | threadMemPerft 10 5 50000000 8 1000000    | 69352859712417ok | 42144s | krzyszp
   2   | Q6600                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 37149s | 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 |
   3   | i7 950 @3.07GHz        | threadMemPerft6 10 5 450000000 8 30000000 | 69352859712417ok | 10359s |
   3   | i7 950 @3.07GHz        | threadMemPerft6 10 5 450000000 8 10000000 | 69352859712417ok | 10341s |

   0   | e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 8 200       | 69352859712417ok | 16895s | sknd
   2[2]| e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 5 10000000  | 69352859712417ok | 13683s | 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

   2   | Q9400                  | threadMemPerft2 10 4 6250000 8 6          | 69352859712417ok | 34954s | patyczak
   2   | Q9400                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 32666s | patyczak

   2   | AMD 48core             | threadMemPerft5 10  4 580000000 8 1000000 | 69352859712417ok | 19820s | AXm77
   2   | AMD 48core             | threadMemPerft5 10  8 580000000 8 1000000 | 69352859712417ok | 10352s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 16 580000000 8 1000000 | 69352859712417ok |  5362s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 24 580000000 8 1000000 | 69352859712417ok |  3709s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 32 580000000 8 1000000 | 69352859712417ok |  2883s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 52 580000000 8 1000000 | 69352859712417ok |  2074s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 48 580000000 8 1000000 | 69352859712417ok |  2065s | AXm77
------------------------------------------------------------------------------------------------------------------
[1] - z tej wersji prawdopodobnie zapomniałem usunąć asercje i spowolniły program.
[2] - dwa rdzenie komputera były obciążone




Byłem już sceptyczny, ale są rekordowe czasy na dwóch różnych komputerach.
Na dużych głębokościach polecenie threadMemPerft6 działa wyraźnie szybciej, choć
na małych nie było żadnego efektu. Zatem udostępniam  trzecią wersję programu :D


Z poleceniem threadMemPerft6 można tak samo kombinować jak z threadMemPerft5 - parametry
w piątce i szóstce mają takie samo znaczenie, zmienił się tylko algorytm.

Pozdrawiam

[patyczak]

Czyli jak coś liczę na drugiej wersji programu to lepiej przerwać i liczyć na trzeciej wersji czy dokończyć?

[mariotti]

Czyli jak coś liczę na drugiej wersji programu to lepiej przerwać i liczyć na trzeciej wersji czy dokończyć?

Można dokończyć. Potem będzie więcej materiału do porównania z następnymi wynikami :)

[Dario666]

Ja też jestem za tym, by ten program był jednowątkowy, bo to znacznie upraszcza sprawę. Nie ma takich problemów jak np. z Yafu, który liczy serię zadań, powiedzmy na 16 rdzeniach, i czeka aż wszystkie 16 się skończy. Dopiero wtedy znów zapodaje 16 nowych zadań. Nie trzeba mówić, że niektóre zadania kończą się znacznie szybciej, więc pozostały czas tych rdzeni jest "marnowany".

Można by było zrobić tak jak w OPTIMA@home, gdzie zadania są ściągane praktycznie na bieżąco (po zwrocie poprzedniego WU) i wtedy serwer kształtowałby listę zadań na bieżąco.

[patyczak]

Kolejny wynik (druga wersja programu):

Kod [Zaznacz] Rozwiń


threadMemPerft2 10 4 6250000 8 6
nodes:69352859712417 time:34954

Q9400

[mariotti]

Ja też jestem za tym, by ten program był jednowątkowy, bo to znacznie upraszcza sprawę. Nie ma takich problemów jak np. z Yafu, który liczy serię zadań, powiedzmy na 16 rdzeniach, i czeka aż wszystkie 16 się skończy. Dopiero wtedy znów zapodaje 16 nowych zadań. Nie trzeba mówić, że niektóre zadania kończą się znacznie szybciej, więc pozostały czas tych rdzeni jest "marnowany".

Trochę boję się chwalić przedwcześnie, ale te problemy mam chyba całkiem ładnie
rozwiązane, zwłaszcza w najnowszej wersji. Wątki równo startują i równo się kończą -
przynajmniej bardzo starałem się uzyskać taki efekt. Można włączyć monitor systemu,
ustawić tick czasu na 5-10s, nasŧepnie można odpalić program na jakiś test który
trwa chociaż z 1000 sekund i na wykresie pokaże się nam obciążenie rdzeni w czasie.

Problem pod-zadań też mam przemyślany. Program za jednym razem ściągnie 20-100
pod-zadań. Następnie każde z pod-zadań dzielone jest na wiele jeszcze mniejszych
tasków. Te najmniejsze taski są ustawiane w kolejce, a wątki pobierają je z kolejki. Jak
ustawimy jeden wątek, to z kolejki będzie pobierał jeden wątek i system będzie obciążony
jednym wątkiem - nie będzie to stanowiło żadnego problemu. Jak ktoś zdecyduje się
na liczenie w pięciu wątkach, to system będzie obciążony pięcioma, a kolejka prawie
pięć razy szybciej się opróżni.  Każdy będzie mógł aplikację używać zgodnie ze swoimi
preferencjami - podobnie sprawa tyczy się pamięci - każdy udostępni aplikacji tyle RAM,
ile uzna za stosowne.  Aplikacja po prostu jest tak napisana, żeby umiała wykorzystać wszystko
co użytkownik zdecyduje się jej  udostępnić, a przynajmniej tak się starałem :D

Tak czy inaczej, aplikacja może z powodzeniem pracować jako jednowątkowa.


Pewnie jeszcze niepokojąca jest sprawa dlaczego ma pobierać 20-100 zadań za
jednym razem. Otóż jestem prawie pewny, że 100 zadań "jednocześnie" policzy się
znacznie szybciej niż te same 100 zadań jedno po drugim. Nie wiem jakie to
będzie przyspieszenie, ale może być duże... rzędu 2-3 razy. Jeśli czekanie
przez pół doby na zakończenie będzie niewygodne, to dorobimy jakieś save-owanie.

Można by było zrobić tak jak w OPTIMA@home, gdzie zadania są ściągane praktycznie na bieżąco (po zwrocie poprzedniego WU) i wtedy serwer kształtowałby listę zadań na bieżąco.

Efekt dla użytkownika będzie podobny. Program ściągnie zadanie, a potem odeśle wyniki.
Właściwie to użytkownik może nawet nie zauważyć, że ściąga paczkę zadań, a nie jedno
zadanie.



Pozdrawiam

[mariotti]

Kolejny wynik (druga wersja programu):

Kod [Zaznacz] Rozwiń


threadMemPerft2 10 4 6250000 8 6
nodes:69352859712417 time:34954

Q9400

Czyli piątka wgrała? :D

Pozdrawiam

[patyczak]

Kolejny wynik (druga wersja programu):

Kod [Zaznacz] Rozwiń


threadMemPerft2 10 4 6250000 8 6
nodes:69352859712417 time:34954

Q9400

Czyli piątka wgrała? :D

Na to wygląda  ;D

[mariotti]

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 8 580000000 8 1000000 - nodes:69352859712417 time:10352


Zastanawiam się, czy jest sens testów na mniejszej ilości niż 4 rdzenie. Może w tym
czasie lepiej zrobić analogiczny test dla wersji threadMemPerft6?

Poza tym niektóre procesory gdy pracują na jednym wątku to potrafią przyspieszyć
zegar, więc na małej ilości wątków może nam wyjść dobry czas, ale spowodowany
czymś innym niż zła skalowalność :)

Pozdrawiam

[AXm77]

Doliczę te 4 (jeszcze jakieś 2 godziny - tak przewiduje).
Opterony 6176 nie mają turbo, także po obciążeniem zawsze będzie 2.3 max.
Planuję jeszcze na "5" przeliczyć 12 i 36 (czyli obciążenie całego jednego i trzech procesorów.)

[mariotti]

Doliczę te 4 (jeszcze jakieś 2 godziny - tak przewiduje).
Opterony 6176 nie mają turbo, także po obciążeniem zawsze będzie 2.3 max.

Fajnie, dzięki.

[Karlik]

W sumie odnośnie procesów i wątków przyszło mi do głowy takie rozwiązanie ze względu na podejście, które opisałeś (w sumie bazuje na ogólnych zasadach działania systemów rozproszonych):
1. Uruchom program.
2. Spróbuj się podłączyć do istniejącej puli zasobów.
3. Udało się - wykonuj te zadania.
4. Nie udało się - zostań masterem i stwórz interfejs do podłączenia się innych procesów.
Wtedy możnaby względnie dynamicznie z poziomu klienta zmieniać liczbę wątków, które w danym momencie mają pracować. Teraz pojawia się innego rodzaju problem - przydział zadań. Nie pisałem nic po stronie boincowego serwera, ale można spróbować zrobić coś takiego, że wysyłamy próbki z tymi samymi danymi w liczbie takiej jak mu ustawimy w opcjach lub liczbie rdzeni procesora. Potem już procesy po stronie klienta się martwią jak to ogarnąć (patrz wyżej), potem master wysyła gotowe dane a reszta nic (albo te same dane). Jeżeli checkpointy będziemy zapisywać w folderze projektu a nie slotu to raczej dałoby się coś takiego zrobić (wtedy nie ma znaczenia kolejność wznawiania procesów - po prostu najwcześniej uruchomiony robi za mastera). Gdybyśmy jednak uruchamiali te procesy po kolei, trzebaby po prostu spowodować wyłączenie procesu jeżeli wcześniej już wszystko w obrębie próbki zostało przeliczone (wystarczy stwierdzić, że nie ma pliku wejściowego albo coś w tym stylu).

[mariotti]

W sumie odnośnie procesów i wątków przyszło mi do głowy takie rozwiązanie ze względu na podejście, które opisałeś (w sumie bazuje na ogólnych zasadach działania systemów rozproszonych):
1. Uruchom program.
2. Spróbuj się podłączyć do istniejącej puli zasobów.
3. Udało się - wykonuj te zadania.
4. Nie udało się - zostań masterem i stwórz interfejs do podłączenia się innych procesów.

W ogóle to jest fajna strategia. Taki program żyje sam własnym życiem i nie potrzebuje jednego
centralnego systemu. Myślałem żeby w ten sposób zrobić program do samouczenia. Na każdym
kliencie program próbuje nowej strategii. Jeśli nowa strategia wydaje się dobra, to prosi dowolnego
losowego klienta o przetestowanie takiej samej. Tamten mu odpowiada czy też się udało czy nie.
Jeśli się udało, to porównuje ze swoją najlepszą. Ostatecznie strategia otrzymuje tym większą
rangę im częściej była testowana, a przeżycie strategii w środowisku rozproszonym zależałoby
tylko od tej rangi. Najlepsze szybko by się propagowały, gorsze by umierały, potem z najlepszych
ewoluowałyby jeszcze lepsze... Koncepcyjnie taki pomysł jest prosty i fajny, ale realizacja to
masakryczny nakład pracy :)

Czy taka strategia nadaje się do tego problemu, który tylko zlicza węzły? Myślę że tak. Ale
cała baza zadań jest zbyt duża, aby każdy klient miał jej kopię. Zatem klient musiałby mieć
tylko jakiś seed, a na jego podstawie mógłby ustalić za jaką część bazy jest odpowiedzialny.
Bazę można podzielić na setki albo tysiące takich części. Gdy taki klient nie może połączyć się z
żadnym innym, to realizuje losowe-niewykonane zadania ze swojej bazy. Gdy może się połączyć, to dokonuje
synchronizacji.  Niektóre klienty wygenerują błędne obliczenia, więc jeśli coś zostanie policzone
nadmiarowo to nawet lepiej. W końcu gdy klient miałby wszystkie wyniki dla swojej części bazy, to
by je wysłał na maszynę centralną - czyli jednak jakaś maszyna centralna musi być, choćby o
takim marginalnym znaczeniu :)

No ale znów dochodzimy do czegoś, co koncepcyjnie jest proste, a w realizacji masakra :)

Wtedy możnaby względnie dynamicznie z poziomu klienta zmieniać liczbę wątków, które w danym momencie mają pracować. Teraz pojawia się innego rodzaju problem - przydział zadań. Nie pisałem nic po stronie boincowego serwera, ale można spróbować zrobić coś takiego, że wysyłamy próbki z tymi samymi danymi w liczbie takiej jak mu ustawimy w opcjach lub liczbie rdzeni procesora. Potem już procesy po stronie klienta się martwią jak to ogarnąć (patrz wyżej), potem master

Można zrobić jeszcze lepszy hardcore, taki żeby mastera prawie nie było :D
Master tylko daje 1000 wersji programu do pobrania, każda wersja ma inny seed - czyli
ta część serwera to serwer FTP :D  Potem program działają jak wirus - z taką tylko różnicą że
klonują się za  zgodą właściciela komputera. Ostatecznie na mastera wysyłają dane.
A może nawet by nie musiały na mastera wysyłać wyników :D

wysyła gotowe dane a reszta nic (albo te same dane). Jeżeli checkpointy będziemy zapisywać w folderze projektu a nie slotu to raczej dałoby się coś takiego zrobić (wtedy nie ma znaczenia kolejność wznawiania procesów - po prostu najwcześniej uruchomiony robi za mastera). Gdybyśmy jednak uruchamiali te procesy po kolei, trzebaby po prostu spowodować wyłączenie procesu jeżeli wcześniej już wszystko w obrębie próbki zostało przeliczone (wystarczy stwierdzić, że nie ma pliku wejściowego albo coś w tym stylu).

Nom fajne to wszystko, ale za dużo roboty...

Zrobimy standardowo, czyli synchronizacja na centralnym serwerze :)

Pozdrawiam

[AXm77]

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 4 580000000 8 1000000 - nodes:69352859712417 time:19820


[mariotti]

Kod [Zaznacz] Rozwiń


threadMemPerft5 10 4 580000000 8 1000000 - nodes:69352859712417 time:19820


Dodane do tabelki powyżej.
Pozdrawiam

[AXm77]

Niezłe przyśpieszenie na "6"-tce:  :)

Kod [Zaznacz] Rozwiń


threadMemPerft6 10 52 580000000 8 1000000 - nodes:69352859712417 time:1658
threadMemPerft6 10 48 580000000 8 1000000 - nodes:69352859712417 time:1642
threadMemPerft6 10 32 580000000 8 1000000 - nodes:69352859712417 time:2383
threadMemPerft6 10 24 580000000 8 1000000 - nodes:69352859712417 time:3080


[mariotti]

Niezłe przyśpieszenie na "6"-tce:  :)

Kod [Zaznacz] Rozwiń


threadMemPerft6 10 52 580000000 8 1000000 - nodes:69352859712417 time:1658
threadMemPerft6 10 48 580000000 8 1000000 - nodes:69352859712417 time:1642
threadMemPerft6 10 32 580000000 8 1000000 - nodes:69352859712417 time:2383
threadMemPerft6 10 24 580000000 8 1000000 - nodes:69352859712417 time:3080


Dziękuję. Niezła maszynka do liczenia.

Ciekawy jestem kilku rzeczy....
Po pierwsze jakby ta aplikacja bez przeróbek działała na klastrze, np. na 6ciu komputerach i każdy
komputer z jednym procesorem 8-rdzeniowym . Po drugie jakby działała po przystosowaniu do obliczeń
na klastrze. Po trzecie jakby działała tak po prostu na jakimś amazonie. Apropo... czy orientuj się
ktoś ile na amazonie kosztuje wynajęcie np. 100 rdzeni na 1 godzinę? Jeśli niedrogo, to można
spróbować :) Jeszcze jedna rzecz mnie ciekawi, jak aplikacja by się zachowała na kompie z
ogromną ilością pamięci, np. 1TB ramu. Rysiu załatwił mi do testów maszynkę która ma 256GB ram,
ale dopiero uczę się obsługi :)

Pozdrawiam

[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 12 1000000 | 69352859712417ok | 15643s |
   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 |
   3   | Phenom II 1050T 2.4GHz | threadMemPerft6 10 6 250000000 8  1000000 | 69352859712417ok | 13618s |
   3   | Phenom II 1050T 2.4GHz | threadMemPerft6 10 6 250000000 8 10000000 | 69352859712417ok | 13599s |

   0   | Q6600                  | threadMemPerft 10 5 50000000 8 1000000    | 69352859712417ok | 42144s | krzyszp
   2   | Q6600                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 37149s | 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 |
   3   | i7 950 @3.07GHz        | threadMemPerft6 10 5 450000000 8 30000000 | 69352859712417ok | 10359s |
   3   | i7 950 @3.07GHz        | threadMemPerft6 10 5 450000000 8 10000000 | 69352859712417ok | 10341s |

   0   | e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 8 200       | 69352859712417ok | 16895s | sknd
   2[2]| e3-1230 v2 3.3ghz      | threadMemPerft 10 6 259200000 5 10000000  | 69352859712417ok | 13683s | 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

   2   | Q9400                  | threadMemPerft2 10 4 6250000 8 6          | 69352859712417ok | 34954s | patyczak
   2   | Q9400                  | threadMemPerft5 10 4 50000000 8 10000000  | 69352859712417ok | 32666s | patyczak

   2   | AMD 48core             | threadMemPerft5 10  4 580000000 8 1000000 | 69352859712417ok | 19820s | AXm77
   2   | AMD 48core             | threadMemPerft5 10  8 580000000 8 1000000 | 69352859712417ok | 10352s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 16 580000000 8 1000000 | 69352859712417ok |  5362s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 24 580000000 8 1000000 | 69352859712417ok |  3709s | AXm77
   2   | AMD 48core             | threadMemPerft6 10 24 580000000 8 1000000 | 69352859712417ok |  3080s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 32 580000000 8 1000000 | 69352859712417ok |  2883s | AXm77
   2   | AMD 48core             | threadMemPerft6 10 32 580000000 8 1000000 | 69352859712417ok |  2383s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 52 580000000 8 1000000 | 69352859712417ok |  2074s | AXm77
   2   | AMD 48core             | threadMemPerft5 10 48 580000000 8 1000000 | 69352859712417ok |  2065s | AXm77
   2   | AMD 48core             | threadMemPerft6 10 52 580000000 8 1000000 | 69352859712417ok |  1658s | AXm77
   2   | AMD 48core             | threadMemPerft6 10 48 580000000 8 1000000 | 69352859712417ok |  1642s | AXm77

------------------------------------------------------------------------------------------------------------------
[1] - z tej wersji prawdopodobnie zapomniałem usunąć asercje i spowolniły program.
[2] - dwa rdzenie komputera były obciążone


[sknd]

Jeśli czekanie przez pół doby na zakończenie będzie niewygodne, to dorobimy jakieś save-owanie.

No, to jest sprawa podstawowa  :p_arr:

[mariotti]

Jeśli czekanie przez pół doby na zakończenie będzie niewygodne, to dorobimy jakieś save-owanie.

No, to jest sprawa podstawowa  :p_arr:

Zależy ile czasu będzie się wykonywał jeden task. A czas wykonania jednego
tasku zależy od tego, jak mi się uda przyspieszyć program. Zależy także od
tego, czy opłaci się do jednego tasku upakować 5 układów czy może 100.

Pozdrawiam