Dogrzewamy mieszkanie czyli AP26 na ATI Radeon

[sesef]

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ść.

[Jarek Wróblewski]

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, ...

[sesef]

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.

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.

[sesef]

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

[sesef]

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

10 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

[Troll81]

 :respect: jesteś wielki  :parrrty:

[Szopler]

Szacun :respect:

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

[ksysju]

Hi

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

[Jarek Wróblewski]

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?

[sesef]

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.

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:

kernel 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.

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ę.

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.

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.

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.

Jaką 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

[Raptor77]

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

10 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

[Jarek Wróblewski]

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.

[sesef]

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

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

for(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.

[Jarek Wróblewski]

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.

[Troll81]

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

[Peciak]

Ja nic nie pojąłem  ;D

[sesef]

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%.

[Troll81]

a co jak się pojawi ap25 i ap26?

[X X X]

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

[Jarek Wróblewski]

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.

[Jarek Wróblewski]

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..

[Troll81]

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).

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

[sesef]

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.

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:

kernel 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)

[Jarek Wróblewski]

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ść.

[sesef]

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.

[Jarek Wróblewski]

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.

[sesef]

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.

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.

[Troll81]

30% to niezła optymalizacja kodu :D

[Troll81]

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.......

[sesef]

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.

[Jarek Wróblewski]

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?

[sesef]

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ć.

[sesef]

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

[apohawk]

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

Ten link coś nie ten teges...

[sesef]

już poprawiłem :)

[apohawk]

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:

Kod [Zaznacz] Rozwiń


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:

Kod [Zaznacz] Rozwiń


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

Kod [Zaznacz] Rozwiń


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

[[PBT] Horpah]

4870 win7x64

Kod [Zaznacz] Rozwiń


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


Kod [Zaznacz] Rozwiń


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


Kod [Zaznacz] Rozwiń


<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>


[Troll81]

 :respect: sesef

[sesef]

Kolejna wersja, kilka poprawek kilka % szybciej.

www.sesef.pl/AP/AP042.zip

[apohawk]

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.txt

Kod [Zaznacz] Rozwiń

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) 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.TXT

Kod [Zaznacz] Rozwiń

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


stdout

Kod [Zaznacz] Rozwiń

[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