BOINC@Poland

Takiego mam pomysła, a nawet trzy.

W pliku PrimeQ64.h zamiast 2 linijek

       PTR(n)[0] = value;
       SIZ(n) =1;

dać 1 linijkę

mpz_set_ui(n,value);

Jeżeli to nie zadziała, spróbować zamiast powyższych 2 linijek dać 4 linijki

mpz_set_ui(n,(unsigned int)(value>>32));
mpz_mul_ui(n,n,1<<16);
mpz_mul_ui(n,n,1<<16);
mpz_add_ui(n,n,(unsigned int)(value^((1LL<<32)-1));

To drugie rozwiązanie ma szansę działać także na 32 bitach, gdyby tam były problemy.

Można też spróbować na 64 bitach kompilować PrimeQ32.h. Jeżeli ten gmp nie jest w pełni dostosowany do 64 bitów i używa słów 32-bitowych, to to ma szansę pójść.

Jeśli coś zadziała, to ustawienia z 7-ką dadzą masę rozwiązań, a powrót do 15-tki da to, co ma być.

Wszystko jest OK oprócz testowania pierwszości liczb powyżej 2^32.

Zapewne szwankuje konwersja long long value -> mpz_t n w procedurze PrimeQ z pliku PrimeQ64.h.

Zara pomyślimy jak to obejść...

Jeszcze można w AP19-64.c po

    out = fopen("SOL-AP15.TXT", "a");
    fprintf(out,"%d %d %lld\n",AP_Length,difference,First_Term);

dodać

    printf("%d %d %d\n",AP_Length,difference,(int)First_Term);

i obserwować, co się pojawi na ekranie.

Teoretycznie mogło się coś skopać z obliczeniami przy kompilacji. Mam nadzieję, że Prime32.h/Prime64.h jest dobrane odpowiednio do wersji, bo kompilator się nie poskarży, a program będzie liczył głupoty.

Gdyby skompilować wersję testową zmieniając w AP19.h linia 134

if(k>=10)
na
if(k>=7)

oraz w AP19-64.c linia 32

  if(AP_Length>=15){
na
  if(AP_Length>=7){

to nawet program, który liczy głupoty, powinien coś wpisać do pliku z wynikami, jeśli się go uruchomi w zakresie 1-1000. Z tego, co wpisze być może mógłbym spróbować zgadnąć, w czym problem.

Kolejne dwa zadanka w katalogu
http://www.math.uni.wroc.pl/~jwr/BaP/
pliki Ap20.zip oraz Ap21.zip
Na razie starczy, zobaczymy, co jesteście w stanie z tego wydusić.

Programy niewiele różnią się od pierwszego, więc powinny sie podobnie zachowywać. W/g mojej oceny z tych trzech zadań największe szanse na rekord daje AP20. Jednak liczby pierwsze są tak nieprzewidywalne, że trudno coś prognozować.

Cytat: sesef w 04 Styczeń 2009, 04:59
Myślałem również nad własna implementacja testu pierwszości, z tego co się doczytałem GMP korzysta z testu Millera-Rabina jadnak taka aplikacja będzie pewnie wolniejsza niż kompilowane z GMP.

Podejrzewam, że w tym konkretnym programie testowanie pierwszości jest wykonywane na tyle rzadko, że jego wydajność nie jest zbyt istotna. Myślę jednak, że nie ma sensu tracić energii na prowizoryczne rozwiązania, które w przyszłości nie wystarczą. Myślę, że na dłuższą metę bez GMP się nie obejdzie. W wielu programach, jakie mam w planie na przyszłość, trzeba operować na liczbach 128-bitowych i testować pierwszość liczb 128-bitowych. Trudno też każdy program pisać w 2 wersjach: z GMP i bez GMP.

Tak więc z punktu widzenia inwestycji w przyszłość dobrze byłoby, żeby ktoś kto ma nerwy do wepchnięcia GMP w Windowsowy kompilator, utorował drogę kolejnym programom.

Po dokładnym przejrzeniu kodu stwierdzam, że w obecnej wersji powinien działać poprawnie tylko do 1757658938, czyli troszkę mniej niż 2^31, ale poza tym, że nie należy przekraczać tej granicy, to nie ma istotnego znaczenia.

Myślę, że po ewentualnym znalezieniu rozwiązania AP19, należy kontynuować do powyższej wartości licząc na lepsze AP19 lub na AP20.

Cytat: emik w 03 Styczeń 2009, 16:49
T5500@1660 aplikacja 64bity zakres 1-10000 - 91sekund
T5500@1660 aplikacja 32bity zakres 1-10000 - 90sekund
czasy zbliżone ale był mały zakres danych, więc trzeba by powtórzyć na większym obszarze

To w zupełności wystarczy, żeby stwierdzić, że na 32 i 64 bitach działa tak samo szybko. W zasadzie test kilkusekundowy już by wystarczył. Jak się zastanowiłem, to chyba wiem dlaczego tak może być. Otóż w tym programie zamiast dzielenia liczb 64-bitowych jest dzielenie 32-bitowe, a to chyba najbardziej żarłoczna operacja z tego programu.

To jednak sytuacja wyjątkowa, w większości tego typu programów nie da się uniknąć dzielenia 64-bitowego.

Inna sprawa, że T5500 jest procesorem nowszej generacji niż stare 32-bitówki i wcale nie jest powiedziane, że na nich też tak fajnie to pójdzie. Ale dramatycznej różnicy być nie powinno.

******

Po prostu tu nie ma mądrych na przewidywanie prędkości działania. Dopiero testy konkretnego programu pokazują jak jest naprawdę.

Wygrzebałem ze starego pliku następujące paskudztwo:

*************

typedef unsigned int __attribute__ ((mode(TI))) uint128;

long long PowerMod(long long r, long long e, long long p)
{
        uint128 a;
        if(e==1) {return r;}
        else
        if(e==0) {return 1;}
        else
        if(e%2==0)
        {a=PowerMod(r,e/2,p); return (a*a)%p;}
        else
        a=PowerMod(r,e/2,p);
        a=(a*a)%p;
        return (r*a)%p;
};

int PrimeQ(long long p)
{
        return (2==PowerMod(2,p,p))?1:0;
};

**************

Pierwsza linijka w jakiś tajemniczy sposób pod 64-bitowym linuxem definiuje liczby 128-bitowe (kolega mi to pokazał, często działa, a często wysypuje kompilator gcc4 i trzeba używać gcc3). Nieważne. W każdym razie, jeśli mamy liczby 128-bitowe, to reszta nadaje się do testowania pierwszości - teoretycznie może to uznać liczbę złożoną za pierwszą, ale zdarza się to na tyle rzadko, że nie zakłóca programu. Dobrego rozwiązania nie pominie, a jak przepuści jakąś lipę, to się ją odsieje przy ręcznej weryfikacji.

W każdym razie jak nie mamy gmp, a mamy liczby 128-bitowe, to jest OK.

Cytat: sesef w 03 Styczeń 2009, 17:13
Któryś z Linuxowców albo Pan Jarek mógłby mnie oświecić i powiedzieć jakie przedziały liczbowe dostarcza biblioteka GMP, może zamiast męczyć się z portem znalazła by się jakaś biblioteka co oferuje takie przedziały pod windows.

gmp jest potrzebne do zdefiniowania procedury

int PrimeQ(long long value)

która testuje, czy liczba 64-bitowa jest pierwsza (wartość procedury różna od 0) czy złożona (procedura ma dawać 0). Procedura ta jest zdefiniowana w PrimeQ32.h i PrimeQ64.h. Poza tym gmp nie jest używane.

Można się obejść bez gmp, ale trzeba mieć własną procedurę testująca pierwszość liczb 64-bitowych i wstawić ją do PrimeQ. Nie wiem, czy to łatwiejsze.

Wolałbym żebyście sami sobie rozdzielali przedziały. Na początek chyba wystarczą posty w stylu: Biorę xM-yM. Myślę, że nie ma sensu przeszukiwania tego samego przedziału przez więcej niż 1 osobę.

@AiDec

1. Na Athlonie 64 3000 1K szło mi w 8-9 sekund. Najlepiej zapuścić sobie testowo jakiś krótki przedział i zmierzyć prędkość. Przy dalszych zakresach może trochę spowalniać, ale chyba nie za bardzo - to wszystko jest do przetestowania. Przy tej prędkości 10mln=24h, ale inny procesor może łatwo wyrabiać ze 2 razy więcej na każdy rdzeń. Trzeba sobie samemu zmierzyć prędkość i oszacować.

2. Ja się na tym nie znam, sądzę, że polecenia, których używam, powinny się z grubsza przenosić. Pod Windowsem może być problem z drukowaniem liczb większych niż 2^32, ale ten konkretny program tego nie robi. Zawsze najlepiej zapuścić testowy przedział i zobaczyć jak działa.

3. Teoretycznie nie dalej niż do 2^31-1, można dalej, ale trzeba byłoby zmienić typ liczb w programie.  W zasadzie to się decyduje w trakcie poszukiwań. Jak się znajdzie rozwiązanie, to można iść dalej, licząc na lepsze, albo sobie odpuścić.

4. Pod 1 rdzeń. Na 4 rdzeniach odpalamy 4 skrypty w różnych katalogach roboczych.

5. Nie testowałem, ale wydaje mi się, że też. W zasadzie program jest tego samego typu, więc i ten aspekt powinien wyglądać podobnie.

Jak program będzie skompilowany, z ustawieniem przedziału nie powinno być problemu. Ja tego pod Windowsem kompilować nie umiem, trzeba mieć gmp. Jak ktoś umie, niech podpowie, bo ten problem będzie przy każdym programie. Ponadto trzeba chyba wywalić z AP19-64.c linuxowe czasomierze, czyli całą definicję microtime() i wszystkie linijki zawierające "time", to może zależeć od kompilatora.

Z kompilacją musicie sobie zrobić jakąś wzajemną samopomoc, bo ja umiem kompilować tylko u siebie na kompilatorze, który w systemie linuxowym jest utrzymywany przez administratorów sieci.

W teorii przedział [x,y] ustawiamy uruchamiając program z linii poleceń
ap19.exe x y
jeśli będzie skompilowany do ap19.exe albo wpisując do pliku AP19-ini.txt linijkę postaci
x y
i uruchamiając program w tym samym katalogu, co ten plik.

Np. na pierwszy test czy chodzi można dać
1 1000
i wtedy w SOL-AP15.TXT powinno się znaleźć
15 65 598396207
15 140 229480759

Pierwsze zadanko znajduje się w katalogu
http://www.math.uni.wroc.pl/~jwr/BaP/
plik AP19.ZIP

Ja się nie znam na BOINC. Mogę dostarczyć procedurę wykonującą obliczenia. Można ją łatwo odpalać na pojedynczym kompie albo podzielić pracę na wiele maszynek.

Z całą pewnością można to zaadaptować do BOINC (w końcu PrimeGrid to zrobił z podobnym programem), ale ja tego nie umiem i nie zrobię. Żeby nie było wątpliwości, program dzieli się w łatwy sposób na niezależne segmenty, więc nie ma problemu z rozdzieleniem pracy na wiele komputerów, które nie muszą się ze sobą komunikować. Wystarczy rozdzielić pracę i zebrać wyniki.

Wyobraźmy sobie, że ma być wykonana Procedura(n) dla n=1,2,3,...,1000000.

Można na jednym kompie odpalić
for(n=1;n<=1000000;n++)Procedura(n);
albo na milionie kompów na raz odpowiednio
Procedura(1);
Procedura(2);
Procedura(3);
...
Procedura(1000000);

Napisanie Procedury to mój problem. Do Was należałoby rozdzielenie pracy i zebranie wyników.

Cytat: jurdziol w 03 Styczeń 2009, 12:37
Raczej pan Jarek by dostarczyl tylko procedure, ktora bedzie obliczac a 'ktos' by musial przygotowac reszte, czyli oprogramowanie projektu, podzial zadan itp.

Tak właśnie. Przy czym w wersji próbnej do pomyślenia jest także ręczne rozdzielanie zadań, np. widziałem, że PrimeGrid ręcznie rozdziela przedziały sita, po prostu użytkownicy na forum zgłaszają, który przedział biorą. No ale docelowo wygodniejszy pewnie byłby jakiś system - to oczywiście zależy od możliwości technicznych.

******

Po zastanowieniu: wydaje mi się wręcz, że pierwszy tego typu program powinien być rozdzielany ręcznie przez umawianie się co do przedziałów obliczeń np. na forum w stosunkowo wąskim gronie testerów. Dopiero potem można ewentualnie myśleć o czymś poważniejszym. Pytanie podstawowe: czy jesteście zainteresowani taką zabawą?

Ja swoje algorytmy rozwiązujące różne zagadnienia matematyczne tworzę w pewnym sensie w izolacji, tzn. trudno mi znaleźć kogoś, kto byłby skłonny ze mną w tej materii współpracować. OK, nic na to nie poradzę, pogodziłem się, że jestem tu skazany sam na siebie.

Jeśli chodzi o uruchamianie programów, to jest lepiej, ale niewiele. W ostatnim czasie współpracę zaoferował mi Raanan Chermoni oraz PrimeGrid. Poza tym jestem skazany na samotną zabawę komputerami dostępnymi w pracowniach studenckich, na których programy uruchamiam dość prymitywnie, tzn. za pomocą skryptów odpalanych ręcznie.

Czuję pewien niedosyt, że nie udało mi się wciągnąć do współpracy więcej osób, zwłaszcza z Polski.

Nie wiem na ile jest to sensowne, ale chodzi mi po głowie następujący pomysł. Na stronie
http://hjem.get2net.dk/jka/math/aprecords.htm
odnotowującej rekordy związane z postępami arytmetycznymi liczb pierwszych, jest jeszcze parę rekordów, których pobicie nie powinno być zbyt trudne. Myślę, że byłbym w stanie wyprodukować program, który dawałby spore szanse na wpisanie się na listę rekordzistów, np. Smallest AP-k with minimal start k=19,20,21,22. Gdyby było takie zainteresowanie, chętnie przekazałbym w użytkowanie taki program BOINC@Poland. Ja umiem zrobić tylko procedurę liczącą, ale nawet przy braku systemu podziału zadań można ją odpalać ręcznie umawiając się kto bierze jaki przedział parametrów. Proszę spojrzeć na
http://hjem.get2net.dk/jka/math/simultprime.htm
gdzie część wyników została uzyskana przez zorganizowane projekty. W tabeli rekordów wymieniane są: nazwisko odkrywcy (czyli właściciela komputera), nazwa projektu oraz nazwa użytego programu.

Z takich poszukiwań pewnie nie byłoby punktów w różnych klasyfikacjach, ale byłaby spora szansa na wpis do tabeli rekordów. Może w ten sposób dałoby się przyciągnąć do projektu nowych użytkowników i spopularyzować ideę tego typu poszukiwań.

Jeśli ten pomysł wydaje się sensowny, jestem gotów rozpocząć przygotowania odpowiedniego programu.

To może ktoś kto jednocześnie zna angielski i rozumie mechanizmy tego całego interesu zgłosi to do PrimeGrid-u.
Ja wspomniałem na ich forum o problemie z pobieraniem WU, ale nie umiem tego precyzyjnie wyjaśnić, bo się na tym nie znam.

Z tego co się zorientowałem z postów na forum PrimeGrid-u, WU są tworzone przez połączenie trzech kolejnych liczb k. Te k, które są podzielne przez liczbę pierwszą z przedziału 29-59, są pomijane przez program, ale oni je chyba wkładają bez sprawdzenia do WU. Wydaje się, że oni nie odsiali WU, które zawierają 3 takie k, przynajmniej w początkowej fazie, nie wiem jak jest teraz. W każdym razie takie WU powodują błędy, na forum PrimeGrid-u jest parę zgłoszeń tego typu. Być może takie wiszące WU, których może być kilkadziesiąt, powodują problemy. Odnoszę wrażenie, że różne kłopoty mogą być spowodowane tym, że to wczesna faza podprojektu i nie wszystkie takie problemy zostały rozpoznane i usunięte.

Cytat: kempler w 02 Styczeń 2009, 09:32
Mam do Pana takie pytanie. Czy można umieścić Pana imię,  nazwisko i stopień naukowy w naszej wiki ? Chciałbym umieścić te informacje w opisie tego projektu.

Jak najbardziej, będę zaszczycony. Jestem doktorem matematyki, habilitacji nie mam i nie planuję. Pewnie w oficjalnym dokumencie powinienem występować jako Jarosław.

Cytat: TJM w 02 Styczeń 2009, 09:08
Czy Primegrid pozwala używać własnych, zoptymalizowanych aplikacji ?  :arrr:

Niw wiem, ja w ogóle nie mam bladego pojęcia jak działa ten mechanizm rozdziału zadań i cały ten system BOINC.
Może trzeba byłoby spytać o to administratorów PrimeGrida?

Nie wiem na ile poprawki Geoffa Reynoldsa zoptymalizowały program, to może mieć większe znaczenie niż tych kilka sekund na ustawieniach kompilatora. Nie wiem, czy PrimeGrid jest skłonny udostępniać kod, którego używa.

Inna sprawa, że sam program liczący nie był chyba optymalizowany przez żadnego programistę, bo zakładam, że Geoff Reynolds nie wgryzał się w szczegóły algorytmu i poprawił co nieco na wierzchu. Ja mogę zaprojektować algorytm i napisać działający program w gołym C (żadnych asemblerów), biorąc niektóre ustawienia na wyczucie, co też zrobiłem. Ale optymalizowanie samego kodu i testowanie wielu wersji, żeby zaoszczędzić parę sekund, przekracza moje możliwości. Jako że nie jestem zawodowym programistą, nie jestem w stanie sprawnie tworzyć i testować wielu wersji.

Jedną z rzeczy, którą zrobiłem na wyczucie, było zastąpienie pojedynczych dzieleń 64-bitowych wieloma szybszymi operacjami. Na ile jest to opłacalne, może zależeć od procesora.

W pliku AP26.h oraz w pliku Sito.h są wprowadzone i używane zmienne s61-s97, m61-m97, r61-r97. A może to za dużo? Może należało skończyć na 89 zamiast 97? A może za mało, może należało dołączyć 101? Nie trzeba rozumieć algorytmu, aby wprowadzać i testować odpowiednie zmiany, jeśli się ich konsekwentnie dokona we wszystkich wystąpieniach. Ale to wymaga żmudnej dłubaniny przy programie i daje wątpliwy, bo zależny od warunków (procesora), efekt.

Jestem przekonany, że PrimeGrid chętnie dowiedziałby się o wszelkich możliwych optymalizacjach.

John na forum PrimeGrid napisał:

The arguments for AP26 are Kmin Kmax shift. It correlates with the WU name of ap26_Kmin_Kmax_shift_WU iteration. For example, ap26_1603_1605_0_0 is Kmin=1603, Kmax=1605, shift=0, and initial result.

Ten sam efekt można uzyskać wykonując w timing??.c:
SearchAP26(1603,0);
SearchAP26(1604,0);
SearchAP26(1605,0);
zatem timing??.c po odpowiedniej modyfikacji pozwala porównać czas wykonania odpowiednich WU z czasem własnej wersji programu. Może być różnica ustawień, jeśli chodzi o to, jak długie ciągi są zapisywane do pliku z wynikami, ale to na czas istotnie wpływać nie powinno. Tym się zresztą łatwo reguluje w linijce
if(AP_Length>=14){

Cytat: IThorne w 01 Styczeń 2009, 19:01
Widzę, że 64-biciaki ostro sobie jeżdżą. A aplikacja dla 32 jest planowana (spodziewam sie negatywnej odpowiedzi po tym jak zobaczyłem tekst o ich marnym wkładzie w szukanie AP24)?

To chyba nie jest na 100% zdecydowane, ale nie wiem, czy uruchamianie tego na 32 bitach jest sensowne, zwłaszcza w sytuacji, gdy mogą one bardziej wydajnie brać udział w innych projektach.

Ja używałem do AP24 komputerów 32-bitowych, bo one akurat w owym czasie nie miały nic lepszego do roboty. Nie robiłem dokładnych pomiarów, ale różnica prędkości była dramatyczna - na oko ponad 10-krotna, przy stosunkowo niewielkiej różnicy taktowania procesora. W programie AP26 różnica wydaje się być mniejsza, ale nadal jest spora.

Ja przekazałem PrimeGrid-owi program, tzn. całą procedurę wykonującą właściwe obliczenia, a oni to opakowali tak, aby dało się to uruchamiać w sieci. Zmiany w samej procedurze liczącej dotyczyły chyba głównie wymiany procedury testującej pierwszość, aby nie używać gmp oraz wstawienia punktów kontrolnych zapisujących postęp obliczeń. Na zagadnieniach sieciowych się nie znam, więc nawet nie starałem się śledzić,  jak oni to opakowywali. Nie mam więcej informacji o szczegółach ich planów niż można zdobyć z dyskusji na forum PrimeGrid:

John (Forum moderator): . NOTE: Currently only available for 64 bit Linux. 64 bit Windows will come later. 32 bit has such a huge disadvantage in processing time that we are reviewing whether it will be implemented.

Blast: And if 32bit is so slow, just forget about it, there's plenty to do for 32bit machines already.

Widać więc, że idea uruchamiania programu na 32 bitach nie cieszy się poparciem.

Dodam od siebie, że prędkość programu może zależeć także od typu procesora i jego pewnych trudno przewidywalnych cech. W programie AP24 używałem:
AMD Athlon 64 Processor 3000+ (1800 MHz)
Intel Pentium D  805 CPU 2.66GHz

Na dwurdzeniowym Pentium-ie można było uruchomić dwa wątki, ale każdy chodził z prędkością ok. 0.6 Athlona, czyli 2-rdzeniowy Pentium był wart 1.2 Athlona.

Jednak w jednym z późniejszych projektów uruchomiłem program, który na każdym rdzeniu Pentiuma dawał 20% wydajności Athlona. Zatem dwurdzeniowy Pentium był w tym wypadku wart 0.4 Athlona. Kolega wytłumaczył mi, że ten model Pentiuma miał problemy z operacją shiftu, na której opierał się ten konkretny program.

Z później uruchamianych projektów na nowszych komputerach, mam podstawy sądzić, że
Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz
już nie ma takich wad i wydajność jego rdzeni jest podobna do wyżej wspomnianego Athlona, natomiast rewelacyjnie spisuje się
Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
ale tu głównym czynnikiem może być wyższe taktowanie.

Wersja programu, którą przekazałem PrimeGrid-owi, jest publicznie dostępna w katalogu
http://www.math.uni.wroc.pl/~jwr/AP26/
plik AP26.ZIP

Wersja ta wymaga do kompilacji gmp, ja używałem pod linuxem polecenia:
gcc -O3 -lm -lgmp -o ap26-32 timing32.c
gcc -O3 -lm -lgmp -o ap26-64 timing64.c
odpowiednio na 32 i 64 bitach. Powyższe programy są tak ustawione, że nie robią nic użytecznego poza testowaniem prędkości, bo przebiegają po zakresie już przeliczonym.

Na komputerach, na których to testowałem, test zajmował 7-12 minut (64 bity) oraz ok. 55 minut (32 bity).

Nie wiem na ile zmiany wprowadzone przez Geoffa Reynoldsa zoptymalizowały sam program, ale podejrzewam, że proporcja wydajności poszczególnych typów procesorów powinna być z grubsza zachowana.

Kilka dni temu PrimeGrid uruchomił podprojekt AP26 Search.

Celem tego podprojektu jest znalezienie postępu arytmetycznego złożonego z 26 liczb pierwszych.

Najnowsza historia związana z postępami arytmetycznymi liczb pierwszych jest następująca:

17 marca 1993 A. Moran, P. Pritchard i A. Thyssen znaleźli pierwszy znany postęp arytmetyczny złożony z 22 liczb pierwszych (w skrócie AP22).

W kwietniu 2004 Ben Green i Terrence Tao udowodnili, że istnieją dowolnie długie postępy arytmetyczne liczb pierwszych. Dowód jest jednak niekonstruktywny i nie tylko nie pozwala na konstruowanie przykładów, ale nawet w żaden sposób nie ułatwia ich znajdowania.

24 lipca 2004 Markus Frind, Paul Jobling i Paul Underwood poprawili 11-letni rekord znajdując pierwszy znany AP23.

18 stycznia 2007 znalazłem pierwszy znany AP24. Do trwających tydzień obliczeń wykorzystałem komputery w pracowniach studenckich Instytutu Matematycznego Uniwersytetu Wrocławskiego. Formalnie komputerów było 75, ale faktycznie tylko 30 64-bitowych. Komputery 32-bitowe miały udział raczej symboliczny, ich wydajność w tym konkretnym programie jest bowiem żałośnie niska. Do poszukiwań użyłem programu w C, opartego na zaprojektowanym przeze mnie algorytmie szukania długich postępów arytmetycznych liczb pierwszych.

Szukanie postępu 25-wyrazowego przekraczało możliwości sieci komputerów w pracowniach studenckich. Jednak Raanan Chermoni, mający dostęp do całkiem wydajnej lokalnej sieci komputerowej, zaproponował mi współpracę. Mój program na jego komputerach doprowadził do znalezienia 17 maja 2008 pierwszego (i jak dotąd jedynego znanego) AP25.

Z kolei pobicie tego rekordu zdaje się przekraczać możliwości lokalnej sieci. Administratorzy PrimeGrid zaoferowali mi uruchomienie poszukiwań AP26 w systemie obliczeń rozproszonych. Geoff Reynolds udoskonalił i dostosował do potrzeb obliczeń rozproszonych w sieci moją wersję programu nakierowaną na szukanie postępów 26-wyrazowych.

Skutkiem ubocznym poszukiwań AP26 będzie zapewne wielokrotne poprawianie rekordów największych znanych AP24 i AP25 odnotowywanych na stronie:
http://users.cybercity.dk/~dsl522332/math/aprecords.htm

Nie będę ukrywał, że byłoby mi bardzo miło, gdyby członkowie drużyny BOINC@Poland dołożyli jakieś polskie akcenty do tych poszukiwań.

Więcej informacji można znaleźć na forum:
http://www.primegrid.com/forum_forum.php?id=38

Na razie do włączenia się do poszukiwań potrzebny jest 64-bitowy Linux, ma się też pojawić wersja programu dla 64-bitowego Windowsa.

Jednym z założeń algorytmu jest wyeliminowanie korzystania z pamięci RAM i zmieszczenie się w pamięci podręcznej procesora, zatem program w zależności od procesora może korzystać z RAM-u mało albo wcale.