BOINC@Poland

Aktualna wersja: 0.4.6.1

Wymagania na chwilę obecną dla wersji 0.4.6.1:
- sterowniki Catalyst 9.2+ (zalecane 9.12 HotFix (http://support.amd.com/us/kbarticles/Pages/ATICatalyst912Hotfix.aspx))
- system windows app działa na x86 i x64
- karta graficzna z serii Radeon HD2k HD3k HD4k HD5k (zalecana karta z serii HD 4000 lub nowsza)

Link do aktualnej wersji: www.sesef.pl/AP/AP26PGx86-461.zip

Podczas liczenia powinien pojawić się plik SOL-AP26.TXT w nim zapisywany jest wynik, niby u mnie i u Oxy wyniki wyszły poprawne, ale jak ktoś chce sprawdzić to poprawna zawartość pliku SOL jest następująca:

Wynik dla kart serii 2k, 3k, 4k, 57xx (i niższe modele)

Cytat11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
13 366384 2167218735183577

Wynik dla kart serii 5800, 5900

Cytat11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
10 366384 1540799946122147
13 366384 2167218735183577

Podziękowania dla:
- Oxy
- Satanetva
- Obix
- Robert_7NBI
- Erni
- Wszystkich którzy siedzieli na ircu i znosili moje marudzenie, że czegoś nie ma w ATI Stream albo, że mi coś nie działa itp.

=======================================================================
Testy:

Interesuje mnie czas z pliku stderr.txt (PrimeTest time: 19.511147 Total time: 115.975238), oraz najlepiej to co pojawi się w konsoli

zaluje ze nie mam ATI zeby cie wspomoc moimi testami  :shame:

Maly blad w nicku ale dzieki za podziekowania. No i znowu musze nowy system stawiac :D. Tym razem Vista x64 :D

XP64 stery 9.8

plik wynikowy:

10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

Czas obliczen - 510 sekund. Obciazenie CPU - od 25% do 32% Obciazenie GPU 41%

za duże obciążenie CPU :D

To zależy od tego, ile wątków da się równocześnie liczyć na GPU. Jeśli tylko jeden, to może być, a jeśli 4, to trzeba to lekuchno poprawić.

Obciążenie CPU to jest chwila roboty wystarczy dodać w dwóch miejscach sleep(100); i już praktycznie użycie cpu jest znikome, ale jednak wydłuża to czas działania i zaciera prawdziwe wyniki tak więc jak już zejdę odpowiednio nisko z czasem to wtedy będzie można się bawić w dobieranie odpowiedniego sleepa.

Dzisiaj sprawdzilem jeszcze raz ten ap26 ustawiłem Sapphirka D0 na 840 /reszta na 500/ i sie zmieniło

Obciazenie GPU 58% czas ok 362sek dziwne musze to przedyskutowac dlaczego.

[EDIT]

10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

czas liczenia 4:49 (289s) obciązenie CPU 12.5% - jeden rdzeń na full, obciązenie GPU 49.4% (4890@920), cat 9.8, win7 x64

10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

System operacyjny  Microsoft Windows Vista 64 Home Premium
Dodatek service pack systemu operacyjnego            Service Pack 2
Internet Explorer                                          8.0.6001.18813
DirectX                                                    DirectX 10.1
Typ procesora                                              QuadCore AMD Phenom II X4 810,
Nazwa płyty głównej                                        Gigabyte GA-MA790XT-UD4P 
Pamięć fizyczna                                            4096 MB  (DDR3-1333 DDR3 SDRAM) Dual
DIMM1: Kingston 9905403-011.A02LF 
DIMM2: Kingston 9905403-011.A02LF 
Karta wideo                   Sapphire Radeon HD 4850  625/975
sterowniki ATI Catalyst 9.5
10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

czas 568 sek
GPU 50%
CPU0 - 61-36%
CPU1 - 7-19%
CPU2- 21-28%
CPU3- 2-16%

Posprawdzałem, sito liczy się tak szybko, że tam to ja już nic więcej nie zrobię (znaczy dałoby radę jeszcze podkoksować, ale nie z moja wiedzą bo jedyne co mnie teraz tam ogranicza to liczenie remaindera)

Teraz problemem jest szybkość generowania liczb, które trafiają do GPU. W wersji 0.1 robi to CPU i wygenerowanie zrobiłem małe testy porównawcze wygenerowanie przez CPU 443555 liczb trwa około 0,007 sekundy, może i niewiele, ale jak taką operacje będzie trzeba wykonać 12376 razy to już z tego robi się 86 sec, wygenerowanie takiej samej ilości liczb na gpu trwa 0,00024 sekundy (przy bardzo nie wydajnym algorytmie) przy 12376 wywołaniach to jest jakieś 3,1 sekundy widać kolosalną różnicę jednak jest pewien mankament. Przy generowaniu na GPU zawiesza się pulpit gpu zostaje tak obciążone, że nie daje nawet rady odświeżyć pulpitu, jak uda mi się z tym uporać to program powinien trochę przyspieszyć :).

3,1 sekundy freeze przeboleć można :D

Niestety generowania liczb na gpu idzie na kołek :( generuje je szybciej niż CPU, ale są one potem potrzebne jeszcze przy sprawdzaniu pierwszości, która jest robiona na CPU, więc muszę te liczby ściągnąć z GPU na CPU, a niestety droga GPU -> jest z 2-2,5x wolniejsza niż CPU->GPU, więc w ogólnym rozrachunku wyszło, że wygenerowanie liczb na gpu+przesłanie ich GPU -> CPU trwa dłużej niż wygenerowanie ich na CPU + przesłanie ich CPU -> GPU (wygenerowane liczby zostaną na CPU więc nie trzeba ich potem ściągać z GPU).

Jako, że generowanie liczb powinno powrócić z powrotem na GPU to mam 2 rozwiązania jakoś pozbyć się tych liczb ze sprawdzania pierwszości, albo wywalić sprawdzanie pierwszości na gpu. Zarówno pierwsze jak i drugie rozwiązanie komplikuje mi sprawę.

a sprawdzanie pierwszości na gpu??

Cytat: Troll81 w 30 Sierpień 2009, 02:28
a sprawdzanie pierwszości na gpu??

Tak trzeba pewnie będzie zrobić, a zbyt proste to nie będzie  :wth: biorąc pod uwagę, że pewnie wszystkie funkcje będę musiał napisać sam bo jak będzie coś potrzebne to pewnie w ATI Stream tego nie będzie :D, ale przynajmniej w swoim czasie będę mógł wpisać w CV "programowanie kart graficznych ATI Radeon w ATI Stream SDK"  :attack:

Na razie wprowadzę w życie inny pomysł, powinno uciąć 50-90 sec.

Dałem nową wersje 0.2 powinno liczyć trochę szybciej, dodatkowo w nowej wersji dodałem czasomierz wystarczy odpalić start.bat i już się samo wszystko uruchomi, jak się skończy przeliczanie to pojawi się tekst typu "Aby kontynuować naciśnij dowolny klawisz..."

Przed naciśnięciem dowolnego klawisza proszę, odczytać dane: Time GPU, Numbers generation time, Prime test time, oraz Total time.

App 0.2 http://www.speedyshare.com/245349402.html (również link zaktualizowany w 1 poście).

No widze znaczna poprawe. Roznica w stosunku do wersji 0.1 to poprawa o 85 sekund.  :parrrty:

Wyniki poprawne :)

GPU time: 232 sekundy
Numbers generation time: 56 sekund
Prime test time: 133 sekundy
Total time: 426 sekund.

Z niecierpliwoscia czekam na wersje 0.3  :parrrty:

EDIT
Zapomnialem dopisac:

GPU - 32%
CPU - Obciaza tylko jeden rdzen w 80% (ogolnie 20% quada mi obciaza)

GPU time: 210, 399459 sekundy
Numbers generation time: 66, 399459 sekund
Prime test time: 136, 969848 sekundy
Total time: 417, 702246 sekund.

obciążenie
CPU0 - 63-73%
CPU1 - 12%
CPU2 - 15%
CPU3 - 10%
GPU - 43% - mało  :(
10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

GPU time: 104.376681,
Numbers generation time: 37.294324,
Prime test time: 70.462979
Total time: 215.607056

GPU @ 42%
CPU @ 12% (jeden rdzeń na 100%)

10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 8734502163109357
11 366384 6998839830228583
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
10 366384 9684491327954279
10 366384 3267586960583089
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 660669773389609
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
10 366384 13812949836154363
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

Geoff Reynolds umieścił w
http://www.geocities.com/g_w_reynolds/AP26/PrimeQ_gen.zip
procedurę testującą pierwszość przy wykorzystaniu jedynie arytmetyki 64-bitowej. Wygląda, że jest to znacznie lepsze rozwiązanie od tego, które ja proponowałem.

Być może da się to jakoś wsadzić na grafę i tam testować pierwszość.

Poprawności procedury Geoffa nie sprawdzałem, milcząco zakładam, że jest OK.

Myślę, że w razie potrzeby można ją trochę przyspieszyć.

Ach gdyby trochę więcej funkcji było w ATI stream SDK. No trzeba jeszcze sporo zejść z czasem obliczeń testowego zakresu, więc jest co przyśpieszać.

Cytat: Jarek Wróblewski w 03 Wrzesień 2009, 10:06
Geoff Reynolds umieścił w
http://www.geocities.com/g_w_reynolds/AP26/PrimeQ_gen.zip
procedurę testującą pierwszość przy wykorzystaniu jedynie arytmetyki 64-bitowej. Wygląda, że jest to znacznie lepsze rozwiązanie od tego, które ja proponowałem.

Być może da się to jakoś wsadzić na grafę i tam testować pierwszość.

Poprawności procedury Geoffa nie sprawdzałem, milcząco zakładam, że jest OK.

Myślę, że w razie potrzeby można ją trochę przyspieszyć.

Widziałem ta procedurę największy problem to pozbycie się uint64_t q1 = two63/anc; i uint64_t q2 = two63/d; z getMagic. Kombinowałem również testem z Millera-Rabina, ale niestety typ double jest za mały i obcinało mi 3 ostatnie cyfry  w liczbie (http://edu.i-lo.tarnow.pl/inf/alg/001_search/0018.php w tym algorytmie typ ulong zastąpiłem typem double) już przy liczeniu a^b mod n :(

Cytat: sesef w 03 Wrzesień 2009, 11:54
Widziałem ta procedurę największy problem to pozbycie się uint64_t q1 = two63/anc; i uint64_t q2 = two63/d; z getMagic.

To wytłumacz mi, w czym problem. Czy na grafie nie ma dzielenia uint64 ? To jakie operacje są dostępne?

Problem w tym że wiele operacji można wykonać w double ale wynik już jest floatem. Więc albo trzeba pisać samemu funkcje. I tutaj przyda się twój umysł matematyczny w celu skrócenia pewnych obliczeń. Albo czekać na pojawienie sie ATI stream SDK 2.0

Cytat: Jarek Wróblewski w 03 Wrzesień 2009, 12:21

Cytat: sesef w 03 Wrzesień 2009, 11:54
Widziałem ta procedurę największy problem to pozbycie się uint64_t q1 = two63/anc; i uint64_t q2 = two63/d; z getMagic.

To wytłumacz mi, w czym problem. Czy na grafie nie ma dzielenia uint64 ? To jakie operacje są dostępne?

Na kartach ATI nie ma po prostu typu całkowitego 64bit, największy możliwy typ to double który z tego co pamiętam ma 54bity czy coś koło tego. Natomiast dla 32bitowego typu dostępne są wszystkie podstawowe operacje +, - *, /, >>, <<, &, |, ^, ~.

Np z braku obsługi właśnie liczb 64bit trzeba liczyć remainder w ten sposób, do tego dochodzi problem, że jeszcze grafika nie ma obsługi funkcji floor dla typu double (tylko na float liczy, jak się podaje double to konwertuje sobie liczbę na float i dopiero liczy). Jak jest jakaś inna metoda na policzenie % to by się bardzo przydała, przyspieszyłoby to sito :)

Cytatkernel int
Rem(double a, double n)
{
   /*double aa = floor(a / n);
   double db = n * aa;
   double c1 = a - db;*/

   double c1;
   double db;

   double ga = a / n;
   float gp = floor((float)ga);
   double gd = ga - (double)gp;
   int ab = (int)gd;
   double ac = gp + (double)ab;
   //double br = ac - ga;

   if(ac > ga)
   {
      ac -= 1.0;
   }

   db = n * ac;
   c1 = a - db;

   return (int)c1;
}

W pliku

http://www.math.uni.wroc.pl/~jwr/cuda/PrimeQ-2009-09-03.zip

są 2 testy.
test.c jest do uruchomienia na CPU jako wzorzec - powinien drukować to samo, co test31.c:


1 1000000000000000003
2 1000000000000000009
3 1000000000000000031
4 1000000000000000079
5 1000000000000000177
6 1000000000000000183
7 1000000000000000201
8 1000000000000000283
9 1000000000000000381
10 1000000000000000387
11 1000000000000000507
12 1000000000000000523
13 1000000000000000583
14 1000000000000000603
15 1000000000000000619
16 1000000000000000621
17 1000000000000000799
18 1000000000000000841
19 1000000000000000861
20 1000000000000000877
21 1000000000000000913
22 1000000000000000931
23 1000000000000000997
Naciśnij dowolny klawisz, aby kontynuować . . .


Czy wygląda na to, że da radę bez większego bólu uruchomić test31.c na grafie?

Dzielenie two63/d wobec two63=2^31 jest de facto 32-bitowe (dla d>2^31 jest zero, a dla d<2^31 wykonujemy dzielenie 32-bitowe).

przy 32bitowym two63 nie powinno być problemów chyba, że znowu się znajdzie coś o czym w tej chwili nie wiem.

Najpierw jednak muszę na GPU przenieść ify bo jak na razie leżały sobie na CPU, a na GPU tylko sito było liczone. Teraz nastał pewien problem

Cytatfor(b=0;b<64;b++)
{
   if((val>>b)&1)
   {
      ...
   }
}

Przy naszych liczbach ile razy w tej pętli może if okazać się prawdziwy? Wszystkie testy robię dla K=366384 i są przypadki, że przechodzi po 2x, tak jest szansa, że przejdzie tego ifa 3x albo 4x lub więcej?

Sito i PrimeQ to są dwie dość niezależne rzeczy, więc można przetestować na grafie samo PrimeQ - do takiego testu nadaje się test31.c.

Co do sita, to ja nad tym jeszcze poważnie nie myślałem, ale być może da się je inaczej zorganizować.

Jeśli chodzi o cytowanego przez Ciebie if-a, to z grubsza raz na 7500^n pętli będzie prawdziwy n+1 razy.

Lub inaczej:

Pętli w każdym K powinno być ok. 47,000,000.

2 x zdarzy się ok. 18,000 razy w każdej próbce (ok. 6,000 razy w każdym K).

3 x zdarzy się średnio 2.5 raza w każdej próbce (mniej niż raz w każdym K).

4 x zdarzy się średnio raz na 3,000 próbek.

5 x zdarzy się średnio raz na 22,500,000 próbek - zakładając, że AP26 będzie trwać np. 30,000,000 próbek, 5 x w jednej pętli trafi się może raz albo dwa, a szanse na wystąpienie 6x są mniejsze niż 0.02%, czyli na 99.98% 6x się nigdy nie pojawi.

Liczby, które podaję powyżej, mogą nie być dokładne, ale powinny mieć właściwy rząd wielkości - jeśli gdzieś nie popełniłem błędu w obliczeniach, to raczej nie mylę się więcej niż o czynnik 2. Jeśli zliczysz wszystkie pętle dla testowego K oraz pętle z 2x, będziesz wiedział, w którą stronę i o ile się mylę.

Czy ten PrimeQ_gen31 ma działać tylko dla jakiś zakresów konkretnych? W ramach testów dałem n = 37814740008933888LL; co przy pierwszym wykonaniu pętli powinno dać 25 wyraz najnowszego AP25, a jednak liczba nie została uznana za pierwszą, przy oryginalnym PrimeQ_gen poszło bez problemów. W kodzie nic nie zmieniałem, odpaliłem wszystko tak jak było na CPU tylko liczbę dałem inna.

Edit

Sprawdziłem jedną rzecz, zamieniłem to dzielenie całkowite na dzielenie zmiennoprzecinkowe

float q1f = (float)two63 / (float)anc;
float q2f = (float)two63 / (float)d;

Wyniki wystarczy zaokrąglić w dół (tyle GPU potrafi na typach float, więc nie będzie problemów) i jest taki sam jak przy dzieleniach całkowitych.

PrimeQ-gen31 będzie działał dla wszystkich zakresów, jeżeli w linijce:


   } while (p<=122);
   
// instead of 122 take 62+number_of_significant_bits_of_d


dokona się odpowiedniej korekty. W tym celu należy wyznaczyć liczbę bity taką, że
2^(bity-1) < d < 2^bity
a następnie zamiast 122 umieścić 62+bity

Ja na szybko robiłem wersję, która miała sprawdzić, czy to w ogóle pójdzie, więc wpisałem ręcznie liczbę odpowiednią do danych testowych. Liczby w moim teście były 60-bitowe.

Liczba, którą podajesz, jest 56-bitowa, więc dla celu testów możesz zmienić 122 na 118. Ale na poważnie, to trzeba w programie bity wyliczyć w zależności od d.

Cytat: sesef w 04 Wrzesień 2009, 01:12
Sprawdziłem jedną rzecz, zamieniłem to dzielenie całkowite na dzielenie zmiennoprzecinkowe

float q1f = (float)two63 / (float)anc;
float q2f = (float)two63 / (float)d;

Wyniki wystarczy zaokrąglić w dół (tyle GPU potrafi na typach float, więc nie będzie problemów) i jest taki sam jak przy dzieleniach całkowitych.

Ale tu jest wredna pluskiewka. Otóż liczby anc i d na ogół są dość losowe, czyli duże. Ilorazy są stosunkowo małe, więc floaty są zazwyczaj wystarczająco dokładne, aby pamiętać zaokrąglenia (tych małych liczb) w odpowiednia stronę. Boję się, że jeśli anc i d będą małe, wyniki mogą być dość losowe. Będzie też problem, gdy ilorazy będą bardzo bliskie liczbie całkowitej - float nie spamięta wystarczającej dokładności, aby zaokrąglić w odpowiednią stronę. To się zdarzy niesłychanie rzadko, niemniej jednak jest to pluskwa, bo program nie zadziała poprawnie dla wszystkich możliwych danych. Spróbuj wypisać takim programem liczby pierwsze z przedziału 100-200. Boję się, że nie będzie żadnej, bo obliczenia się losowo zwichrują.

Iloraz two63/d może w tej metodzie być błędnie liczony zarówno dla małych d, jak i dla takich d, że two63/d jest prawie całkowite i małe, np. dla d około two63/3, two63/5.

Ponadto nie wykluczam, że PrimeQ-gen31 będzie działać szybciej - dla testów prędkości trzeba zwiększyć przedział testowy, a znalezionych liczb pierwszych nie wypisywać, tylko zliczać. Chociaż najprawdopodobniej różnica prędkości nie będzie zauważalna, bo getMagic zabiera stosunkowo mało czasu w stosunku do całego testu pierwszości.

Teraz zaczynam się zastanawiać jaki sens ma to dzielenie uint64_t q2 = two63/d; skoro d będzie >32bit chyba, że w AP mogą się trafić liczby pierwsze <=32bit

Teoretycznie mogą być wyrazy mniejsze od 2^32, ale nie jest znany żaden AP21 lub dłuższy o wyrazie mniejszym niż 2^32.

Jednak boję się, że mogą być takie wredne d>2^32, dla których to dzielenie przez floaty da zły wynik. Nie ma też specjalnej kontroli nad dzieleniem przez anc.

Chyba najbezpieczniej będzie dopracować wersję z PrimeQ-gen31.

Jak będę miał chwilę czasu, to spróbuję to zrobić i pomyślę o jakichś optymalizacjach.

W katalogu
http://www.math.uni.wroc.pl/~jwr/cuda/PrimeQ_gen/
jest druga wersja PrimeQ_gen31 wraz z programem testującym prędkość.

Jeśli wyśledzisz, że test.c oraz test31v2.c produkują inne wyniki, daj znać - dla wszelkich sensownych danych powinny działać tak samo.

Na oko działają tak samo szybko - superdokładnych testów nie robiłem. W argumencie podajemy liczbę parzystą.

W tym samym katalogu wersja trzecia - powinna być nieco szybsza.

Częściowo już na gpu kod napisałem, funkcja getMagic będzie wyglądać tak:

Cytatvoid getMagic(uint2 d, uint2 *pMagic, uint *pShift)
{
   uint two63 = 0x80000000;

   uint p = 31;          
   uint q2 = 0;
   uint r2 = two63;
   if(d.x == 0)
   {
      q2 = two63/d.y;
      r2 = r2 - q2*d.y;
   }
   uint2 q2a = uint2(0, q2);
   uint2 r2a = uint2(0, r2);
   uint bits = 62;
   uint check = 0;

   if(d.x == 0)
      check = d.y;
   else
   {
      check = d.x;
      bits += 32;
   }

   while (check)
   {
      bits++;
      check >>= 1;
   };
   

   do
   {      
      q2a = ShiftLeft1bit(q2a);
      r2a = ShiftLeft1bit(r2a);

      if(CompareLess(d, r2a))
      {
         r2a = sub(r2a, d);
         q2a = add2(q2a, 1);
      }
      p++;
   } while(p <= bits);


   *pMagic = add2(q2a, 1);

   *pShift = p - 64;
}

uint2 jest to typ wektorowy dostępny na kartach ati składa się po prostu z 2 liczb uint x i y. Jak nie będzie jakiś przeciwności to jutro będzie można już protestować prędkość i popróbować jakiś optymalizacji.

Jak na razie wszystko mam przepisane na GPU, i prawie działa, ale nie do końca. Gdzieś musi być jeszcze błąd bo podaje tylko część wyników

Cytat1000000000000000009
1000000000000000031
1000000000000000079
1000000000000000177
1000000000000000183
1000000000000000201
1000000000000000371
1000000000000000449
1000000000000000491
1000000000000000563
1000000000000000583
1000000000000000695
1000000000000000799
1000000000000000841
1000000000000000913
GPU time: 0.524404
Aby kontynuować, naciśnij dowolny klawisz . . .

Rozumiem, że CPU i GPU dają inne rezultaty.

No to trzeba wyśledzić, gdzie obliczenia CPU i GPU się rozjeżdżają.

Na końcu getMagic trzeba wydrukować *pMagic oraz *pShift

Na końcu mulmod trzeba wydrukować r

Trzeba porównać wyniki drukowane przez CPU i GPU.

getMagic i mulmod nie mają prawa zwracać innych wyników na GPU niż na CPU - obliczenia muszą przebiegać identycznie.

Dla każdej testowanej liczby pierwszej będzie drukowanych kilkadziesiąt liczb, więc trzeba wybrać jedną liczbę, dla której test pierwszości na CPU i GPU wypada inaczej, i uruchomić śledzenie dla tej liczby.

Trochę czasu spędziłem nad tym i jak zwykle szukałem w złym miejscu :(

Okazało się, że ATI ma chyba problem z warunkiem >= w pętli.

w psp2 jest pętla

Cytatfor (i=62;i>=0;i--)

normalnie dla CPU kończy się ona z i = -1 jednak na GPU jest inaczej bo kończy się z i = 0. Przy debugowaniu wszystko było normalnie bo wszystko jest liczone na CPU, a normalny program jak był odpalany na GPU to już był problem z tą pętlą.

Prosta modyfikacja na:

Cytatfor (i=62;i>=-1;i--)

I wszystko pięknie śmiga :) Biorąc pod uwagę, że całe sprawdzanie pierwszości to jakieś 400 linijek kodu to nigdy bym się nie spodziewał, że błąd będzie akurat w tym miejscu.

To zaskakujące, że tak proste elementy, jak ta pętla, nie przenoszą się bezpośrednio na GPU.

Najważniejsze, żeby program produkował poprawne wyniki.

Mam pytanie

Ile liczb procentowo odpada na tych ifach za sitem? Mam problem z implementacją n%x w tych ifach, natomiast w sicie daje poprawne wyniki przy n59%x (pomimo, że do liczenia tego nodulo używam takiego samego kodu i w sicie i ifach). W ifach wynik różni się o +/- 1-2 w 95% przypadków  i teraz nie wiem czy kombinować dalej i jakoś rozwiązać ten problem czy pominąć ify i sprawdzać od razu pierwszość.

W tej chwili nie mam pod ręką środków do wyliczenia procentowo, ile liczb odpada. Jest to sporo (chyba więcej niż połowa), ale nie należy się tym sugerować, bo wykonanie wielu operacji typu n%x też jest kosztowne i wiem z doświadczenia, że prędkość programu prawie nie zależała od liczby ifów na tym etapie (więcej ifów to mniej testowania pierwszości, ale też i więcej grzebania się w ifach, które to grzebanie w ifach częstokroć i tak kończy się testowaniem pierwszości). Ponadto program stosunkowo rzadko przechodzi przez sito.

Liczba n59 jest zawsze mniejsza od 2^48, natomiast samo n może być znacznie większe (2^57 lub w przyszłości nawet więcej) - stąd może się brać niepoprawność dzielenia.

Pominięcie ifów nie jest żadną zbrodnią, więc możesz to zrobić. Program może zwolnić, ale nieznacznie. Biorąc pod uwagę, że musiałbyś robić karkołomne sztuki dla poprawnego zaimplementowania n%x, to może teoretycznie być nawet opłacalne - ale raczej jest bez większego znaczenia.

Pamiętaj jednak, że program będzie wówczas drukował więcej ciągów, więc się nie zdziw, jeżeli plik z wynikami testowymi będzie inny (ma prawo być tylko większy - wszystkie dotychczas znajdowane ciągi muszą się pojawić). Program będzie równoważny w zakresie poszukiwań AP26, natomiast usuniecie ifów może mieć skutek uboczny w postaci nieco większej liczby znajdowanych AP25, AP24, ...

Cytat: Jarek Wróblewski w 13 Październik 2009, 15:41Liczba n59 jest zawsze mniejsza od 2^48, natomiast samo n może być znacznie większe (2^57 lub w przyszłości nawet więcej) - stąd może się brać niepoprawność dzielenia.

To wszystko wyjaśniło, n%x jest liczone przy użyciu liczb double, które poprawność zapewniają do 2^54 dlatego części wyników nie jest niewiele inna.

No to teraz czas zacząć od początku

http://pclab.pl/news38938.html

Z tego co wyczytałem jest pewien plus czyli wsparcie dla 64bit

Skończyłem praktycznie cała aplikacje pod GPU przeniesione zostało sito i sprawdzanie pierwszości. Jak na razie chcę sprawdzić tylko działanie dlatego nie myślałem zbytnio nad optymalizacją kodu, więc jak na razie liczy około 30 min.

Co nowego:
- przeniesione sprawdzanie pierwszości na GPU
- dodana obsługa kart Redeon serii 5k

Download:
www.sesef.pl/AP/AP.0.3.zip

Jak zwykle odpalamy start.bat

Jak wszystko będzie działać poprawnie to będzie można wziąć się za optymalizację i mam nadzieję przyspieszyć ze 100-200x.

Taki wynik powinien się pojawić w SOL-AP26.TXT

Cytat10 366384 1331888331538339
13 366384 13734687267510577
12 366384 5000752284776537
10 366384 6501761426757209
10 366384 13811703175594549
10 366384 8453925410873909
10 366384 8498538171042841
12 366384 1530009333321211
11 366384 14210675573786479
12 366384 594560806287601
10 366384 4875107655944653
11 366384 5950014192294959
10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 14286548534926607
10 366384 5543991933678599
10 366384 8734502163109357
11 366384 7338651716002021
11 366384 2954944439791973
10 366384 4763728136122547
10 366384 4232076310247099
11 366384 6998839830228583
10 366384 1011908406124897
13 366384 1552413910324759
10 366384 12771685429394789
10 366384 2050813916403341
11 366384 12009800853593951
12 366384 7554360526150901
10 366384 2331803599795099
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
12 366384 15794290817181997
10 366384 9684491327954279
10 366384 4623000168789319
11 366384 16540529768597509
10 366384 10578103605691057
10 366384 3267586960583089
11 366384 574232874051989
10 366384 1459178643530617
10 366384 14953937908094447
11 366384 8079412944341597
11 366384 8603691897862783
10 366384 9735298495263823
10 366384 9352581431252833
10 366384 9093893281499471
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 10068049380891851
11 366384 8911943185680817
10 366384 2294967576344473
10 366384 11335914176619833
10 366384 1255892682660361
10 366384 11476274835737807
11 366384 7036595108074969
13 366384 1784605561256887
10 366384 8188609810134857
10 366384 7305170829858437
10 366384 12980626856360411
10 366384 10724748844928731
10 366384 1267829275041547
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
10 366384 5468363059257071
10 366384 14625791300894617
14 366384 15879407069784169
12 366384 362194047736201
11 366384 13998919386172451
10 366384 13065373819344881
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 16672808018696537
13 366384 12554749952945171
13 366384 15237401094993617
10 366384 660669773389609
11 366384 1100393597938247
10 366384 3895923284153731
12 366384 4508932648260331
10 366384 11977568522771779
11 366384 7322837064164717
10 366384 1540799946122147
11 366384 15009234584804179
11 366384 6866441475500933
12 366384 14782924219657043
10 366384 4775675618896643
12 366384 6497689582045349
10 366384 7374851772758473
11 366384 2250720491330359
10 366384 2757477855886981
15 366384 1192586918362261
11 366384 4048151801441081
10 366384 13812949836154363
11 366384 14907737006882729
10 366384 14897048503112591
11 366384 10259604894279193
10 366384 2287269140073173
11 366384 1833028084821499
11 366384 2003229604981763
10 366384 14531182366753699
10 366384 5036419906757977
13 366384 13191542322298957
12 366384 16438041375277853
13 366384 15731878523384263
10 366384 14478118252620437
13 366384 2167218735183577

 :respect: jesteś wielki  :parrrty:

Szacun :respect:

Jak już kupię radzia i appka będzie gotowa to powalczymy z resztą świata %)

Hi

hd4700 xp 32,  przelicza się już z godzinę, podglądając wyniki jest już na 2/3. 
Obciążenie karty zerowe.

No to super !!!  :respect: :respect: :respect: :respect: :respect: :respect: :respect: :respect: :respect: :respect:

Co do optymalizacji, to na podstawie moich wyobrażeń o GPU, przypuszczam, że największym problemem nie będzie optymalizacja samych obliczeń, ale organizacji wątków.

Na CPU program idzie z grubsza tak:
wchodzi w sito, najczęściej dosyć szybko zmienna sito staje się zerem, i przechodzi do następnej pętli. Bardzo rzadko przechodzi przez sito i testuje pierwszość.

Przy jednym wątku nie ma znaczenia, że za każdym razem wchodzimy w sito na inną głębokość, a przez całe sito przechodzimy tylko sporadycznie. Kiedy projektowałem algorytm, nie śniło mi się o obliczeniach na GPU.

Jeśli teraz bezpośrednio przeniesiemy ten algorytm na GPU, to jawi mi się taki scenariusz:

Wątki są wykonywane w paczkach po, bodajże, 16 wątków. Jeśli teraz te 16 wątków wejdzie w sito, to często zdarzy się, że 15 wątków się zakończy (zmienna sito się wyzeruje), ale 16-ty wątek będzie szedł głębiej w sito i może nawet dojdzie do testowania pierwszości. No i jeśli ja dobrze rozumiem działanie GPU, to te 15 wątków będzie czekało bezczynnie aż ten 16-ty skończy swoją robotę.

Prawdopodobnie to będzie wymagało jakiejś reorganizacji. Chociaż oczywiście powyższy czarny scenariusz nie oznacza, że program będzie chodził z 1/16 prędkości - w praktyce często wątki nie będą miały dramatycznej różnicy czasu spędzonego w sicie, ale prognozowanie na ile jest to problemem, to trochę wróżenie z fusów.

Ponadto nie wiem, jak wygląda sprawa operacji 64-bitowych, bo zdaje się, że w GPU większość jednostek wykonuje tylko operacje 32-bitowe, a tych 64-bitowych jest niewiele.

Jaką masz platformę testową? Czy zainstalowanie wszystkiego sprawiało dużo bólu, czy poszło raczej bezproblemowo?

Cytat: Jarek Wróblewski w 26 Październik 2009, 19:38Co do optymalizacji, to na podstawie moich wyobrażeń o GPU, przypuszczam, że największym problemem nie będzie optymalizacja samych obliczeń, ale organizacji wątków.

Wątki organizuje sterownik, ja jedynie zadaję dane i tyle. Wygląda to mniej więcej tak z programu wrzuciłem (znaczy przeniosłem na gpu) pętle i5, i43, i47, i59. Przejście przez te pętle daje listę 1774220 liczb następnie ta lista jest podawana do sita, nie wiem ile wątków jest wykonywanych jednocześnie ale jest to chyba liczba SIMD*16 (każda seria GPU ma inna ilość jednostek SIMD 4750/4770/4830 ma ich 8, 4850/70/90 10, a nowe karty serii 5k odpowiednio 5750 9 jednostek 5770 10, a 5850/70 po 20) na początek z listy pobrane zostanie te SIMD*16 wątków następnie kolejno jak któryś wątek się skończy z listy będzie pobierana kolejna liczba o to wszystko dba sterownik ATI. Jak jakaś liczba nie przejdzie sita to w liście jest zamieniana na 0 i tak jak przejdzie całą listę to trafia to do sprawdzania pierwszości znowu każda liczba z listy trafia do jednego wątku i jest "obrabiana" tylko najpierw jest sprawdzane czy dana liczba nie jest równa 0 jeśli tak to wątek kończy prace i sterownik uruchamia następny z kolejną liczbą, jest to wykonywane w ten sposób ponieważ z poziomu gpu nie mogę stworzyć nowej listy tylko z liczbami które przeszły sito, możliwe jest to z  poziomu CPU jednak musiałbym wtedy ściągnąć dane z GPU wygrzebać z listy interesujące liczby i wysłać z powrotem nową listę na GPU co zajmowałoby za dużo czasu. Jeśli chodzi o otymalizacje to na chwilę obecną to rzeczy z którymi sobie nie dam rady to obliczanie modulo w sicie, w tej chwili jest to liczone przy użyciu typu double w wymyślaną na szybko funkcja round() (GPU nie ma obsługi funkcji round dla liczb double i musiałem sobie sam takie coś napisać)

Liczenie remaindera wygląda tak:

Cytatkernel int
Rem(double a, double n)
{
   /*double aa = floor(a / n);
   double db = n * aa;
   double c1 = a - db;*/

   double c1;
   double db;

   double ga = a / n;
   float gp = floor((float)ga);
   double gd = ga - (double)gp;
   int ab = (int)gd;
   double ac = gp + (double)ab;

   if(ac > ga)
   {
      ac -= 1.0;
   }

   db = n * ac;
   c1 = a - db;

   return (int)c1;
}

Najlepiej byłoby całkowicie pozbyć się tego Remaindera 64bit i zastąpić jakoś liczenie tego elementu tablicy operacją 32bit.

Kolejną sprawą jest samo sito. Zmienna sito jest 64 bitowa więc dla każdego if muszę wykonać 2 operacje & (dla dolnych 32bitów i górnych 32 bitów). Jakby było możliwe wykonanie sita 32 bitowego, zaoszczędziłoby to 50% operacji wykonywanych na sicie.

Cytat: Jarek Wróblewski w 26 Październik 2009, 19:38Wątki są wykonywane w paczkach po, bodajże, 16 wątków. Jeśli teraz te 16 wątków wejdzie w sito, to często zdarzy się, że 15 wątków się zakończy (zmienna sito się wyzeruje), ale 16-ty wątek będzie szedł głębiej w sito i może nawet dojdzie do testowania pierwszości. No i jeśli ja dobrze rozumiem działanie GPU, to te 15 wątków będzie czekało bezczynnie aż ten 16-ty skończy swoją robotę.

Jak już pisałem wcześniej takich problemów nie ma, bo jak któryś wątek się skończy to sterownik pobiera kolejną liczbę z listy i w miejsce zakończonego wątku odpala następny. Opisana sytuacja może wystąpić tylko w momencie kiedy w liście skończą się już liczby i nie będzie danych, żeby uruchomić nowe wątki wtedy program musi czekać aż wszystkie zakończą działanie.

Cytat: Jarek Wróblewski w 26 Październik 2009, 19:38Ponadto nie wiem, jak wygląda sprawa operacji 64-bitowych, bo zdaje się, że w GPU większość jednostek wykonuje tylko operacje 32-bitowe, a tych 64-bitowych jest niewiele.

ATI Stream (w tym piszę program na GPU) udostępnia liczby zmiennoprzecinkowe pojedynczej i podwójnej precyzji (float, double) oraz 8, 16, 32 bitowe liczby całkowite na wszystkich tych typach liczb można wykonywać takie same operacje jak na CPU czyli + - * / i w przypadku liczb całkowitych jeszcze ~, ^, &, |, % << >> (może o czymś zapomniałe, ale są to standardowe operacje dostępne na dzisiejszych CPU), natomiast nie ma obsługi liczb całkowitych 64bit, więc na potrzeby sprawdzania pierwszości musiałem napisać sobie emulację liczby 64bit składającej się z dwóch liczb 32bit i mam do tego operacje + - * >> <<

Natomiast OpenCL oraz CUDA mają programowe wsparcie dla liczb całkowitych 64bit.

Cytat: Jarek Wróblewski w 26 Październik 2009, 19:38Jaką masz platformę testową? Czy zainstalowanie wszystkiego sprawiało dużo bólu, czy poszło raczej bezproblemowo?

Obecnie jest to stary procek Athlon64 3200+ oraz karta graficzna ASUS Formula 4770 wszystko działa bez problemów na WinXP i Windows 7 do linuxa się nie dotykałem. Na chwilę obecną aplikacja powinna bez problemów działać na sterownikach Catalyst 9.2 lub nowszych (zalecam 9.5 albo nawet 9.7 lub nowsze) oraz jakimś systemie windows, żeby nie było problemów ze sterownikami to najlepiej vista albo win7.

Samo odpalenie wszystkiego nie jest problemem, na chwilę obecną większym problemem jest wybór karty ponieważ ze względu na remainder, który jest liczony przy pomocy typu double program może działać tylko na wybranych kartach z tej listy http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSystemRequirements.aspx#cards a mianowicie na kartach z serii 38xx, 47xx, 48xx, 58xx

CAL Runtime: 1.4.427
Found: 1 device(s)

Device 0: ATI Radeon HD5800 series (Cypress) 1024 MB local ram (remote 2047 MB cached + 2047 MB uncached)
GPU core clock: 1004 MHz, memory clock: 300 MHz
Single precision FLOPS: 2891520 Double precision FLOPS: 578304 (GPU supporting double precision)

GPU time: 999.792723, Numbers generation time: 43.440360, Prime test time: 29.530773

Cytat10 366384 1331888331538339
13 366384 13734687267510577
12 366384 5000752284776537
10 366384 6501761426757209
10 366384 13811703175594549
10 366384 8498538171042841
12 366384 1530009333321211
11 366384 14210675573786479
12 366384 594560806287601
10 366384 4875107655944653
11 366384 5950014192294959
10 366384 785436737771879
10 366384 16137071418665303
10 366384 13946622976437587
10 366384 14286548534926607
10 366384 5543991933678599
10 366384 8734502163109357
11 366384 7338651716002021
11 366384 2954944439791973
10 366384 4763728136122547
10 366384 4232076310247099
11 366384 6998839830228583
10 366384 1011908406124897
13 366384 1552413910324759
10 366384 12771685429394789
10 366384 2050813916403341
11 366384 12009800853593951
12 366384 7554360526150901
10 366384 2331803599795099
10 366384 785468127438811
11 366384 5581880890832023
25 366384 6171054912832631
12 366384 15794290817181997
10 366384 9684491327954279
10 366384 4623000168789319
11 366384 16540529768597509
10 366384 10578103605691057
10 366384 3267586960583089
11 366384 574232874051989
10 366384 1459178643530617
10 366384 14953937908094447
11 366384 8079412944341597
11 366384 8603691897862783
10 366384 9735298495263823
10 366384 9352581431252833
10 366384 9093893281499471
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 10613929284401483
10 366384 14083229671187167
11 366384 16518632605478693
11 366384 3007107694524497
10 366384 10068049380891851
11 366384 8911943185680817
10 366384 2294967576344473
10 366384 11335914176619833
10 366384 1255892682660361
10 366384 11476274835737807
11 366384 7036595108074969
13 366384 1784605561256887
10 366384 8188609810134857
10 366384 7305170829858437
10 366384 12980626856360411
10 366384 10724748844928731
10 366384 1267829275041547
10 366384 2411963918614357
11 366384 6569259450263561
10 366384 13700995611657901
10 366384 5468363059257071
10 366384 14625791300894617
14 366384 15879407069784169
12 366384 362194047736201
11 366384 13998919386172451
10 366384 13065373819344881
11 366384 6250872237076277
10 366384 7687488261269507
10 366384 16672808018696537
13 366384 12554749952945171
13 366384 15237401094993617
10 366384 660669773389609
11 366384 1100393597938247
10 366384 3895923284153731
12 366384 4508932648260331
10 366384 11977568522771779
11 366384 7322837064164717
10 366384 1540799946122147
11 366384 15009234584804179
11 366384 6866441475500933
12 366384 14782924219657043
10 366384 4775675618896643
12 366384 6497689582045349
10 366384 7374851772758473
11 366384 2250720491330359
10 366384 2757477855886981
15 366384 1192586918362261
11 366384 4048151801441081
10 366384 13812949836154363
11 366384 14907737006882729
10 366384 14897048503112591
11 366384 10259604894279193
10 366384 2287269140073173
11 366384 1833028084821499
11 366384 2003229604981763
10 366384 14531182366753699
10 366384 5036419906757977
13 366384 13191542322298957
12 366384 16438041375277853
13 366384 15731878523384263
10 366384 14478118252620437
13 366384 2167218735183577

Wątki organizuje sterownik, więc ręcznie mu się nie pomoże, można co najwyżej starać się tak napisać program, aby sterownik się z tymi wątkami nie zapędzał w ślepą uliczkę. Dlatego bardzo trudno cokolwiek tu zrobić.

Jeśli zaś chodzi o optymalizację arytmetyki:

Dzielenia 64-bitowe można zastąpić 32-bitowymi:

W sicie:
http://www.math.uni.wroc.pl/~jwr/AP26/faster32.zip

Po sicie (to zdaje się usunąłeś z programu, ale możesz próbować przywrócić i sprawdzić, czy się opłaca):
http://www.math.uni.wroc.pl/~jwr/AP26/if32.zip

Sorry, ja chyba w porę nie zrozumiałem, że Ty musisz się aż tak strasznie męczyć, aby robić to dzielenie, i nie skojarzyłem, żeby Ci wskazać te pliki.

Co do 32-bitowego sita, to:

1. Można to zrobić.

2. Gotowca, jak to zrobić, do podesłania nie mam.

3. Byłyby pewne problemy z kompatybilnością z dotychczasową wersją. Otóż zakres obliczeń byłby 2 razy węższy, więc trzeba byłoby np. zamiast starym programem z sitem 64-bitowym liczyć SHIFT=64, przy sicie 32-bitowym liczyć SHIFT=64 oraz SHIFT=96. Tu byłyby pewne kłopotu z organizacją checkpointów - wszystko do obejścia, ale wymagałoby jakiejś dziubaniny.

4. Sito jest 64-bitowe, bo taki był maksymalny rozmiar liczb całkowitych na komputerze, na którym projektowałem algorytm. Próbowałem kiedyś zrobić sito 128-bitowe, ale to tylko spowolniło program. Zapewne sito 64-bitowe jest najlepsze na 64-bitowym CPU. Natomiast nie wiem, czy na GPU będzie szybsze sito 32-, czy 64-bitowe. I tego się nie dowiemy przed napisaniem i uruchomieniem programu.

W wolnej chwili zrobię łatę, która zamienia sito 64-bit na 32-bit. Teoretycznie zmiana sita z 64 na 32 może mieć pozytywny wpływ na organizację wątków przez sterownik - to jest zbyt skomplikowane, aby próbować to sobie wyobrazić i przewidzieć. 32-bitowe sito oznacza, że głębokość wchodzenia poszczególnych wątków w sito będzie mniej zróżnicowana. Ale w sumie puszczając program 2 razy wykona się więcej operacji. Trudno przewidywać jaki będzie efekt.

Cytat: Jarek Wróblewski w 27 Październik 2009, 06:12Jeśli zaś chodzi o optymalizację arytmetyki:

Dzielenia 64-bitowe można zastąpić 32-bitowymi:

W sicie:
http://www.math.uni.wroc.pl/~jwr/AP26/faster32.zip

Po sicie (to zdaje się usunąłeś z programu, ale możesz próbować przywrócić i sprawdzić, czy się opłaca):
http://www.math.uni.wroc.pl/~jwr/AP26/if32.zip

Widziałem już wcześniej te pliki tylko nie zauważyłem, że wynik tych obliczeń jest 32bitowy. Wprowadzenie tego 32bitowego dzielenia wyeliminuje wszelkie obliczenia na typie double co niesie za sobą obsługę wszystkich kart, a nie tylko tych wybranych które mają wsparcie dla double precision.

Dodatkowo do mnożenia w sprawdzaniu pierwszości zastosuję algorytm Karatsuby powinno to przyspieszyć cały program.

Jak na razie po drobnych zmianach udało się uzyskać przyspieszenie około 5-7%.

Zrobiłem pomiary dla testowego zakresu w kodzie zmieniłem 2 wartości pętli, aby zakres był mniejszy

Cytatfor(i31=0;i31<1;++i31)
for(i37=0;i37<1;++i37)

Na gpu ten zakres jest liczony w 2,829649 sekundy, natomiast ściągnięcie danych z gpu trwa 12,780028 sekundy gdzie niestety 99% danych nie jest istotnych i teraz muszę opanować jakoś ten czas ściągania danych jakby dało się go zmniejszyć 5-6x to praktycznie jakiekolwiek zmiany w sicie nie byłby potrzebne.

Cytat: sesef w 27 Październik 2009, 21:11
Widziałem już wcześniej te pliki tylko nie zauważyłem, że wynik tych obliczeń jest 32bitowy. Wprowadzenie tego 32bitowego dzielenia wyeliminuje wszelkie obliczenia na typie double co niesie za sobą obsługę wszystkich kart, a nie tylko tych wybranych które mają wsparcie dla double precision.

Zwracam uwagę, że:
w pliku rep32-1a.h w linijkach:

n59a=n59&((1<<30)-1);
n59b=n59>>30;

w pliku rep32-2a.h w linijce:

if(sito&=OKOK101[((n59a=n59&((1<<30)-1))+17*(n59b=n59>>30))%101])

w pliku if32.h w linijkach:

na=((int)n)&((1<<29)-1);
nb=((int)(n>>29))&((1<<17)-1);
nc=((int)(n>>46));

następuje przesiadka obliczeń z 64 bitów na 32, to znaczy zmienne n59 oraz n są 64-bitowe, natomiast n59a, n59b, na, nb, nc 32-bitowe.

Przy na, nb, nc pamiętałem, aby wpisać wyraźnie mapowanie typów (int), a przy n59a i n59b to samo mapowanie odbywa się przy podstawieniu (bo akurat nie pamiętałem, aby dla przejrzystości je wpisać).

n59 ma w praktyce 48 bitów, do n59a dajemy dolnych 30, a pozostałych 18 do n59b.

Z kolei n jest 64-bitowa i dzielimy ją od dołu na kawałki mające odpowiednio 29, 17 i 18 bitów.

tyle z tego pojąłem że jest szansa na obsługę mojego radka 3650 :D

Ja nic nie pojąłem  ;D

Chyba udało mi się bez potrzeby przepisywania programu wyeliminować te czasy ściągania danych z gpu, jednak jest pewien mankament teoretycznie może wystąpić sytuacja gdzie w badanej paczce danych na karcie wystąpią dwa lub więcej AP (na kartę do przetworzenia za każdym razem leci paczka 1774220 liczb) w takim wypadku zostanie zwrócony ten o większej ilości wyrazów. Biorąc pod uwagę rzadkość występowania AP nie przypuszczam, żeby w jednej paczce danych pojawił się AP24 i AP25 więc pewnie ten problem nie wystąpi, a program po tych zmianach powinien spokojnie przyspieszyć o jakieś 30-40%.

a co jak się pojawi ap25 i ap26?

Znalezienie AP jest na tyle rzadkie, że można taką WU potraktować resentem z usunięciem tego zwycięskiego wariantu.

Można nawet po prostu zignorować problem, a dokonać weryfikacji ręcznie. AP24 jest znajdowane średnio raz na tydzień. No więc można przy każdym znalezionym AP24 (lub dłuższym) przeliczyć na CPU całą próbkę lub jej odpowiedni fragment. Rozwiązanie toporne, ale skuteczne.

Skoro AP24 jest znajdowane średnio raz na ok. 100,000 próbek, to dwa AP24 zejdą się w jednej próbce średnio raz na 100,000 tygodni, czyli 2000 lat. O wiele częściej zdarzyć się mogą niewykryte błędy z powodu przegrzania lub przypadkowych cząsteczek alfa uderzających w komórki pamięci.

No więc to naprawdę nie jest problem, a w każdym razie nie opłaca się go rozwiązywać kosztem zauważalnego spowolnienia programu.

A... jak rozumiem, próbka zawiera ponad 2000 paczek, więc 2 AP24 znajdą się w jednej paczce średnio raz na 4,000,000 lat (liczonego na obecny przerób całego projektu - na pojedynczym komputerze to by było raz na 1,000,000,000 lat).

Dużo zdrowia wszystkim życzę  :)

Jeśli dobrze rozumiem, to na CPU wyliczasz liczby n59 i je przesyłasz do GPU. Czy tak? No to chyba z tego powodu CPU ma dużo roboty i jest dużo danych do przesyłu CPU->GPU.

Te pętle wyliczające kolejne n59 przy użyciu prostych operacji to było bardzo wydajne rozwiązanie na CPU, ale filozofia działania GPU jest zupełnie inna. Z programem w obecnej postaci nic innego nie zrobisz. Postaram się pomyśleć, czy te pętle można jakoś prosto rozebrać i przenieść na GPU - żeby to miało sens, musiałoby być przepisane na operacje 32-bitowe w nie za dużej ilości..

CytatA... jak rozumiem, próbka zawiera ponad 2000 paczek, więc 2 AP24 znajdą się w jednej paczce średnio raz na 4,000,000 lat (liczonego na obecny przerób całego projektu - na pojedynczym komputerze to by było raz na 1,000,000,000 lat).

Jak znam praktykę to szansa jedna na milion przydarza się w 9 przypadkach na 10 :D

Cytat: Jarek Wróblewski w 30 Październik 2009, 07:38Jeśli dobrze rozumiem, to na CPU wyliczasz liczby n59 i je przesyłasz do GPU. Czy tak? No to chyba z tego powodu CPU ma dużo roboty i jest dużo danych do przesyłu CPU->GPU.

Tak wyliczam 1774220 kolejnych liczb n59 czyli pętle od i5 do i59. Obecnie znajdują się one na CPU, jednak mam przygotowany kod dla GPU którego zapomniałem umieścić w obecnej wersji programu, znajdzie się w następnej chociaż nie należy do najwydajniejszych.

Tak wygląda kod pojedynczego wątku do generowania liczb:

Cytatkernel void
numGen(uchar4 pos<>, uchar pos5<>, double n[],
      double s43, double s47, double s53, double s59,
      out double o<>)
{
   double n43, n47, n53, n59;
   int i43, i47, i53, i59;
   int k = 0;   

   k = pos5;
   n43 = n[k];
   /////////////////////////////// W
   for(i43 = 19; i43 > pos.w; i43--)
   {
      n43 += s43;
      if(n43 >= 258559632607830.0)
         n43 -= 258559632607830.0;
   }

   //////////////////////////////// Z
   n47=n43;
   for(i47 = 23; i47 > pos.z; i47--)
   {
      n47 += s47;
      if(n47 >= 258559632607830.0)
         n47 -= 258559632607830.0;
   }

   //////////////////////////////// Y
   n53 = n47;
   for(i53 = 29; i53 > pos.y; i53--)
   {
      n53 += s53;
      if(n53 >= 258559632607830.0)
         n53 -= 258559632607830.0;
   }

   //////////////////////////////// X
   n59 = n53;
   for(i59 = 35; i59 > pos.x; i59--)
   {
      if(i59>1)
      {
         n59 += s59;
         if(n59 >= 258559632607830.0)
            n59 -= 258559632607830.0;
      }
   }

   o = n59;   
}

gdzie pos<> to miejsca w których mają się zakończyć pętle (i43-i59), n[] są to wartości n43 dla danej paczki danych, każda paczka zawiera ich tyle ile będzie wykonań pętli i5 czyli 4, pos5 to pozycja w tablicy n[] dla każdego wątku, s43-s59 stałe, i o<> to jest tablica wyjściowa, do której trafiają wszystkie wygenerowane liczby.

Teraz jak mogę wyeliminować z liczenia sita liczby double to przy generowaniu liczb też zastąpię je operacjami na liczbach całkowitych. Obecnie największym problemem jest to, że ważna jest tylko ostatnia iteracja każdej pętli, i wszystkie poprzednie w każdym wątku się dublują, dla przykładu 1 wątek musi wykonać 1 iterację drugi wątek musi wykonać już 2 zaczynając od początku ponieważ nie zna miejsca, ani wartości na jakich skończył wątek pierwszy (chociaż pomimo takiego nadkładu pracy jest szybciej niż na CPU)

Cytat: sesef w 31 Październik 2009, 22:53
Obecnie największym problemem jest to, że ważna jest tylko ostatnia iteracja każdej pętli, i wszystkie poprzednie w każdym wątku się dublują, dla przykładu 1 wątek musi wykonać 1 iterację drugi wątek musi wykonać już 2 zaczynając od początku ponieważ nie zna miejsca, ani wartości na jakich skończył wątek pierwszy (chociaż pomimo takiego nadkładu pracy jest szybciej niż na CPU)

Te pętle były po to, aby używać prostych operacji na CPU. Przekładanie pętli w obecnej postaci na GPU musi być bardzo niewydajne. Ale w tej chwili nie mam gotowego rozwiązania jak to obejść.

Zrobiłem trochę pomiarów i wychodzi na to, że przeliczenie sita dla całego K zajmuje około 90-100 sec (przy GPU obciążonym na ~50%) natomiast sprawdzanie pierwszości dla całego K zajmuje około 1100 sekund co jest żałośnie niskim wynikiem w porównaniu do sita. Tak się zastanawiam nad przerobieniem trochę mulmoda bo np po pierwszym wywołaniu mulmod zwraca wynik 1 (oraz w kilku kolejnych wywołaniach), więc większość tych mnożeń można by zrobić przy pomocy mnożenia 32bit zamiast 64bit/128bit, tylko teraz moje pytanie czy zawsze tak jest, czy może trafiłem na taki przypadek, że akurat te kilka początkowych wyników jest 32bit.

Tak, z procedury testowania pierwszości można wywalić kilka początkowych wykonań mulmoda, ale to nie ma szansy przyspieszyć programu o więcej niż 10%. Myślę jednak, że nie ma sensu teraz komplikować programu taką przeróbką, dopóki rząd wielkości czasu działania jest nie do przyjęcia.

Obawiam się, że może być tak, że wątki są pakowane w paczki po, powiedzmy, 16. Z takiej paczki przez sito przejdzie najwyżej jeden wątek. I wtedy ten wątek sobie testuje pierwszość, a pozostałe 15 czeka na niego.

Daj namiar na kod źródłowy, zobaczę, czy jestem w stanie sobie wyobrazić, co się tam dzieje.

Cytat: Jarek Wróblewski w 05 Listopad 2009, 20:46Obawiam się, że może być tak, że wątki są pakowane w paczki po, powiedzmy, 16. Z takiej paczki przez sito przejdzie najwyżej jeden wątek. I wtedy ten wątek sobie testuje pierwszość, a pozostałe 15 czeka na niego.

Z tego co czytałem, wygląda to chyba jednak trochę inaczej. GPU dobiera sobie działania w paczki po 64 sztuki np 64 dodawania potem 64 mnożenia itp przy sicie nie ma z tym problemu bo tam praktycznie tylko sam iloczyn bitowy więc ładnie to leci, problem jest właśnie przy mulmodzie gdzie jest mieszanina dodawania, mnożenia i przesunięć bitowych. Spróbuje mnożenie 128 bit albo całego mulmoda napisać tak, żeby poukładać najbardziej jak się da w paczki te działania.

Jak na razie dodałem część ifów z oryginalnego programu (dodanie kolejnych skutkowało tylko wydłużeniem czasu działania programu, zamiast jego zmniejszeniem) oraz kilka tweaków do samego sprawdzania pierwszości co w rezultacie dało przyspieszenie z 18 sekund na niecałe 12 sek.

30% to niezła optymalizacja kodu :D

mam pewne pytanie do osb programujących
nasza firma dystrybuuje wewnętrzną gazetkę piszącą o roznych pierdolach
ostatni numer traktuje o przetwarzaniu rownoleglum, rozproszonym itp - miedzy innymi o narzędziach do automatycznej paralelizacji kodu
jest ktoś zainteresowany??

wyrumuniłbym tę gazetkę w sztukach iluśtam i rozesłał do zainteresowanych.......

I wszystko się wyjaśniło, problemem nie jest sprawdzanie pierwszości, które nawet ładnie sobie radzi tylko końcowa funkcja redukująca całą paczkę danych do jednej wartości (w ten sposób eliminowałem czas ściągania danych z gpu tylko o zgrozo dla 1,7 kk liczb taki kernel redukujący zajmuje ca 4,5 sekundy gdzie ściągnięcie tych danych z GPU w najgorszym przypadku jak pokazały pomiary to jest jakieś 2 sekundy.

Ja się nie odzywałem, bo żadnych mądrych sugestii po przejrzeniu Twojego kodu nie miałem  :(

Natomiast obserwując dyskusję na PrimeGridzie, co się dzieje z CUDA-mi na AP26, widzę, że tu jest też trochę problemu z podpięciem gotowego programu pod BOINC, żeby na każdej sensownej konfiguracji GPU/CPU/OS to chodziło bez większych problemów.

Wiem też, że mfl0p optymalizując AP26 pod różne CPU/OS przepisał po swojemu spore kawałki kodu i wgryzł się w detale algorytmu. No więc można  zakładać, że z AP26 na CUDAch pod względem optymalizacyjno-programistycznym wyciśnięto z grubsza tyle, ile się da. Czy jesteś w stanie oszacować, jaka jest prędkość Twojego programu w stosunku do tego, co teraz PrimeGrid puszcza na CUDAch?

Na chwilę obecną wygląda to tak:

GPU time: 57.004280, Data download: 436.561012, Prime test time: 0.005724

Problemem jest ściąganie danych z GPU, samo przeliczanie idzie w miarę szybko chociaż kod nie ma jakiś wyrafinowanych optymalizacji. Jak uda mi się pozbyć tego czasu ściągania danych albo chociaż zmniejszyć go 10x to już będzie całkiem nieźle.

ogólnie śmiesznie to wygląda ściągnięcie danych po skończeniu sita 0.7 sekundy po sprawdzaniu pierwszości 5 sekund, niby ramu powinno na karcie wystarcza i teraz nie wiem co się sypie. Pogrzebie trochę, może będzie dało rado to jakoś zmniejszyć.

Właśnie skończyłem wersję 0.4, liczy już na tyle szybko, że liczenie na GPU stało się opłacalne chociaż nie będzie takich ilości pkt jak za milkę.

Obecnie czas w sekundach wygląda tak (plik stderr.txt)

PrimeTest time: 19.511147 Total time: 115.975238 (to jest czas na jednej liczby K, w normalnym WU w PG takich liczba K jest 9)
Nie jestem zorientowany w czasach aplikacji CUDA, ale z tego co kiedyś liczyłem powinno być szybciej.

Jak wszystko będzie stabilnie działać, to dorobie Checkpointy i będzie można startować do BOINC.

Link do wersji 0.4: www.sesef.pl/AP/AP04.zip

Cytat: sesef w 17 Styczeń 2010, 18:16Link do wersji 0.4: www.sesef.pl/AP/ap04.zip

Ten link coś nie ten teges...

już poprawiłem :)

Ok, poszło.
Zużywało to połowę rdzenia CPU, średnie obciążenie GPU ok. 37% (CC i milka obciążają GPU na ponad 90%)
Karta: Sapphire HD4850 1GB Ram VAPOR-X
Sterowniki: 9.12
OS: WinXP 64

SOL-AP26.TXT:
11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577

stderr.txt:
Can't open init data file - running in standalone mode
AP26 Search 0.4 adapted for ATI GPU by Sebastian Jaworowicz
Code by Jaroslaw Wroblewski

CAL Runtime: 1.4.515
Found: 1 device(s)

Device 0: ATI Radeon HD 4700/4800 (RV740/RV770) 1024 MB local ram (remote 64 MB  cached + 1024 MB uncached)
GPU core clock: 650 MHz, memory clock: 1000 MHz
Single precision FLOPS: 1040000 Double precision FLOPS: 208000 (GPU supporting double precision)

Starting WU (K= 366384 - 366384 shift 0) on GPU 0
PrimeTest time: 59.162008 Total time: 223.302118
called boinc_finish



na konsoli
E:\BOINC\Power Apps\AP>AP26.exe 366384 366384 0 -device 0
[0] GPU time: 12.647305
NumList size: 21180
[1] GPU time: 1.111696
NumList size: 41192
[2] GPU time: 1.079766
NumList size: 61800
[3] GPU time: 1.082015
NumList size: 81944
[4] GPU time: 1.106002
NumList size: 102669
[5] GPU time: 1.056725
NumList size: 122071
[6] GPU time: 1.155293
NumList size: 143888
[7] GPU time: 1.049795
NumList size: 163715
[8] GPU time: 1.079961
NumList size: 182692
[9] GPU time: 1.148877
NumList size: 201803
[10] GPU time: 1.042534
NumList size: 221640
[11] GPU time: 0.000000
NumList size: 221640
[12] GPU time: 0.000000
NumList size: 221640
[13] GPU time: 1.081759
NumList size: 241167
[14] GPU time: 1.214453
NumList size: 262303
[15] GPU time: 1.146143
NumList size: 283504
[16] GPU time: 1.126834
NumList size: 303781
[17] GPU time: 1.187920
NumList size: 325167
[18] GPU time: 1.122701
NumList size: 345858
[19] GPU time: 1.089979
NumList size: 366872
[20] GPU time: 1.140614
NumList size: 387773
[21] GPU time: 1.248369
NumList size: 408053
[22] GPU time: 1.321643
NumList size: 429231
[23] GPU time: 1.297286
NumList size: 449912
[24] GPU time: 1.223155
NumList size: 469923
[25] GPU time: 0.000000
NumList size: 469923
[26] GPU time: 1.222711
NumList size: 489464
[27] GPU time: 1.270657
NumList size: 510298
[28] GPU time: 1.321403
NumList size: 532236
[29] GPU time: 1.332019
NumList size: 554639
[30] GPU time: 1.363226
NumList size: 577693
[31] GPU time: 1.582205
NumList size: 601541
[32] GPU time: 1.298439
NumList size: 622866
[33] GPU time: 1.268509
NumList size: 644152
[34] GPU time: 1.398845
NumList size: 671347
[35] GPU time: 1.824710
NumList size: 695471
[36] GPU time: 1.382409
NumList size: 718201
[37] GPU time: 1.261642
NumList size: 739154
[38] GPU time: 1.193848
NumList size: 758183
[39] GPU time: 1.152869
NumList size: 777107
[40] GPU time: 1.260739
NumList size: 796893
[41] GPU time: 1.351867
NumList size: 818988
[42] GPU time: 1.370915
NumList size: 841632
[43] GPU time: 1.342457
NumList size: 864995
[44] GPU time: 1.367870
NumList size: 887417
[45] GPU time: 1.321557
NumList size: 909408
[46] GPU time: 1.256888
NumList size: 930439
[47] GPU time: 1.388172
NumList size: 951749
[48] GPU time: 1.236212
NumList size: 977849
[49] GPU time: 1.344767
NumList size: 999502
[50] GPU time: 1.298303
NumList size: 1019712
[51] GPU time: 1.124478
NumList size: 1038374
[52] GPU time: 1.178805
NumList size: 1058637
[53] GPU time: 1.227926
NumList size: 1080045
[54] GPU time: 1.303551
NumList size: 1106422
[55] GPU time: 1.358447
NumList size: 1127900
[56] GPU time: 1.344007
NumList size: 1149814
[57] GPU time: 1.350732
NumList size: 1171844
[58] GPU time: 1.327648
NumList size: 1193002
[59] GPU time: 1.326787
NumList size: 1214381
[60] GPU time: 1.261160
NumList size: 1235150
[61] GPU time: 1.329276
NumList size: 1257300
[62] GPU time: 1.319852
NumList size: 1279163
[63] GPU time: 1.239560
NumList size: 1299695
[64] GPU time: 1.202681
NumList size: 1319142
[65] GPU time: 0.000000
NumList size: 1319142
[66] GPU time: 1.203411
NumList size: 1338003
[67] GPU time: 1.244715
NumList size: 1358491
[68] GPU time: 1.220791
NumList size: 1378601
[69] GPU time: 1.279803
NumList size: 1398866
[70] GPU time: 1.157864
NumList size: 1419101
[71] GPU time: 1.266026
NumList size: 1439676
[72] GPU time: 1.252813
NumList size: 1459854
[73] GPU time: 1.289362
NumList size: 1483449
[74] GPU time: 1.309787
NumList size: 1505003
[75] GPU time: 1.327758
NumList size: 1525598
[76] GPU time: 1.269453
NumList size: 1545818
[77] GPU time: 1.111103
NumList size: 1564734
[78] GPU time: 0.000000
NumList size: 1564734
[79] GPU time: 0.000000
NumList size: 1564734
[80] GPU time: 1.192162
NumList size: 1584004
[81] GPU time: 1.260084
NumList size: 1604546
[82] GPU time: 1.089157
NumList size: 1622790
[83] GPU time: 1.245433
NumList size: 1642368
[84] GPU time: 1.207480
NumList size: 1661109
[85] GPU time: 1.211070
NumList size: 1680378
[86] GPU time: 1.202938
NumList size: 1699409
[87] GPU time: 1.140247
NumList size: 1717966
[88] GPU time: 1.230652
NumList size: 1736658
[89] GPU time: 1.075784
NumList size: 1755349
[90] GPU time: 1.168272
NumList size: 1774643

4870 win7x64

Can't open init data file - running in standalone mode
AP26 Search 0.4 adapted for ATI GPU by Sebastian Jaworowicz
Code by Jaroslaw Wroblewski

CAL Runtime: 1.4.467
Found: 1 device(s)

Device 0: ATI Radeon HD 4700/4800 (RV740/RV770) 512 MB local ram (remote 1855 MB  cached + 1855 MB uncached)
GPU core clock: 770 MHz, memory clock: 900 MHz
Single precision FLOPS: 1232000 Double precision FLOPS: 246400 (GPU supporting double precision)

Starting WU (K= 366384 - 366384 shift 0) on GPU 0
PrimeTest time: 71.764784 Total time: 145.760992
called boinc_finish



11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 1574579779396307
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
11 366384 2003229604981763
10 366384 14531182366753699
13 366384 15731878523384263
13 366384 2167218735183577



<app_init_data>
<major_version>0</major_version>
<minor_version>0</minor_version>
<release>0</release>
<app_version>0</app_version>
<slot>0</slot>
<wu_cpu_time>0.000000</wu_cpu_time>
<user_total_credit>0.000000</user_total_credit>
<user_expavg_credit>0.000000</user_expavg_credit>
<host_total_credit>0.000000</host_total_credit>
<host_expavg_credit>0.000000</host_expavg_credit>
<resource_share_fraction>0.000000</resource_share_fraction>
<checkpoint_period>300.000000</checkpoint_period>
<fraction_done_start>0.000000</fraction_done_start>
<fraction_done_end>0.000000</fraction_done_end>
<rsc_fpops_est>0.000000</rsc_fpops_est>
<rsc_fpops_bound>0.000000</rsc_fpops_bound>
<rsc_memory_bound>0.000000</rsc_memory_bound>
<rsc_disk_bound>0.000000</rsc_disk_bound>
<computation_deadline>0.000000</computation_deadline>
<host_info>
    <timezone>0</timezone>
    <domain_name></domain_name>
    <ip_addr></ip_addr>
    <host_cpid></host_cpid>
    <p_ncpus>0</p_ncpus>
    <p_vendor></p_vendor>
    <p_model></p_model>
    <p_features></p_features>
    <p_fpops>0.000000</p_fpops>
    <p_iops>0.000000</p_iops>
    <p_membw>0.000000</p_membw>
    <p_calculated>0.000000</p_calculated>
    <m_nbytes>0.000000</m_nbytes>
    <m_cache>0.000000</m_cache>
    <m_swap>0.000000</m_swap>
    <d_total>0.000000</d_total>
    <d_free>0.000000</d_free>
    <os_name></os_name>
    <os_version></os_version>
</host_info>
<proxy_info>
    <socks_version>0</socks_version>
    <socks_server_name></socks_server_name>
    <socks_server_port>0</socks_server_port>
    <http_server_name></http_server_name>
    <http_server_port>0</http_server_port>
    <socks5_user_name></socks5_user_name>
    <socks5_user_passwd></socks5_user_passwd>
    <http_user_name></http_user_name>
    <http_user_passwd></http_user_passwd>
    <no_proxy></no_proxy>
</proxy_info>
<global_preferences>
   <source_project></source_project>
   <mod_time>0.000000</mod_time>
   <run_on_batteries>0</run_on_batteries>
   <run_if_user_active>0</run_if_user_active>
   <run_gpu_if_user_active>0</run_gpu_if_user_active>
   <suspend_if_no_recent_input>0.000000</suspend_if_no_recent_input>
   <start_hour>0.000000</start_hour>
   <end_hour>0.000000</end_hour>
   <net_start_hour>0.000000</net_start_hour>
   <net_end_hour>0.000000</net_end_hour>
   <leave_apps_in_memory>0</leave_apps_in_memory>
   <confirm_before_connecting>0</confirm_before_connecting>
   <hangup_if_dialed>0</hangup_if_dialed>
   <dont_verify_images>0</dont_verify_images>
   <work_buf_min_days>0.000000</work_buf_min_days>
   <work_buf_additional_days>0.000000</work_buf_additional_days>
   <max_ncpus_pct>0.000000</max_ncpus_pct>
   <cpu_scheduling_period_minutes>0.000000</cpu_scheduling_period_minutes>
   <disk_interval>0.000000</disk_interval>
   <disk_max_used_gb>0.000000</disk_max_used_gb>
   <disk_max_used_pct>0.000000</disk_max_used_pct>
   <disk_min_free_gb>0.000000</disk_min_free_gb>
   <vm_max_used_pct>0.000000</vm_max_used_pct>
   <ram_max_used_busy_pct>0.000000</ram_max_used_busy_pct>
   <ram_max_used_idle_pct>0.000000</ram_max_used_idle_pct>
   <idle_time_to_run>0.000000</idle_time_to_run>
   <max_bytes_sec_up>0.000000</max_bytes_sec_up>
   <max_bytes_sec_down>0.000000</max_bytes_sec_down>
   <cpu_usage_limit>0.000000</cpu_usage_limit>
</global_preferences>
</app_init_data>


 :respect: sesef

Kolejna wersja, kilka poprawek kilka % szybciej.

www.sesef.pl/AP/AP042.zip

I kolejne wyniki:

Karta: 4850
OS: WinXP64

Obciążenie GPU: 40-45% wg RivaTuner, jest postęp, ale jest też dużo miejsca na poprawę ;)
(rivatuner pokazuje mi obciążenie GPU ok. 20-25%, kiedy nic poza windowsem się nie liczy na GPU, nie wiem czy to normalne)
Obciążenie 1 rdzenia CPU: 40-50%

Porównując Totaltime, to jest to więcej niż kilka procent  :parrrty:

stderr.txtCan't open init data file - running in standalone mode
AP26 Search 0.4.2 adapted for ATI GPU by Sebastian Jaworowicz
Code by Jaroslaw Wroblewski

CAL Runtime: 1.4.515
Found: 1 device(s)

Device 0: ATI Radeon HD 4700/4800 (RV740/RV770) 1024 MB local ram (remote 64 MB  cached + 1024 MB uncached)
GPU core clock: 650 MHz, memory clock: 1000 MHz
Single precision FLOPS: 1040000 Double precision FLOPS: 208000 (GPU supporting double precision)

Starting WU (K= 366384 - 366384 shift 0) on GPU 0
PrimeTest time: 22.355025  [K=366384]
Total time: 171.210608
called boinc_finish


SOL-AP26.TXT11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
13 366384 2167218735183577


stdout[0] GPU time: 20.068729
NumList size: 9028
[1] GPU time: 1.312739
NumList size: 15763
[2] GPU time: 1.351717
NumList size: 23120
[3] GPU time: 1.279822
NumList size: 31461
[4] GPU time: 1.337044
NumList size: 40902
[5] GPU time: 1.264171
NumList size: 48854
[6] GPU time: 1.284298
NumList size: 59773
[7] GPU time: 1.405604
NumList size: 70270
[8] GPU time: 1.346994
NumList size: 79677
[9] GPU time: 1.332832
NumList size: 86924
[10] GPU time: 1.302259
NumList size: 93690
[11] GPU time: 0.000000
NumList size: 93690
[12] GPU time: 0.000000
NumList size: 93690
[13] GPU time: 1.327918
NumList size: 99662
[14] GPU time: 1.450732
NumList size: 106947
[15] GPU time: 1.434462
NumList size: 116700
[16] GPU time: 1.513092
NumList size: 128792
[17] GPU time: 1.467436
NumList size: 136135
[18] GPU time: 1.387802
NumList size: 145019
[19] GPU time: 1.341416
NumList size: 154060
[20] GPU time: 1.383248
NumList size: 165424
[21] GPU time: 1.435767
NumList size: 173840
[22] GPU time: 1.451290
NumList size: 182107
[23] GPU time: 1.389316
NumList size: 189811
[24] GPU time: 1.272623
NumList size: 196824
[25] GPU time: 0.000000
NumList size: 196824
[26] GPU time: 1.280333
NumList size: 203898
[27] GPU time: 1.404469
NumList size: 211331
[28] GPU time: 1.481024
NumList size: 218205
[29] GPU time: 1.509315
NumList size: 226667
[30] GPU time: 1.480370
NumList size: 235206
[31] GPU time: 1.457903
NumList size: 243998
[32] GPU time: 1.462377
NumList size: 250427
[33] GPU time: 1.477515
NumList size: 258464
[34] GPU time: 1.388923
NumList size: 268433
[35] GPU time: 1.495816
NumList size: 276783
[36] GPU time: 1.490359
NumList size: 286229
[37] GPU time: 1.455648
NumList size: 293760
[38] GPU time: 1.290453
NumList size: 302359
[39] GPU time: 1.290042
NumList size: 308678
[40] GPU time: 1.362920
NumList size: 317152
[41] GPU time: 1.577131
NumList size: 326840
[42] GPU time: 1.477082
NumList size: 332706
[43] GPU time: 1.430428
NumList size: 341215
[44] GPU time: 1.481268
NumList size: 349111
[45] GPU time: 1.518159
NumList size: 356348
[46] GPU time: 1.460254
NumList size: 362525
[47] GPU time: 1.492533
NumList size: 370084
[48] GPU time: 1.496155
NumList size: 379791
[49] GPU time: 2.264996
NumList size: 390001
[50] GPU time: 1.723957
NumList size: 400241
[51] GPU time: 1.635873
NumList size: 409861
[52] GPU time: 1.579765
NumList size: 418960
[53] GPU time: 1.404149
NumList size: 427819
[54] GPU time: 1.495340
NumList size: 434831
[55] GPU time: 1.487992
NumList size: 442769
[56] GPU time: 1.480676
NumList size: 451882
[57] GPU time: 1.470553
NumList size: 460173
[58] GPU time: 1.482329
NumList size: 467959
[59] GPU time: 1.468039
NumList size: 475533
[60] GPU time: 1.512973
NumList size: 482979
[61] GPU time: 1.725257
NumList size: 494264
[62] GPU time: 1.508734
NumList size: 501838
[63] GPU time: 1.408805
NumList size: 508552
[64] GPU time: 1.442520
NumList size: 520880
[65] GPU time: 0.000000
NumList size: 520880
[66] GPU time: 1.651005
NumList size: 530498
[67] GPU time: 1.526321
NumList size: 542510
[68] GPU time: 1.374614
NumList size: 552700
[69] GPU time: 1.417716
NumList size: 559878
[70] GPU time: 1.376208
NumList size: 568094
[71] GPU time: 1.279688
NumList size: 577847
[72] GPU time: 1.029864
NumList size: 587169
[73] GPU time: 1.031307
NumList size: 596053
[74] GPU time: 1.029597
NumList size: 605780
[75] GPU time: 1.373714
NumList size: 613614
[76] GPU time: 1.430095
NumList size: 621559
[77] GPU time: 1.293600
NumList size: 628811
[78] GPU time: 0.000000
NumList size: 628811
[79] GPU time: 0.000000
NumList size: 628811
[80] GPU time: 1.319468
NumList size: 636342
[81] GPU time: 1.281513
NumList size: 643705
[82] GPU time: 1.274741
NumList size: 650690
[83] GPU time: 1.328654
NumList size: 657134
[84] GPU time: 1.302470
NumList size: 664270
[85] GPU time: 1.312868
NumList size: 670504
[86] GPU time: 1.289840
NumList size: 678343
[87] GPU time: 1.313102
NumList size: 683956
[88] GPU time: 1.290551
NumList size: 690012
[89] GPU time: 1.328269
NumList size: 696008
[90] GPU time: 1.305902
NumList size: 701885
Total time: 171.210608


4870-512 770/900 Win7x64

Can't open init data file - running in standalone mode
AP26 Search 0.4.2 adapted for ATI GPU by Sebastian Jaworowicz
Code by Jaroslaw Wroblewski

CAL Runtime: 1.4.515
Found: 1 device(s)

Device 0: ATI Radeon HD 4700/4800 (RV740/RV770) 512 MB local ram (remote 1855 MB  cached + 1855 MB uncached)
GPU core clock: 770 MHz, memory clock: 900 MHz
Single precision FLOPS: 1232000 Double precision FLOPS: 246400 (GPU supporting double precision)

Starting WU (K= 366384 - 366384 shift 0) on GPU 0
PrimeTest time: 43.658013  [K=366384]
Total time: 107.825508
called boinc_finish



11 366384 6998839830228583
10 366384 785468127438811
25 366384 6171054912832631
10 366384 1459178643530617
10 366384 9735298495263823
10 366384 1727805601738891
10 366384 2138118918508471
11 366384 3007107694524497
10 366384 1255892682660361
11 366384 7036595108074969
10 366384 8188609810134857
10 366384 2411963918614357
10 366384 13700995611657901
14 366384 15879407069784169
11 366384 6250872237076277
10 366384 11977568522771779
10 366384 1540799946122147
12 366384 14782924219657043
13 366384 2167218735183577


W pierwszym poście nowa wersja 0.4.5

Checkpointy i ogólnie kilka usprawnień nic więcej jak na razie.

I kolejna seria wyników:

WinXP 64, radeon 4850
Catalyst 9.12

Obciążenie CPU: 50% rdzenia
Obciążenie GPU: ok. 45%

Keep up the good work!  :respect:

pojawił się AP26-checkpoint.txt366385 366384 0

stderr.txtCan't open init data file - running in standalone mode
AP26 Search 0.4.5 adapted for ATI GPU by Sebastian Jaworowicz
Code by Jaroslaw Wroblewski

CAL Runtime: 1.4.515
Found: 1 device(s)

Device 0: ATI Radeon HD 4700/4800 (RV740/RV770) 1024 MB local ram (remote 64 MB  cached + 1024 MB uncached)
GPU core clock: 650 MHz, memory clock: 1000 MHz
Single precision FLOPS: 1040000 Double precision FLOPS: 208000 (GPU supporting double precision)

Starting WU (K= 366384 - 366384 shift 0) on GPU 0
PrimeTest time: 25.862614  [K=366384]
Total time: 166.524785
called boinc_finish

konsola[0] GPU time: 17.842999
NumList size: 7923
[1] GPU time: 1.196776
NumList size: 15338
[2] GPU time: 1.176018
NumList size: 24043
[3] GPU time: 1.143830
NumList size: 31031
[4] GPU time: 1.259845
NumList size: 40382
[5] GPU time: 1.090101
NumList size: 50972
[6] GPU time: 1.152581
NumList size: 58258
[7] GPU time: 1.112349
NumList size: 65925
[8] GPU time: 1.187573
NumList size: 74091
[9] GPU time: 1.198023
NumList size: 84345
[10] GPU time: 1.148534
NumList size: 96492
[11] GPU time: 0.000000
NumList size: 96492
[12] GPU time: 0.000000
NumList size: 96492
[13] GPU time: 1.198203
NumList size: 106145
[14] GPU time: 1.246668
NumList size: 115650
[15] GPU time: 1.351193
NumList size: 126969
[16] GPU time: 1.391201
NumList size: 139023
[17] GPU time: 1.197625
NumList size: 149246
[18] GPU time: 1.275139
NumList size: 158266
[19] GPU time: 1.224576
NumList size: 172084
[20] GPU time: 1.232327
NumList size: 180764
[21] GPU time: 1.150238
NumList size: 193066
[22] GPU time: 1.112735
NumList size: 204981
[23] GPU time: 1.182096
NumList size: 213292
[24] GPU time: 1.164259
NumList size: 222298
[25] GPU time: 0.000000
NumList size: 222298
[26] GPU time: 1.227753
NumList size: 231618
[27] GPU time: 1.349585
NumList size: 239912
[28] GPU time: 1.465378
NumList size: 247198
[29] GPU time: 1.368686
NumList size: 255154
[30] GPU time: 1.304912
NumList size: 265704
[31] GPU time: 1.240864
NumList size: 276293
[32] GPU time: 1.254209
NumList size: 288109
[33] GPU time: 1.286089
NumList size: 299465
[34] GPU time: 1.246655
NumList size: 309840
[35] GPU time: 1.291687
NumList size: 319135
[36] GPU time: 1.366284
NumList size: 328300
[37] GPU time: 1.265670
NumList size: 335982
[38] GPU time: 1.095159
NumList size: 345409
[39] GPU time: 1.066127
NumList size: 355397
[40] GPU time: 1.183204
NumList size: 364819
[41] GPU time: 1.273312
NumList size: 374803
[42] GPU time: 1.256183
NumList size: 383695
[43] GPU time: 1.283695
NumList size: 396427
[44] GPU time: 1.366941
NumList size: 404438
[45] GPU time: 1.322882
NumList size: 415817
[46] GPU time: 1.401468
NumList size: 426227
[47] GPU time: 1.294616
NumList size: 436961
[48] GPU time: 1.434847
NumList size: 446744
[49] GPU time: 1.355176
NumList size: 457645
[50] GPU time: 1.258984
NumList size: 467374
[51] GPU time: 1.145543
NumList size: 477066
[52] GPU time: 1.138615
NumList size: 486575
[53] GPU time: 1.281832
NumList size: 498735
[54] GPU time: 1.355874
NumList size: 509733
[55] GPU time: 1.300981
NumList size: 518781
[56] GPU time: 1.206671
NumList size: 531398
[57] GPU time: 1.368564
NumList size: 539199
[58] GPU time: 1.302702
NumList size: 549329
[59] GPU time: 1.341813
NumList size: 559533
[60] GPU time: 1.305289
NumList size: 571127
[61] GPU time: 1.291756
NumList size: 580751
[62] GPU time: 1.339288
NumList size: 591368
[63] GPU time: 1.299526
NumList size: 600840
[64] GPU time: 1.195361
NumList size: 612301
[65] GPU time: 0.000000
NumList size: 612301
[66] GPU time: 1.187748
NumList size: 621869
[67] GPU time: 1.216270
NumList size: 633087
[68] GPU time: 1.180253
NumList size: 645241
[69] GPU time: 1.212625
NumList size: 657839
[70] GPU time: 1.238645
NumList size: 670585
[71] GPU time: 1.387419
NumList size: 677782
[72] GPU time: 1.263928
NumList size: 690649
[73] GPU time: 1.184490
NumList size: 701943
[74] GPU time: 1.245418
NumList size: 709875
[75] GPU time: 1.350996
NumList size: 717577
[76] GPU time: 1.158592
NumList size: 730547
[77] GPU time: 1.143802
NumList size: 740243
[78] GPU time: 0.000000
NumList size: 740243
[79] GPU time: 0.000000
NumList size: 740243
[80] GPU time: 1.097088
NumList size: 750912
[81] GPU time: 1.142611
NumList size: 759204
[82] GPU time: 1.213463
NumList size: 768469
[83] GPU time: 1.271039
NumList size: 776561
[84] GPU time: 1.237324
NumList size: 784373
[85] GPU time: 1.230634
NumList size: 792468
[86] GPU time: 1.023276
NumList size: 803364
[87] GPU time: 1.080883
NumList size: 811589
[88] GPU time: 1.078839
NumList size: 821337
[89] GPU time: 1.169427
NumList size: 828438
[90] GPU time: 1.277135
NumList size: 835730
Total time: 166.524785


W pierwszym poście wersja finalna, działająca z BOINC.

Progress bar działa, checkpointy są wszystko ładnie liczy WU sa validowane.

UWAGA program wypluwa różne wyniki dla różnych typów kart. Wyniki dla odpowiedniej serii kart podane w pierwszym poście.

Aplikacja działa  ;D na karcie 5850 czas obliczenia wynosi około 700 sekund
A teraz pytanie do mądrych ludzi czy istnieje możliwość liczenia AP26 jednocześnie na procu i na karcie ATI

Cytat: Piotr Rakowski w 26 Styczeń 2010, 12:53
Aplikacja działa  ;D na karcie 5850 czas obliczenia wynosi około 700 sekund
A teraz pytanie do mądrych ludzi czy istnieje możliwość liczenia AP26 jednocześnie na procu i na karcie ATI

Na chwile obecną nie. Trochę długo jak na 700 sekund, jaki masz load gpu?

A te wszystkie klienty TJM owe i FreeHALowe ?

42-45 % ale liczą się jednocześnie 4 inne zadania na CPU
sterowniki 9.12 nie hotfix

Cytat: Piotr Rakowski w 26 Styczeń 2010, 13:34
A te wszystkie klienty TJM owe i FreeHALowe ?

42-45 % ale liczą się jednocześnie 4 inne zadania na CPU

Możesz spróbować dać w app_info.xml

<count>1</count>

na
<count>0.5</count>

A po wgraniu sterowników jakie kazał wgrać mądry sesef i przy zwolnieniu jednego rdzenia tylko do AP26GPU czas .....370 sek - czyli niezły dopalacz  :attack:
a jak ustawimy próbki 0.5 GPU i 1 CPU to dwie próbki przelicza sie w czasie 644 sek  :attack:  :attack:
Fajna aplikacja dla dwujajecznych  ::)
Teraz na wyścigach właściciele procków dwujajecznych z systemem 32 mogą pokazać czterojajecznym z systemem 64 - figę  XD

HI

Coś robię chyba żle.

Wgrywam to wszystko z katalogu AP26 PG do katalogu projektu. Odpalam boinca i dostaję komunikat:

No work sent , No work available for the applications you have selected.

a masz zaznaczone że ma chodzić na cpu ?

Hi

tak,  tylko cpu,

ja zrobiłem tak wrzuciłem rozpakowana aplikacje sesefa, usunąłem aplikacje domyślną, zatrzymałem milke i collo,  zamknąłem Boinc, zaktualizowałem Bionc i działa

Cytat: ksysju w 26 Styczeń 2010, 17:34
HI

Coś robię chyba żle.

Wgrywam to wszystko z katalogu AP26 PG do katalogu projektu. Odpalam boinca i dostaję komunikat:

No work sent , No work available for the applications you have selected.

A tylko AP liczysz?

procek 4 jajka
liczę 2x inna aplikacja na CPU i 2 x AP26GPU
ale faktycznie przy starcie wstrzymałem dosłownie wszystko inne

Hi

Robię jak Piotr R.
Zatrzymuję cała resztę.  Próbowałem na 2 maszynach  i to samo.

Cytat: ksysju w 26 Styczeń 2010, 19:53
Hi

Robię jak Piotr R.
Zatrzymuję cała resztę.  Próbowałem na 2 maszynach  i to samo.

Z tego co widzę, u mnie też ten komunikat się pojawia:

Cytat2010-01-26 20:54:01   PrimeGrid   Requesting new tasks for CPU
2010-01-26 20:54:07   PrimeGrid   Scheduler request completed: got 0 new tasks
2010-01-26 20:54:07   PrimeGrid   Message from server: No work sent
2010-01-26 20:54:07   PrimeGrid   Message from server: No work available for the applications you have selected.  Please check your settings on the web site.

Jednak próbki pobiera. Manager 6.10.24

W pierwszym poście wersja 0.4.6.1

- Poprawiony bug z progressbarem
- Zmieniłem bibliotekę odpowiedzialną za sprawdzanie pierwszości wcześniej było to czyste GMP teraz zastosowałem bibliotekę opartą na GMP, która nazywa sie MPIR (http://www.mpir.org/) z tego co się chwalą w najnowszej wersji przyspieszyli sprawdzanie pierwszości co właśnie ma swoje skutki w programie. U mnie przyspiesza o 2 sekundy, na innych kompach może być więcej.

Witam

oki doki  :) ruszyło

Wyczyściłem bufor z milky, przegrałem najnowszą aplikację od sesef'a i zassało wu.

Komp ma 2xhd4770  liczy po 2 wu, każde wu poniżej 700s.

jak z dojnością w stosunku do milki?  %)

Pigu no nie żartuj, 1 do 20

http://www.boincatpoland.org/smf/boinc/lista-projektow-wedlug-'dojnosci'/msg89115/#msg89115

Z moich doświadczeń wynika że aplikacja AP26 GPU nie chodzi w BOINC 6.10.36. Nie pobiera zadań, cały dzień cuda wianki na kiju, modlitwy i te sprawy odstawiałem Dopiero jak zainstalowałem BOINC 6.10.18 to wszystko wróciło do normy. Po zainstalowaniu sterowników 10.3 opłaca się liczyć 0.5 GPU i 0.5 CPU - najwydajniej. Przedtem najwydajniej było 1 CPU i 1 GPU. Dziwna sprawa.