AP26 search

[Jarek Wróblewski]

nie dowierzałem, że taki wynik osiągnął nasz ksysju :parrrty:

zrobiłem na szybko pełną statystykę stan na 05-01-09 20:15
łączna liczba przeliczonych wu podprojektu AP26Search = 23898

ksysju zrobił swoje, a ja mam podejrzenie, że reszta dopchnęła BOINC@Poland na I miejsce w AP26. Czy ktoś jest w stanie to sprawdzić?

Dogrzebałem się ręcznie do:
BOINC@Poland 4,604
[B@H] Clooney ->  BOINC@Heidelberg  4,403
blah -> niezrzeszony
Skligmund ->  BOINCstats 3,145

dalej nie miałem cierpliwości przeglądać...

[AiDec]

A ja sie nigdzie dogrzebac nie moge. Czy ktos uprzejmy moglby podac linka pod ktorym moge sprawdzic ile mam pkt. w AP26?

[RAD-Poland]

http://sig.primestats.net/pg/28684.png


AP26 to jeszcze nie opisana pozycja subproject  EDIT: nie wiem co ile aktualizują

zerknij na http://www.boincatpoland.org/smf/primegrid/ap26-search/msg54179/#msg54179
Aktualizacja co 15 min

punkty to ilość przeliczonych wu * 13,61 pkt/wu

[Mchl]

Jakby tak jeszcze ktoś od nas znalazł pierwszy AP26 to w ogóle byłoby fajnie :)

[Jarek Wróblewski]

Jakby tak jeszcze ktoś od nas znalazł pierwszy AP26 to w ogóle byłoby fajnie :)

Na razie nie ma znalezionych żadnych AP24 ani AP25. Jednak myślę, że AP24 się wkrótce pojawi w statystykach, bo najmniejszy znany AP24 jest na drodze programu, a WU, który ma go znaleźć, został już przydzielony użytkownikowi o nazwie ksysju. No chyba, że ksysju nałykał się tyle WU do buforka, że będzie to liczył przez tydzień, albo, za przeproszeniem, zwróci.

EDIT:

http://www.primestats.net/primegrid/teams.php?project=AP26

1     BOINC@Poland     106,343     7,814
2    BOINCstats    65,774    4,833
3    BOINC@Heidelberg    60,384    4,437
4    PrimeSearchTeam    45,119    3,316
5    BOINC Confederation    21,027    1,545    

http://www.primestats.net/primegrid/users.php?project=AP26

1     ksysju     69,504     5,107
2    blah    50,464    3,708
3    [B@H] Clooney    40,937    3,008
4    Skligmund    36,174    2,658
5    Lumiukko    23,926    1,758

Może warto namówić więcej linixowców 64-bitowych, żeby pomogli utrzymać to prowadzenie.

Może warto się tym gdzieś na stronie głównej pochwalić. A nuż ktoś rzuci jakiś superpunktujący projekt i przerzuci swoje moce na ten front.

[Jarek Wróblewski]

No i ksysju doliczył się do pierwszego AP24.
Co prawda to już było znane, ale próba generalna przed prawdziwymi odkryciami zaliczona  :attack:

[Jarek Wróblewski]

@ksysju
Widze niezłe stadko tam masz i to karmione 64 bitami ;D Tylko pozazdrościć :arrr:

Cosik mi się widzi, że to stadko się rozrasta  XD

Liczby WU w/g PrimeStat:

W dniu 8 stycznia 2009
całe AP26 - 5,387
BOINC@Poland - 3,144 = 58,36 %
ksysju - 2,832 = 52,57 %

Razem do 8 stycznia 2009
całe AP26 - 37,434
BOINC@Poland - 10,958 = 29,27 %
ksysju - 7,939 = 21,21 %

[Troll81]

Jak będzie AP pod windozę to się jeszcze bardziej rozrośnie.

[Jarek Wróblewski]

Ładnie ciągniesz, AiDec, może dziesiątkę dogonisz. Trzymam kciuki.

[AiDec]

Ładnie ciągniesz, AiDec, może dziesiątkę dogonisz. Trzymam kciuki.

Dzieki. Wreszcie znalazlem czas zeby pojechac do mojego kompa (mam kompy porozrzucane po calej wsi ;) ) - stad zmiany na lepsze :).

[Jarek Wróblewski]

Na stronie
http://www.primegrid.com/forum_thread.php?id=1182
publikowane są szczegółowe dane dotyczące znalezionych AP23 i dłuższych.

Na razie znaleziono 2 AP24 (w tym jeden ksysju) oraz 3 AP23 (w tym jeden AiDec).

EDIT: AKTUALIZACJA:

Znaleziono 2 AP24 (w tym jeden ksysju) oraz 4 AP23 (w tym dwa AiDec).

[Jarek Wróblewski]

Tutaj
http://www.primegrid.com/forum_thread.php?id=1179
toczy się dyskusja nad instalacją Windy. Ja z tego rozumiem, że to jest kwestia odpowiedniego skompilowania i przetestowania programu, więc nie można wykluczyć, że Windę uruchomią lada chwila. No ale mogą się też pojawić jakieś problemy i się trochę pociągnie.

Jak Winda ruszy, to ogłoszenie może się ukazać gdzieś w dziale
http://www.primegrid.com/forum_forum.php?id=38

[Troll81]

Czekam z niecierpliwością :D

[ksysju]

Witam

Czy komuś "wysypywały" się próbki?

Ostatnio na dwóch kompach miałem tak po kilkanascie sztuk wu  z errorem po sekundzie, dwóch.
Na obu w tym samym czasie (sobota-niedziela). Może przypadek, może coś więcej.

--
ksysju

[TJM]

Tak, mi się wysypywały zaraz na początku, zajrzyj na stronę w te WU - pewnie u wszystkich się sypnęły, tak właśnie było w moim przypadku.

[Jarek Wróblewski]

Witam

Czy komuś "wysypywały" się próbki?

Ostatnio na dwóch kompach miałem tak po kilkanascie sztuk wu  z errorem po sekundzie, dwóch.
Na obu w tym samym czasie (sobota-niedziela). Może przypadek, może coś więcej.

--
ksysju

Czy jesteś w stanie podać namiary na te próbki?

[Jarek Wróblewski]

Tak, mi się wysypywały zaraz na początku, zajrzyj na stronę w te WU - pewnie u wszystkich się sypnęły, tak właśnie było w moim przypadku.

Na początku oni bezmyślnie robili próbki z trzech kolejnych K.
K podzielne przez liczbę pierwszą z zakresu 29-59 są pomijane przez program.
Próbki, które zawierały 3 takie K nie miały nic do roboty i zwracały błąd, a potem gdzieś tam wisiały i krążyły między użytkownikami.

Zdaje się, że teraz próbki zawierają tyle kolejnych K, żeby dokładnie 3 były niepodzielne przez 29-59.

[TJM]

BOINC ma zabezpieczenie przed próbkami krążącymi w nieskończoność -> max number of total/error results przypisany do każdej aplikacji lub nawet każdej wersji aplikacji.
Takie uszkodzone zadanko może sobie jakiś czas powisieć, bo za każdym razem przechodzi przez cykl: kolejka na serwerze -> wysłanie do użytkownika -> przeliczanie -> odesłanie -> zaraportowanie -> validator -> transitioner -> kolejka na serwerze, więc niewykluczone że to 'pierwsze uszkodzone zadania reloaded' %-)

[Jarek Wróblewski]

A jeśli chodzi o uruchamianie Windy, to wygląda na to, że PrimeGrid walczy ze skompilowaniem tego pod Win64.
Geoff Reynolds jest raczej specem od kompilowania pod linuxem, a inni jak dotąd dostają różnego rodzaju błędy.

To są chyba problemy w tym duchu, co my mieliśmy z kompilacją AP19 - w jednym systemie chodzi, a w drugim coś się zacina. Z tym, że nam był potrzebny program na własny użytek, więc można było zrobić jakąś łatankę na kolanie - mindc miał jakieś syfiate GMP, które co prawda pierwszości porządnie testować nie umiało, ale z którego dało się wybrać coś, co działa poprawnie, i jakoś to ruszyło.

No ale oni to chcą mieć porządnie skompilowane, więc to trwa...

Wysiłki kompilacyjne można śledzić tutaj:
http://www.primegrid.com/forum_thread.php?id=1179

[ksysju]

Witam

Wu z błędami:    559200 i końcówki 26 do 29,30,31,35 do 40.
Tyle z jednego kompa, drugiego nie mogę znaleźć, nie pamiętam nazwy.
Klikałem po całości próbek, ale znudziło mi się przy 6000  ;D
Coś mi się nie chce wierzyć, że mam tego tyle "u siebie" do przeliczenia.
         
--
ksysju

[Jarek Wróblewski]

To na pewno nie jest ten problem, o którym pisałem. To już jest nowsza generacja próbek, np. ...27
się nazywa:
ap26_168602_168605_0_0
tu są 4 kolejne K, bo 168603 odpada jako podzielne przez 43.
Zresztą jak widać ktoś to potem przeliczył.
Czyli to nie wina próbek, tylko coś u Ciebie zaszwankowało, ale nie podejmuję się zgadywać co. Może to losowe i jednorazowe.

[Jarek Wróblewski]

AiDec i mindc:
Wygląda na to, że blah i  Skligmund są na razie poza Waszym zasięgiem, natomiast
4.  [B@H] Clooney 3,008
od długiego czasu nie ruszył się z miejsca, więc macie szansę go wyprzedzić za kilka dni i zrobić trójkę Polaków w pierwszej piątce.

Będę Wam kibicował.

ksysju: Gratuluję 20,000 WU i trzymam kciuki za pięćdziesiątkę w styczniu.

[mindc]

(...) Z tym, że nam był potrzebny program na własny użytek, więc można było zrobić jakąś łatankę na kolanie - mindc miał jakieś syfiate GMP, które co prawda pierwszości porządnie testować nie umiało, ale z którego dało się wybrać coś, co działa poprawnie, i jakoś to ruszyło.

używałem intelowskiej biblioteki GMP  :ph34r:

[Jarek Wróblewski]

(...) Z tym, że nam był potrzebny program na własny użytek, więc można było zrobić jakąś łatankę na kolanie - mindc miał jakieś syfiate GMP, które co prawda pierwszości porządnie testować nie umiało, ale z którego dało się wybrać coś, co działa poprawnie, i jakoś to ruszyło.

używałem intelowskiej biblioteki GMP  :ph34r:

Jednakowoż trzy fakty są bezsporne:

1. Twoje GMP nie radziło sobie z testowaniem pierwszości liczb 64-bitowych.

2. Dało się to obejść.

3. Z kompilacją zaszedłeś dalej niż jest obecnie PrimeGrid.

Jak rozumiem, problemem jest to, że na razie nikt tam nie umie sensownie skompilować wersji Win64. Co prawda kompilacja się udała, ale za cenę 2.5-krotnego spowolnienia programu, co jest nie do przyjęcia.

[sesef]

Przepraszam bardzo, jakie muszą być parametry startowe dla AP26, udało mi się skompilować na x64 appa z PrimeGrida jednak nie wiem czy coś mi nie działa czy podaje złe parametry startowe.

Kompilowane na Windowsowym porcie oryginalnego GMP. AP19 mi działa więc od biedy AP26 również powinno.


Edit.

Najlepiej przydałby się jakiś krótki przedział który na pewno mi zwróci jakiś wynik.

[Jarek Wróblewski]

Przepraszam bardzo, jakie muszą być parametry startowe dla AP26, udało mi się skompilować na x64 appa z PrimeGrida jednak nie wiem czy coś mi nie działa czy podaje złe parametry startowe.

Kompilowane na Windowsowym porcie oryginalnego GMP. AP19 mi działa więc od biedy AP26 również powinno.


Edit.

Najlepiej przydałby się jakiś krótki przedział który na pewno mi zwróci jakiś wynik.

Rozumiem, że kompilowałeś kod z katalogu
http://www.geocities.com/g_w_reynolds/AP26/
plik AP26-boinc-src.zip

Ściągnij także plik AP26-boinc-bin.zip z tego samego katalogu.
Plik z parametrami to AP26-ini.txt - powinien się on znajdować w katalogu, w którym uruchamiany jest program (uwaga: plik z parametrami może zostać zmieniony, przy kolejnej próbie uruchomienia programu trzeba przywrócić wersje początkową).

Jeśli wszystko jest OK, to powinien powstać plik SOL-AP26.txt identyczny z TEST-366384.txt

Przy okazji widzę, że myliłem się co do postępów PrimeGrida - w AP26-boinc-bin.zip jest skompilowany program do Win64, ale on nie jest przystosowany do BOINC i chyba nie był porządnie przetestowany. Można go porównać z własną kompilacją. Ja tego nie robiłem, bo nie mam Win64 (nawet na oczy w życiu nie widziałem komputera z Win64). Ja wiem tylko tyle co zrozumiałem z
http://www.primegrid.com/forum_thread.php?id=1179
a techniczne szczegóły dotyczące kompilacji są dla mnie niezbyt zrozumiałe, więc wiem, że jest problem z kompilacją, ale nie wiem dokładnie, gdzie on leży.

[sesef]

Ściągnąłem ten plik z binarkami jest tam testowy zakres. Szykuje się trochę walki, teraz nie chce mi otworzyć pliku z zakresem otworzyć i sypie błędami. Jak to wszystko poprawię to pomierzę czasy jak będzie znośny to skompiluje wersję pod BOINC i podeślę na forum.


A teraz jeszcze zwraca za mało wyników :/

Zwraca mi tylko takie wyniki, a ta z primegrida zwraca dużo więcej, co dziwniejsze wyświetla mi je jako Non-solution i przez to nie zapisuje ich do plików.

10 366384 16137071418665303
11 366384 7315382125981751
11 366384 3007107694524497
12 366384 2248956393265657

Edit2
Niespodzianek ciąg dalszy. App z Pana strony natomiast zwraca poprawny wynik (taki sam jak kompilacja z primegrida)

[Jarek Wróblewski]

Po przeanalizowaniu wyników jest dla mnie w miarę oczywiste, co się dzieje.

Otóż szwankuje procedura testowania pierwszości liczb.

Ja rozumiem to tak: Geoff zastąpił testowanie pierwszości GMP swoją procedurą zyskując 5% prędkości pod linuxem. Użył do tego jakiegoś typu long double, który ma pod linuxem 64 bity precyzji, a w kompilatorach Windowsowych na ogół mniej i stąd problemy. Jeśli się nie uda zmusić Windowsów do takiej precyzji (chyba o tym coś było w tym wątku PrimeGrida), to jednym z najprostszych rozwiązań jest powrót do GMP.

Ja nie wiem na ile Geoff wtopił swoją procedurę w kod, ale w zasadzie problem sprowadza się do podstawienia innej definicji procedury PrimeQ.

Oryginalna procedura używająca GMP jest w PrimeQ64.h w katalogu
http://www.math.uni.wroc.pl/~jwr/AP26
plik AP26.ZIP - to mój program, który był modyfikowany przez Geoffa.

W ostateczności, gdyby PrimeQ64.h szwankowała, można wziąć procedurę z PrimeQ.zip w http://www.math.uni.wroc.pl/~jwr/BaP

[sesef]

Z tego co podebuggowałem problem leży w procedurze validate_ap26(int k, int d, int64_t f) (source z PrimeGrid)

Dokładnie sypie się na pogrubionej linijce

static int validate_ap26(int k, int d, int64_t f)
{
  int64_t N;
  int j;
#ifdef GMP
  mpz_t mpN;
#else
  const int base[] = {2,3,5,7,11,13,17,19,23};
#endif

  if (f%2==0)
    return 0;

#ifdef GMP
  mpz_init2(mpN,64);
#endif

  for (j = 0, N = f; j < k; j++)
  {
#if ((defined(__i386__) || defined(__x86_64__)) && !defined(GMP))
nie istotne, nie jest używane...........

#elif ((defined(__ppc64__) || defined(__powerpc64__)) && !defined(GMP))
  nie istotne, nie jest używane...........
#else
    if (N < 0)
    {
      fprintf(stderr,__FILE__": modulus out of range.\n");
      exit(EXIT_FAILURE);
    }

    mpz_set_ui(mpN,f);

    if (mpz_probab_prime_p(mpN,9) == 0)
      break;
#endif

    N += (int64_t)d*2*3*5*7*11*13*17*19*23;
  }

#ifdef GMP
  mpz_clear(mpN);
#endif

  return j;
}

Przez to "testowanie" większość poprawnych wyników jest uważana za błędne i oznaczana jako "Non-solution" a tak oznaczone rezultaty nie trafiają do pliku wynikowego.

[Jarek Wróblewski]

Teraz widzę, że same błędy testowania pierwszości tego nie wyjaśniają. W tej chwili nie rozumiem, co się dzieje.

[Jarek Wróblewski]

To wisi na testowaniu pierwszości GMP. Jeżeli to działa źle, jak przy AP19 u mindca, to stąd się może brać problem validate_ap26.

Jednak nadal nie rozumiem, dlaczego ten 11-elementowy kawałek AP25 został wydrukowany do pliku.

EDIT:

No dobra, teraz doczytałem, że pierwszość GMP przetestowałeś i jest OK.

To ja już nic nie rozumiem.

EDIT:

Myślę, że po prostu sprawdzanie pierwszości w programie działa trochę źle. Trochę, tzn. najczęściej daje dobre wyniki, ale nierzadko się myli w obie strony (tzn. liczby pierwsze oznacza jako złożone, a złożone jako pierwsze). Te pomyłki powodują z jednej strony, że gubi się rozwiązania, a z drugiej strony validate_ap26 nie chce przepuszczać lipy.

Żeby podważać poprawność validate_ap26 musiałbym wiedzieć, jakie rozwiązania są oznaczane jako Non-solution i się im przyjrzeć. Wtedy będę wiedział, czy są odrzucane słusznie, czy niesłusznie.

EDIT:

W/g mnie tam jest bug, zamiast

mpz_set_ui(mpN,f);

powinno być

mpz_set_ui(mpN,N);

Napisałem o tym do Geoffa. Jednak to nie ma prawa mieć związku z Twoimi problemami. Jeśli tu istotnie jest bug, to polega na tym, że weryfikator wielokrotnie sprawdza pierwszość pierwszego wyrazu. To się w żaden sposób nie powinno wiązać z tym, czego doświadczasz. Ani też nie powinno mieć znaczenia póki program działa poprawnie.

[sesef]

No dobra, teraz doczytałem, że pierwszość GMP przetestowałeś i jest OK.

Znaczy uznałem tak na podstawie 2 faktów.
1. Ten port GMP to tak na prawdę zwykłe GMP (ściągałem source ze strony GMP) tylko projekt zawiera odpowiednie confingi aby dało się to skompilować pod windowsem i tyle. Source nie jest w żaden sposób zmieniane. Natomiast mindc używał implementacji GMP z Intelowskiej biblioteki MKL i Bóg jeden wie co tam Intel napchał dlatego występowały problemy.
2. Skompilowałem na tych samym buidzie GMP również kod z Pana strony (AP26.zip) i dostaje już poprawny wynik (Taki sam jak w tym pliku test....)

Przechodząc do samych wyników dostaje w konsoli coś takiego (Non-solution nie jest zapisywane do pliku, inne zbędne informacje o checkpointach wyciąłem)

Gwiazdką zaznaczyłem wyniki które testowa aplikacja z PrimeGrida oraz Pana podała jako poprawne.

Non-Solution: 10 366384 785436737771879 *
Solution: 10 366384 16137071418665303 *
Non-Solution: 10 366384 13946622976437587 *
Non-Solution: 10 366384 8734502163109357 *
Non-Solution: 11 366384 6998839830228583 *
Non-Solution: 10 366384 7080577488310663
Non-Solution: 10 366384 785468127438811 *
Non-Solution: 11 366384 5581880890832023 *
Non-Solution: 10 366384 5663618548914103
Non-Solution: 25 366384 6171054912832631 *
Non-Solution: 24 366384 6252792570914711
Non-Solution: 23 366384 6334530228996791
Non-Solution: 22 366384 6416267887078871
Non-Solution: 21 366384 6498005545160951
Non-Solution: 20 366384 6579743203243031
Non-Solution: 19 366384 6661480861325111
Non-Solution: 18 366384 6743218519407191
Non-Solution: 17 366384 6824956177489271
Non-Solution: 16 366384 6906693835571351
Non-Solution: 15 366384 6988431493653431
Non-Solution: 14 366384 7070169151735511
Non-Solution: 13 366384 7151906809817591
Non-Solution: 12 366384 7233644467899671
Solution: 11 366384 7315382125981751 (WTF? zapisuje to do pliku, a według poprawnego winiku tego nie powinno być)
Non-Solution: 10 366384 9684491327954279 *
Non-Solution: 10 366384 3267586960583089 *
Non-Solution: 10 366384 1459178643530617 *
Non-Solution: 10 366384 9735298495263823 *
Non-Solution: 10 366384 1727805601738891 *
Non-Solution: 10 366384 1574579779396307 *
Non-Solution: 10 366384 2138118918508471 *
Non-Solution: 11 366384 10613929284401483 *
Non-Solution: 10 366384 10695666942483563
Non-Solution: 10 366384 14083229671187167 *
Non-Solution: 11 366384 16518632605478693 *
Non-Solution: 10 366384 16600370263560773
Solution: 11 366384 3007107694524497 *
Non-Solution: 10 366384 1255892682660361 *
Non-Solution: 11 366384 7036595108074969 *
Non-Solution: 10 366384 7118332766157049
Non-Solution: 10 366384 8188609810134857 *
Non-Solution: 10 366384 2411963918614357 *
Non-Solution: 11 366384 6569259450263561 *
Non-Solution: 10 366384 6650997108345641
Non-Solution: 10 366384 13700995611657901 *
Non-Solution: 14 366384 15879407069784169 *
Non-Solution: 13 366384 15961144727866249
Non-Solution: 12 366384 16042882385948329
Non-Solution: 11 366384 16124620044030409
Non-Solution: 10 366384 16206357702112489
Non-Solution: 11 366384 6250872237076277 *
Non-Solution: 10 366384 6332609895158357
Non-Solution: 10 366384 7687488261269507 *
Non-Solution: 10 366384 660669773389609 *
Non-Solution: 10 366384 11977568522771779 *
Non-Solution: 10 366384 1540799946122147 *
Non-Solution: 12 366384 14782924219657043 *
Non-Solution: 11 366384 14864661877739123
Non-Solution: 10 366384 14946399535821203
Non-Solution: 10 366384 13812949836154363 *
Non-Solution: 11 366384 2003229604981763 *
Non-Solution: 10 366384 2084967263063843
Non-Solution: 10 366384 14531182366753699 *
Non-Solution: 13 366384 15731878523384263 *
Non-Solution: 12 366384 15813616181466343
Non-Solution: 11 366384 15895353839548423
Non-Solution: 10 366384 15977091497630503
Non-Solution: 13 366384 2167218735183577 *
Solution: 12 366384 2248956393265657 (WTF? zapisuje to do pliku, a według poprawnego winiku tego nie powinno być)

Edit
Może problem nie leży w samej funkcji validate_ap26 a w dobieraniu parametrów podczas rekurencyjnego wywoływania.

Jak usunąłem ten kawałek kodu z ReportSolution (czyli praktycznie ten nieszczęsny validate i późniejsze jego rekurencyjne wywoływanie) to uzyskałem poprawne wyniki. Tak więc jestem pewny na 99,99%, że problem leży w samym validate albo jego wywołaniu.

    if ((i = validate_ap26(AP_Length,difference,First_Term)) < AP_Length)
    {
#ifdef BOINC
      if (boinc_is_standalone())
#endif
        printf("Non-Solution: %d %d %"PRId64"\n",
               AP_Length,difference,First_Term); 

      /* Check leading terms */
      ReportSolution(i,difference,First_Term);

      /* Check trailing terms */
     ReportSolution(AP_Length-(i+1),difference,First_Term
                     +(int64_t)(i+1)*difference*2*3*5*7*11*13*17*19*23);
      return;
    }

[Jarek Wróblewski]

Teraz nie mam wątpliwości.
validate_ap26 działa poprawnie co do zasady, ale skopane jest testowanie pierwszości wewnątrz validate_ap26.

Dzięki bugowi z f zamiast N w ogóle cokolwiek przechodzi przez validate_ap26. Gdyby nie ten bug, to najprawdopodobniej program niczego by nie drukował do pliku, a i na ekranie by się mniej pojawiało.

Pomyślę jak temu dziadostwu zajrzeć w bebechy.

EDIT:

Pierwszy test:

Zamiast

    mpz_set_ui(mpN,f);

    if (mpz_probab_prime_p(mpN,9) == 0)
      break;

daj

    mpz_set_ui(mpN,N);
{
char kuku[128];
int pipi;
FILE *fifi;

fifi=fopen("BUG.TXT","at");
mpz_get_str(kuku,10,mpN);

fprintf(fifi,"%"PRId64" %s\n",N,kuku);


    if ((pipi=mpz_probab_prime_p(mpN,9)) == 0)
{fprintf(fifi,"zlozona %"PRId64" %s %d\n",N,kuku,pipi);
fclose(fifi);
      break;
};
fprintf(fifi,"pierwsza %"PRId64" %s %d\n",N,kuku,pipi);
fclose(fifi);
};

i zobacz, co się pojawia w BUG.TXT

[sesef]

Dostałem coś takiego:

785436737771879 3183450471
zlozona 785436737771879 3183450471 0
16137071418665303 3114264919
pierwsza 16137071418665303 3114264919 1
16218809076747383 3249736823
pierwsza 16218809076747383 3249736823 1
16300546734829463 3385208727
zlozona 16300546734829463 3385208727 0
13946622976437587 877899091
zlozona 13946622976437587 877899091 0
8734502163109357 3266893293
zlozona 8734502163109357 3266893293 0
6998839830228583 1642835559
zlozona 6998839830228583 1642835559 0
7080577488310663 1778307463
zlozona 7080577488310663 1778307463 0
785468127438811 213379035
zlozona 785468127438811 213379035 0
5581880890832023 3953996951
zlozona 5581880890832023 3953996951 0
5663618548914103 4089468855
zlozona 5663618548914103 4089468855 0
6171054912832631 2952266871
zlozona 6171054912832631 2952266871 0
6252792570914711 3087738775
zlozona 6252792570914711 3087738775 0
6334530228996791 3223210679
zlozona 6334530228996791 3223210679 0
6416267887078871 3358682583
zlozona 6416267887078871 3358682583 0
6498005545160951 3494154487
zlozona 6498005545160951 3494154487 0
6579743203243031 3629626391
zlozona 6579743203243031 3629626391 0
6661480861325111 3765098295
zlozona 6661480861325111 3765098295 0
6743218519407191 3900570199
zlozona 6743218519407191 3900570199 0
6824956177489271 4036042103
zlozona 6824956177489271 4036042103 0
6906693835571351 4171514007
zlozona 6906693835571351 4171514007 0
6988431493653431 12018615
zlozona 6988431493653431 12018615 0
7070169151735511 147490519
zlozona 7070169151735511 147490519 0
7151906809817591 282962423
zlozona 7151906809817591 282962423 0
7233644467899671 418434327
zlozona 7233644467899671 418434327 0
7315382125981751 553906231
pierwsza 7315382125981751 553906231 1
7397119784063831 689378135
zlozona 7397119784063831 689378135 0
9684491327954279 1500437863
zlozona 9684491327954279 1500437863 0
3267586960583089 1611590065
zlozona 3267586960583089 1611590065 0
1459178643530617 2159420281
zlozona 1459178643530617 2159420281 0
9735298495263823 3499603023
zlozona 9735298495263823 3499603023 0
1727805601738891 388100235
zlozona 1727805601738891 388100235 0
1574579779396307 1819009747
zlozona 1574579779396307 1819009747 0
2138118918508471 2594181047
zlozona 2138118918508471 2594181047 0
10613929284401483 4239063371
zlozona 10613929284401483 4239063371 0
10695666942483563 79567979
zlozona 10695666942483563 79567979 0
14083229671187167 1842832095
zlozona 14083229671187167 1842832095 0
16518632605478693 3701468965
zlozona 16518632605478693 3701468965 0
16600370263560773 3836940869
zlozona 16600370263560773 3836940869 0
3007107694524497 3522099281
pierwsza 3007107694524497 3522099281 1
3088845352606577 3657571185
zlozona 3088845352606577 3657571185 0
1255892682660361 1295637001
zlozona 1255892682660361 1295637001 0
7036595108074969 4158150105
zlozona 7036595108074969 4158150105 0
7118332766157049 4293622009
zlozona 7118332766157049 4293622009 0
8188609810134857 1257240393
zlozona 8188609810134857 1257240393 0
2411963918614357 479493973
zlozona 2411963918614357 479493973 0
6569259450263561 3891816457
zlozona 6569259450263561 3891816457 0
6650997108345641 4027288361
zlozona 6650997108345641 4027288361 0
13700995611657901 2692777645
zlozona 13700995611657901 2692777645 0
15879407069784169 2443405417
zlozona 15879407069784169 2443405417 0
15961144727866249 2578877321
zlozona 15961144727866249 2578877321 0
16042882385948329 2714349225
zlozona 16042882385948329 2714349225 0
16124620044030409 2849821129
zlozona 16124620044030409 2849821129 0
16206357702112489 2985293033
zlozona 16206357702112489 2985293033 0
6250872237076277 2604281653
zlozona 6250872237076277 2604281653 0
6332609895158357 2739753557
zlozona 6332609895158357 2739753557 0
7687488261269507 3607570435
zlozona 7687488261269507 3607570435 0
660669773389609 724049705
zlozona 660669773389609 724049705 0
11977568522771779 4245855555
zlozona 11977568522771779 4245855555 0
1540799946122147 1903518627
zlozona 1540799946122147 1903518627 0
14782924219657043 3269110611
zlozona 14782924219657043 3269110611 0
14864661877739123 3404582515
zlozona 14864661877739123 3404582515 0
14946399535821203 3540054419
zlozona 14946399535821203 3540054419 0
13812949836154363 4769275
zlozona 13812949836154363 4769275 0
2003229604981763 1023552515
zlozona 2003229604981763 1023552515 0
2084967263063843 1159024419
zlozona 2084967263063843 1159024419 0
14531182366753699 2334327715
zlozona 14531182366753699 2334327715 0
15731878523384263 1728655815
zlozona 15731878523384263 1728655815 0
15813616181466343 1864127719
zlozona 15813616181466343 1864127719 0
15895353839548423 1999599623
zlozona 15895353839548423 1999599623 0
15977091497630503 2135071527
zlozona 15977091497630503 2135071527 0
2167218735183577 4007425753
zlozona 2167218735183577 4007425753 0
2248956393265657 4142897657
pierwsza 2248956393265657 4142897657 1
2330694051347737 4278369561
zlozona 2330694051347737 4278369561 0
2412431709429817 118874169
zlozona 2412431709429817 118874169 0

[Jarek Wróblewski]

Sprawa jasna. Wiem, co się dzieje, nie wiem dlaczego.

Bezpośrednim winowajcą jest:

mpz_set_ui(mpN,N);

które powinno zamienić 64-bitową liczbę N na GMP, a zamiast tego obcina ją do 32 bitów, czyli w pewnym sensie zachowuje się jak na 32 bitach.

Najprościej zastąpić to wersją uniwersalną, która powinna działać niezależnie od 32/64 bitów:

    mpz_set_ui(mpN,N>>32);
    mpz_mul_2exp(mpN,mpN,32);
    mpz_add_ui(mpN,mpN,N&(INT64_C(4294967295)));

To powinno załatwić sprawę konwersji N do GMP.

Jaką masz wartość GMP_LIMB_BITS ?

Można to druknąć dając gdziekolwiek w programie:
printf("GMP_LIMB_BITS: %d\n",GMP_LIMB_BITS);

[sesef]

Można to druknąć dając gdziekolwiek w programie:
printf("GMP_LIMB_BITS: %d\n",GMP_LIMB_BITS);

Kolejna niespodzianka. Jak wrzuciłem do programu to GMP_LIMB_BITS wynosi 64 ale przed kompilacją według makr GMP_LIMB_BITS wynosi 32 i tylko te części kodu chce kompilować które są w dyrektywach dla 32 bit.

Ciekawostka numero duo

# include <gmp.h>
# if (GMP_LIMB_BITS==64)
#  include "PrimeQ64.h"
# elif (GMP_LIMB_BITS==32)
#  include "PrimeQ32.h"
# endif

Według Visual Studio jest wersja 32 bit przez co część kodu przeznaczona dla 64 bit jest nie aktywna (w VS zaznaczona na szaro) czyli podczas kompilacji powinien kompilator rzucać błędami że brakuje mu PrimeQ32.h bo według dyrektyw to ma aktywne i to ma linkować (pliku PrimeQ32 w ogóle nie włączyłem do projektu) jednak nic takiego się nie dzieje i linkuje sobie PrimeQ64.h które znajduje się w projekcie.


Dobra wywaliłem te całe podziały na kod 64 i 32 bit i wrzuciła ta standardową wersje podana przez Pana jak na razie z tego co mieli to widzę że powinno dawać poprawne wyniki. Dlaczego bezpośrednie podstawienie liczby na 64 bit nie działa nie mam pojęcia w funkcji sprawdzającej pierwszość z PrimeQ64.h działa bez problemów a tutaj nie chcę, z tego co widzę ta uniwersalna metoda wykonuje kilka obliczeń czy spowalnia to jakoś znacząco kod?, zawszę na upartego mogę skopiować metodę konwersji liczby z funkcji PrimeQ (jak dobrze rozumuję powinno również działać)


Edit2
Przeliczyło się i dało teraz już poprawny wynik.

[Jarek Wróblewski]

No to ja już się chyba w tym nie połapię.

W każdym razie PrimeQ64.h i PrimeQ32.h nie mają prawa poprawnie działać, jeżeli nie są użyte w odpowiedniej wersji.

Niezależnie od komputera, ja to rozumiem tak, że GMP_LIMB_BITS powinno określać jakiej długości są słowa użyte w rachunkach. Jeśli to jest pomieszane, to mogą się pojawiać dziwne rzeczy. To trochę tak jakby wykonywać rachunki, tylko nie być do końca zdecydowanym, czy liczymy w systemie dziesiętnym, czy szesnastkowym.

No dobra, jesteśmy gdzieś między 32 i 64 bitami, tylko gdzie?

Póki co spróbuj podstawić tę uniwersalną konwersję N do GMP i zobacz jak program chodzi.

EDIT:

Nie wiem, czy mocno spowalnia, to są proste operacje. Możesz oczywiście skopiować tę konwersję z PrimeQ64.h - tak będzie najwydajniej, ale mogą być problemy przy przenoszeniu tego na inny kompilator. Ale to nieistotne, bo i tak są problemy. Z tym, że validate_ap26 jest wykonywane kilka razy na minutę, więc wydajność tej konwersji nie ma znaczenia.

Póki co ważne, że to chodzi. Teraz pytania są dwa:

1. Jaka jest wydajność Twojej kompilacji?
Przedział testowy na 3GHz powinien zająć poniżej 300 sekund (280-290 byłoby chyba całkiem nieźle)

2. Czy umiesz to skompilować z tymi bajerami BOINC? - ja o tym nie mam bladego pojęcia, więc nie pomogę, w razie problemów musisz pytać na forum PrimeGrida.

Ja zaraz napiszę tam o źródle problemu, żeby ostrzec innych.

[sesef]

1. No i tu wychodzi ciekawostka nr 3

Wersja skompilowana z GMP 6:11
Wersja testowa 4:58

Komputer AMD64 3200+ 2.0 Ghz podkręcone na 2.7

Pokombinuje jeszcze z flagami kompilacji itp ale nie wiem czy nawet zdołam zejść do poziomu aplikacji liczącej przez FPU

2. To nie jest problem, kompilowałem już aplikacje do MilkyWay@Home tak więc z tym problemów nie będzie.

[Jarek Wróblewski]

Wersja skompilowana z GMP 6:11
Wersja testowa 4:58

Nie rozumiem, które wersje masz na myśli.
Są 3:
1. Mój oryginalny program z GMP
2. Binarka 64-bitowa od PrimeGrida
3. To, co kompilowałeś

EDIT:

Napisałem na forum PrimeGrida o tym problemie (bo to dotyczyło obliczeń, więc się na tym znam).
Jak coś sensownego wykompilujesz lub będziesz miał problemy, to już sam tam napisz, bo na kompilacji się pewnie znasz dużo lepiej ode mnie.

[sesef]

Nie rozumiem, które wersje masz na myśli.
Są 3:
1. Mój oryginalny program z GMP
2. Binarka 64-bitowa od PrimeGrida
3. To, co kompilowałeś

Przetestowałem wszystkie 3

Ad1 6:12
Ad2 4:58
Ad3 6:11

Pokombinuje z flagami kompilatora, może kompilator Intela coś pomoże.