BOINC@Poland

Cytat: mindc w 05 Luty 2009, 21:14

Cytat: Jarek Wróblewski w 04 Luty 2009, 17:13
Dostałem informację, że AP26 jest dostępny na 32-bitowego linuxa.

ucieszyłem się niezmiernie, ale...
znowu ktoś zapomniał dodać flagę -static przy kompilacji i kilkadziesiąt maszyn nie ma co liczyć gdy milka leży i kwiczy

Ja się na tym nie znam, więc nie wiem w czym problem, ale przekazałem tę informację administratorom PrimeGrid-a.
Oto odpowiedź, jaką właśnie dostałem:

Cytat
I will compile a 32-bit static linked executable and upload it in a day or two. The program doesn't use any special libraries, so only Linux users running fairly old versions of the system libraries will need the static version.

Rozumiem więc, że problem dotyczy tylko linuxa ze starszymi bibliotekami, a wersja static pojawi się za dzień lub dwa.

Dostałem informację, że AP26 jest dostępny na 32-bitowego linuxa. Nie wiem jaka jest wydajność, ale w testach zoptymalizowana wersja 32-bitowa chodziła tylko 1.7 raza wolniej od 64-bitowej.

Były jakieś problemy z 64-bitową wersją linuxową. Nowa wersja była wolniejsza od starej. W tej chwili powinna być z powrotem używana stara wersja.

Cytat: sesef w 03 Luty 2009, 11:01
Powinno, ale Troll może miał pecha i akurat wystąpił błąd podczas otwierania SOL19 i mu nie zapisało :P

Gdyby coś takiego się działo, to byłoby to nad wyraz wredne, bo można byłoby znaleźć rozwiązanie i je zgubić.
Tu akurat pewnym zabezpieczeniem jest zapisywanie rozwiązania 2 razy. Jednak to zasiewa we mnie pewien niepokój i zastanawiam się, czy i jakie środki można przedsięwziąć na przyszłość.

Cytat: Troll81 w 03 Luty 2009, 10:10
A co jeśli mi wyszła 19 w pliku sol 15

19 powinno być zapisane 2 razy: w sol15 i w sol19. Czy to zostało wpisane tylko do sol15, a do sol19 nie? To byłoby bardzo dziwne. Tak czy owak podaj to AP19.

Cytat: Mchl w 02 Luty 2009, 02:48
A czy istnieje sposób na sprawdzenie, że dany APn jest takim który ma najmniejszy możliwy znany początek? Widzę, że do AP17 wypisane są już postępy z minimalnymi początkami. Jak można dowieść, że postępu z mniejszym początkiem już nie będzie?

Zgodnie z bardzo rozsądną, ale chyba niemożliwą do udowodnienia, hipotezą, najmniejszy możliwy początek AP-k to najmniejsza liczba pierwsza nie przekraczająca k. Można łatwo udowodnić, że mniejszy być nie może. Natomiast wydaje się, że nie ma innego dowodu, że taki jest osiągalny, niż znalezienie przykładu.

Tak więc dla AP18 i AP19 najmniejszy możliwy początek powinien być równy 19, a dla AP20, AP21, AP22, AP23 23.

Zatem postępy o początku powyżej odpowiednio 19 i 23 są zapewne rekordami tymczasowymi, chociaż ta tymczasowość może być bardzo długa. Natomiast osiągnięcie odpowiednio 19 i 23 wydaje się być bardzo trudne (i na pewno nie można ich znaleźć tym programem, który napisałem - ale napisanie innej wersji, to nie problem, tylko, że liczyłaby latami zanim do czegoś by się doliczyła).

A dowód minimalności początków, które podałem (jak kogoś interesuje)? Przykładowo, jeśli AP19 zaczyna się od 17, to 18-sty wyraz jest podzielny przez 17, jest więc złożony.

Wczoraj (1 lutego 2009) Sebastian Jaworowicz znalazł AP20 o najmniejszym znanym wyrazie początkowym i tym samy pobił rekord z roku 1992.

Tabela rekordów:
http://users.cybercity.dk/~dsl522332/math/aprecords.htm

AP20 znalezione dla s=1,...,15 będzie nowym rekordem, gdyż czym mniejsze s, tym lepszy wynik (mniejszy wyraz początkowy). Także AP20 znalezione przez program AP19, gdyby się takie trafiło, będzie rekordowe, bo to odpowiada s=0. AP20 znalezione dla s=16 może być rekordowe lub nie. Dla s>16 AP20 rekordem nie będzie, więc lepiej użyć tam programu AP21, który pomija część AP20, przez co jest szybszy.

Niestety, czym większe K, tym rzadziej występują AP20. Jednak zakres pozostałych poszukiwań jest na tyle duży, że jest spora szansa na znalezienie kolejnego AP20. Najlepiej obserwować liczbę pojawiających się krótszych AP - po to właśnie zapisuję nawet AP15, żeby widzieć jak dużo postępów znajduje program.

Ogłoszone:
http://tech.groups.yahoo.com/group/primenumbers/message/19838

Trzeba pewnie poczekać paręnaście godzin na uaktualnienie strony z rekordami:
http://users.cybercity.dk/~dsl522332/math/aprecords.htm

Oto wskazówki dla szukających AP21 o minimalnym znanym wyrazie początkowym.

Po pierwsze, skompilować program z Ap21.zip z http://www.math.uni.wroc.pl/~jwr/BaP/ i postępować zgodnie ze wskazówkami w pliku Opis.txt. W razie problemów można zamiast PrimeQ64.h wczytać procedurę z PrimeQ.zip z tegoż katalogu.

Sugeruję, aby na początek brać kolejne s=17,18,...,96 i dla każdego s liczyć K do 10M.

Jeśli ktoś napisze "Biorę s=17", to znaczy, że uruchomi
./ap21 17 1 10000000

Gratulacje, sesef!!!

Wynik jest poprawny, ogłoszę go, jak uzyskam od Ciebie potwierdzenie, że chcesz wystąpić pod swoim nazwiskiem.

W tym układzie, tak jak to napisałem w opisie do programu, AP20 można kontynuować dla s=1,2,...,16

Możesz dalej liczyć s=16, jeśli znajdzie następne AP20, to może ono być rekordem lub nie.

s=17 do 96 należy liczyć programem AP21. Zaraz uruchomię odpowiedni wątek.

Natomiast AP20 wymaga kolejnej rundki. Mamy policzone K=1 do 10M.

To teraz trzeba się zdecydować na kolejny zakres K.

Jeśli ktoś teraz napisze "Biorę s=1, K=10M-XYM", to znaczy, że uruchomi
./ap20 1 10000001 XY000000

Najlepiej, żeby XY było wybrane jednolicie - to samo dla wszystkich s, pewnie sensowne opcje to XY=20, 30, 40 lub 50, zależy jak długie przedziały chcecie mieć i jak często restartować program z nowymi parametrami.

Ale ja się potem zorientowałem, że program działa poprawnie tylko do 1 757 658 938, więc tego nie należy przekraczać.

Cytat: Troll81 w 28 Styczeń 2009, 19:09
no i mam kolejne Ap19

19 528837600 943065709

No to fajnie. Sprawdziłem, że rozwiązanie jest poprawne, ale rekordem niestety nie jest, bo jest gorsze od obu wyników Mariana. O tym decyduje ta trzecia liczba: 943065709 (u Mariana jest 275525353 - czym mniej tym lepiej).

Rekord będzie wtedy, gdy trzecia liczba będzie mniejsza od 275525353 lub gdyby się pojawiło AP20.

No ale AP19 są tu na tyle rzadkie, że warto dać o nich znać na forum nawet jak nie są rekordowe. Niestety, możemy się nimi cieszyć tylko we własnym gronie, bo na zewnątrz liczą się tylko rekordy.

Cytat: Jarek Wróblewski w 23 Styczeń 2009, 06:33
21 stycznia Machloj stracił swój rekord świata (19-wyrazowy postęp arytmetyczny liczb pierwszych o najmniejszym znanym wyrazie początkowym). Nowym rekordzistą w tej kategorii jest Mariusz Szafrański, który brał udział w dalszych poszukiwaniach prowadzonych przez BOINC@Poland.

Z przyczyn technicznych zmienił się adres strony z rekordami. Nowy adres to:

http://users.cybercity.dk/~dsl522332/math/aprecords.htm

Dziś (26 stycznia) Mariusz poprawił swój rekord sprzed pięciu dni.

No dobra, kształtuje mi się takie wyobrażenie.

Każda przewidywalna aplikacja ma, powiedzmy, 3 argumenty liczbowe określające zakres, np.:

./ap20 s KMIN KMAX

Aplikacja produkuje plik z rozwiązaniami. Wielkość WU oraz pliku można praktycznie dowolnie regulować w miarę potrzeby. Ten plik jest dowodem przeprowadzenia obliczeń.

Być może w jednym momencie dobrze byłoby mieć jednocześnie kilka aplikacji. Wtedy można mieć jednocześnie kilka programów, a podmiana programu na inny byłaby mniej bolesna - bo stać by nas było na wsadzenie takiej aplikacji do kwarantanny.

Aplikacje muszą jakoś rozpoznawać, czy dany WU jest ich - ja nie wiem jakie są tu opcje.

Licząc w wąskim gronie można mieć chyba dość duże WU.

Jak rozumiem, TJM, potrzebowałbyś mieć konkretny działający program, żeby zacząć go obudowywać. Trzeba też pewnie ustalić pewne standardy co do nazw plików i aplikacji. Czy to jest łatwo zmienialne?

AP20 jest tu dość dobrym modelowym przykładem. Aplikacja ma dostać 3 parametry jak opisane wyżej, produkuje plik SOL-AP15.TXT i ten plik należy odesłać do weryfikacji.

Jej bliźniaczka, AP21 działa w sposób analogiczny, znaczenie parametrów jest takie samo, plik wynikowy nazywa się tak samo. To oczywiście można łatwo zmieniać.

Wyobraźmy sobie, że w przyszłości dokładamy aplikację TUP19, którą wywołuje się identycznie:
./tup19 s KMIN KMAX
i która też produkuje plik wynikowy, który należy odesłać do serwera.

W zasadzie chyba każdą przyszłą aplikację można wsadzić w ten schemat.

Czy to jest duży problem, zaplanować tak, aby było miejsce dla 3-5 różnych aplikacji jednocześnie?

To chyba z grubsza opis standardów, w które powinno się dać wsadzić każdy program.

Dalszą dyskusję na temat obudowania aplikacji BOINCiem wyniosę do osobnego wątku:
http://www.boincatpoland.org/smf/przetwarzanie-rozproszone/ap20-i-inne-aplikacje-w-boinc/

Mam wątpliwości, czy te programy są do tego celu odpowiednie. A dokładniej, czy przewidywany czas obliczeń uzasadnia inwestowanie czasu w przygotowanie BOINCa. Po znalezieniu AP20 zmieni się zakres dalszych obliczeń. To nie jest program, który może bezmyślnie lecieć latami bez interwencji człowieka. Tu każdy rekord może wymagać zmiany strategii poszukiwań.

Te programy mają bardziej charakter testowy. Ja mam na uwadze program, który mógłby chodzić latami, ale nie jest jeszcze gotowy.

Podstawowe pytanie jest następujące:

Załóżmy, że zainwestujesz czas i uruchomisz to w BOINC (takim dla zamkniętego grona, jak opisałeś). Załóżmy, że po miesiącu zechcemy się wycofać z tych obliczeń i rozpocząć nowe, innym programem. Czy pracę włożoną w przygotowanie automatu trzeba powtórzyć od nowa, czy też można tylko podstawić nową aplikację (+ jakieś kosmetyczne zmiany) i zasuwać dalej innym programem?

Myślę, że inwestowanie dłubaniny w samo AP20 nie jest opłacalne. Ale jeśli miałaby to być maszynka, w której w miarę bezboleśnie można będzie podstawiać nowe aplikacje, to myślę, że warto  to rozważyć.

Cytat: Mchl w 26 Styczeń 2009, 14:40
Tak sobie myślę, czy nie byłoby wam wygodniej zarządzać podziałem przedziałów gdzieś na Wiki?
Łatwiej by było uniknąć pomyłek, bo wszystko by było widoczne w jednym miejscu obok siebie.

Ja zaproponowałem rezerwowanie przedziałów przez posty, bo mi nic mądrzejszego nie przyszło do głowy - nie za bardzo się orientuję, jakie są dostępne możliwości techniczne.

Każde usprawnienie będzie mile widziane.

W pierwszym poście tego wątku zamieszczam statystyki poszukiwań i ranking.

Dzięki za osiągnięcie porozumienia, zgłaszam wynik jako Mariana.

EDIT:

Ogłoszone:
http://tech.groups.yahoo.com/group/primenumbers/message/19836

Powinno się pojawić za paręnaście godzin na stronie z rekordami.

Honorowe zachowanie Trolla tworzy precedens, który możemy stosować w przyszłości jako regułę, zanim jakaś automatyzacja nie pozwoli uniknąć przypadkowego dublowania przedziałów poszukiwań. W razie podwójnego odkrycia rekord należy tylko do tego, kto pierwszy zarezerwował przedział.

Zwracam jednak uwagę, że takie reguły możemy sobie stosować tylko wewnętrznie. Gdyby na drugim końcu świata jakiś inny poszukiwacz, prowadzący niezależne poszukiwania, wcześniej ogłosił to samo lub jakiś inny wynik lepszy od tego rekordu, trudno byłoby coś zrobić, bo liczy się czas ogłoszenia wyniku. Na pocieszenie dodam, że to raczej teoretyczny problem, bo nie wydaje mi się, aby w tej chwili ktoś gonił za tymi konkretnymi rekordami (a przynajmniej nikt nie robi tego skutecznie).

Zdarzyło mi się jednak kiedyś, że znalazłem coś fajnego, a gdy chciałem to ogłosić, okazało się, że ktoś inny znalazł to samo kilka godzin wcześniej. No i wynik był tylko jego.

Opublikowanie wyniku na tym forum należy uznać za jego ogłoszenie. Chcę Ci jednak, Marianie, zwrócić uwagę, że gdyby Troll nie pomylił przedziałów, a znalazł w swoim przedziale wynik lepszy of Twojego, Twój wynik siedzący w komputerze straciłby wartość. Dlatego warto (ale też bez przesady) ogłaszać rekordy możliwie szybko.

Dokładniej, mam na myśli taki scenariusz:

Rekord jest 275955343.

Komputer Mariana znajduje 275525353, ale Marian tego nie ogłasza.

Troll znajduje i ogłasza (ze swojego legalnego przedziału), powiedzmy 222222222 i to jest od tej chwili nowy rekord, a rekord Mariana siedzący w komputerze się przeziębił.

Cytat: RAD-Poland w 25 Styczeń 2009, 19:37
Czytając wypowiedź w wątku AP20 rodzi się pytanie

Czy aplikacja AP26 podprojektu PrimeGrid - AP26 search dokonuje pełnego przeglądu AP10 - AP26 jak wynikałoby z plików wynikowych odsyłanych do projektu, czy też jest skupiona wyłącznie na jak najszybszym odnalezieniu AP26 i dopuszcza pomijanie w wynikach niższych AP.. ?

To drugie. Aplikacja nie pomija AP26 o różnicach dopuszczalnych przez program, ale część krótszych AP pomija.

Szukając AP24 szacowałem, że szanse jego znalezienia są tak świetne, że napisałem program, który część AP24 pomijał, ale nie pomijał żadnego AP25 o różnicy rozważanej przez program. Moje rozumowanie było następujące: Mam na tyle świetne szanse znaleźć AP24, że mogę sobie z nich trochę odpuścić, dostając za to większe prawdopodobieństwo, że trafię na AP25. Ten sam program był użyty potem do znalezienia AP25.

Szukanie AP26 to jednak strasznie trudna sprawa, dlatego program jest nastawiony na maksymalizację szansy znalezienia AP26. Dlatego przepuszcza niektóre AP25 i krótsze. Zysk jest niebanalny - dzięki temu program jest 2 razy szybszy.

Znany jest jeden AP25 - akurat on jest na drodze programu i został znaleziony.

Znanych jest też 9 AP24, z czego 4 są na drodze programu, a 5 nie. 2 zostały już znalezione. Na razie nie znaleziono nowego AP24.

Cytat: sesef w 25 Styczeń 2009, 17:10
PrimeGrid znalazł 324 AP20, nie dobrał by czegoś mniejszego z tych znalezionych??

Nie wiem, pewnie to zostanie w którymś momencie sprawdzone. Jednak szanse na to są raczej małe. Program AP26 jest nakierowany na szukanie czegoś innego. Szanse, że konkretny AP20 znaleziony tym programem będzie miał najmniejszy znany początek, oceniam na około 1 : 100 000. To jest możliwe, ale mało prawdopodobne. Szanse na to, że wśród dotąd znalezionych AP20 jest nowy rekord to ułamek procenta.

Niesamowite, rekord pobity dosłownie o włos. Gratulacje.

Szczerze mówiąc, trochę jestem w kropce, bo sytuacja jest dość nietypowa. Z jednej strony to PBT_marian_boss zarezerwował ten przedział. Z drugiej to Troll81 jako pierwszy to ogłosił, przy czym w działaniu Trolla81 nie należy dopatrywać się złej woli, tylko zwykłą nieuwagę.

Jeśli nie macie innych sugestii, proponuję rozwiązanie kompromisowe: Podać nazwiska obu kolegów (w kolejności alfabetycznej). Jeśli obaj na to przystaniecie, ogłoszę wynik.

Cytat: sesef w 25 Styczeń 2009, 17:10
Czy pogrubiony AP19 ma się jakoś do naszych poszukiwać AP19??

Nie, bo AP19, które znajduje ten program, mają większy wyraz początkowy i nie ustanawiają rekordu. Dlatego nazwałem ten program AP20, ponieważ on w zakresie swoich poszukiwań nie przepuszcza żadnego AP20, natomiast może pominąć niektóre AP19 - one nas nie interesują. Dzięki temu, że pozwalamy sobie na przepuszczanie niektórych AP19, program działa szybciej.

AP19 mają natomiast walor psychologiczny - znajdujemy coś bliskiego AP20. Ponadto, statystycznie rzecz biorąc, jest mało prawdopodobne, aby znaleźć dużo AP19 nie znajdując żadnego AP20.

21 stycznia Machloj stracił swój rekord świata (19-wyrazowy postęp arytmetyczny liczb pierwszych o najmniejszym znanym wyrazie początkowym). Nowym rekordzistą w tej kategorii jest Mariusz Szafrański, który brał udział w dalszych poszukiwaniach prowadzonych przez BOINC@Poland.

Z przyczyn technicznych zmienił się adres strony z rekordami. Nowy adres to:

http://users.cybercity.dk/~dsl522332/math/aprecords.htm

Chyba wyjaśniła się tajemnica cudownej siły 64 bitów w programie AP26.

Otóż kompilatory 32-bitowe mają kompletnie zrąbane dzielenie liczb 64-bitowych przez małe liczby ustalone w kodzie programu. Można dostać kilkukrotne przebicie prędkości wykonując to dzielenie w inny, bardzo prosty, sposób. Dla mnie jest to szokujące, że kompilator nie umie wydajnie skompilować elementarnej operacji typu n%101 i że robiąc to dzielenie po swojemu (żadnych asemblerów, czyste C !!!), można przyspieszyć program kilkakrotnie.

Dokonałem odpowiedniej zmiany w programie i Geoff Reynolds twierdzi, że teraz stosunek prędkości 64:32 bitów jest w okolicach 1,7. To jest już całkiem sensowne i moim zdaniem jest spora szansa, że w przyszłości AP26 ruszy też na 32 bitach.

Zdaje się, że wersja zoptymalizowana na 32 bity jest u Geoffa w katalogu z programem. Może ktoś się chce pobawić w testowanie?

Ogłoszone:

http://tech.groups.yahoo.com/group/primenumbers/message/19826

Gratulacje! Zweryfikowałem, że to poprawne rozwiązanie.

Napisz, czy mam to zgłosić anonimowo, pod Twoim forumowym nickiem, czy też podasz swoje imię i nazwisko.

Pragnę Cię w jednym rozczarować: Moim zdaniem Twoje odkrycie nie zachęca, a wręcz zniechęca do dalszych poszukiwań AP19 tym konkretnym programem. Otóż wszyscy widzimy jak trudno jest znaleźć jakiekolwiek AP19, a tu jeszcze chodzi o znalezienie AP19 mającego najmniejszy znany początek.

Ten program daje AP o początku z przedziału (z grubsza) do 1.4G. Machloj odkrył AP19 z początkiem około 1.3G, więc każde nowe AP19 miało świetną szansę znaleźć się poniżej tego wyniku. Ty zaś przyblokowałeś dalsze poszukiwania znajdując AP19 z początkiem 275M, co oznacza, że każde kolejne AP19 ma około 20% szansy znaleźć się poniżej tego progu.

W moim odczuciu najsensowniej jest zawiesić AP19 (zapisując przeszukany zakres) i przejść do AP20.

Oczywiście każdy ma prawo kontynuować AP19, ale uprzedzam, że tylko średnio co piąte AP19 będzie rekordem.

Nie robiłem testów, ale pisząc program założyłem, że w miarę możliwości program powinien korzystać z cache procesora i nie ruszać RAM-u.

Mogę sobie więc wyobrazić, że jest jakaś krytyczna wartość cache procesora, poniżej której program wchodzi do RAM-u i spowalnia.

To tylko teoretyczne przypuszczenia, nie poparte żadnymi eksperymentami.

Same dane, które są w wyraźnie zadeklarowanych tablicach, jak liczyłem, powinny się mieścić w jakichś 120kb.
Nie wiem, ile zajmuje reszta programu, ani też nie bardzo wiem jak mierzyć tak małe użycie pamięci. Być może także sam system operacyjny, czy inne uruchomione programy jakoś wpływają na ilość cache dostępnego dla samego programu - to tylko moje naiwne wyobrażenia, dokładnie się na tym nie znam.

Cytat: Szopler w 19 Styczeń 2009, 17:17
Faktycznie nie powinno mieć to wpływu... W takim razie nie wiem co ma. Ubuntu na pewno 64 bit.

Na pewno masz 64 bity. Na 32 bitach musiałbyś proca podkręcić do 5GHz w ciekłym azocie, żeby mieć szansę się wyrobić z WU w godzinę, a Ty się wyrabiałeś poniżej 50 minut (co wymaga przynajmniej 6GHz na 32 bitach).

Cytat: TJM w 19 Styczeń 2009, 16:39
Niby jakim cudem plikopartycja miałaby zwalniać obliczenia ? Tak samo dobry nośnik danych jak każdy inny.

Inna sprawa, że programowi nośnik danych nie jest zbyt potrzebny. Wpisuje do pliku linijkę co kilka sekund, a jak ma dość cache procesora, to nawet RAM-u nie rusza.

Jeśli obecny program nie znajdzie lepszego AP19 (nie krótszego, bo wszystkie AP19 mają po 19 wyrazów, tylko mającego mniejszy wyraz początkowy), to wydaje się mało sensowne kontynuowanie poszukiwań w/g tej samej strategii. Wtedy musiałbym napisać inny program, nieco inaczej skonstruowany. Obecny rekord na pewno jest możliwy do pobicia, to jest tylko kwestia czasu, być może sporego. Całkowity przebieg obecnego programu AP19 jest zbyt krótki, aby wartało robić specjalne bajery w celu jego uruchomienia.

Są jednak zagadnienia, które wymagają tak dużego nakładu CPU, że zainwestowanie czasu ludzkiego w przygotowanie obliczeń jest opłacalne. Ja jestem w stanie napisać programy do takich zagadnień, jednak na początek zaproponowałem programy o krótszym przebiegu, żebyśmy zobaczyli na czym zabawa polega i jakie problemy generuje.

Co do AP20, to przed przeliczeniem s do 46, K do 10,000,000, nie ma sensu nic dalej planować, bo a nuż ten przebieg coś znajdzie i zupełnie zmieni zakres dalszych sensownych poszukiwań.

Gdybyś Ty lub ktokolwiek inny chciał wkładać wysiłek w dostosowywaniu programu do CUDA lub innych cudów, to ja musiałbym najpierw przygotować program, który w zamierzeniu miałby odpowiednio długi czas obliczeń.

Póki co, ktoś tam napisał, że WU mu chodzi około 800 sekund.

Te 432 sekundy, to było bez optymalizacji Geoffa, które zaoszczędziły ok. 5%.

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 47
model name      : AMD Athlon(tm) 64 Processor 3000+
stepping        : 2
cpu MHz         : 1809.283
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni
bogomips        : 3620.21
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

EDIT:

Idę spać. Jak rozumiem, na razie tylko Szopler liczył nowym programem WU PrimeGrida. Jak będą dokładne dane od większej liczby użytkowników, to mogę coś rano napisać na forum PrimeGrida.

A co do sesefa, to uważam, że wykonał kawał dobrej roboty i powinien dostać za to jakiś forumowy medal (przynajmniej coś takiego jak Machloj i ja za AP19).

EDIT:

John i Rytis z PrimeGrida przyznali, że błędnie zinterpretowali pomiar prędkości AP26 linux/Win i że w rzeczywistości wydajność jest porównywalna (Win wydaje się być nieznacznie wolniejsza). Można więc spokojnie liczyć pod Win64 bez obawy o marnowanie mocy.

Wersja 32-bitowa jest 8 razy wolniejsza i nie będzie udostępniona publicznie (i się z tym zgadzam, bo to byłoby do pewnego stopnia marnowanie zasobów, Sita mają przebitkę 2:1, a LLR 1:1).

Rytis napisał:
Augustine, while we are not going to release 32bit applications for AP26, it is possible to compile and run your own if you'd want to - the source code is public.

Czyli, ja rozumiem, że jak ktoś się uprze i mimo wszystko chce liczyć na 32-bitach, to niech sobie sam kompiluje. Zwracam jednak uwagę, że WU na 32 bitach zamiast 15 minut chodziłby ok. 2 godzin, za 13.61 kredytu.

W wątku
http://www.primegrid.com/forum_thread.php?id=1179
jest też opis, co zrobić, jak się ma 32-bitowy system na 64-bitowym procku. Bierze się jakieś Wubi i chodzi jak na 64 bitach - ja się na tym kompletnie nie znam.

Cytat: Szopler w 18 Styczeń 2009, 19:58
Różnie i różniście... 13 do 17 minut zależnie od obłożenia kompa innymi zadaniami ;)

No to nie wiem, w czym problem.

Patrzę tu:

http://www.primegrid.com/show_host_detail.php?hostid=80069

Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40 GHz (Ty masz zdaje się 2.50), czasy około 12 minut.
To wcale nie jesteś wolniejszy 2 razy.

Tutaj:

http://www.primegrid.com/show_host_detail.php?hostid=90454

AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
leci koło 16 minut na próbkę.

Z tego, co mi się wydawało grzebiąc po takich danych, to rzędu 15 minut na próbkę jest całkiem sensowne.

Jak rozumiem, próbek powinno się na raz liczyć tyle, ile jest rdzeni - pewnie ktoś z Was wie jak to działa.

W każdym razie 100 próbek na dobę na rdzeń wydaje się całkiem sensowne.

Geoff pisał na forum PrimeGrida:

On my C2D at 2.66GHz in 64-bit mode the test range took 303 seconds with the original GMP PrimeQ() and 287 seconds with the replacement long double PrimeQ(), so the replacement doesn't make a huge difference.

Czyli rzędu 5 minut na przedział testowy (u Geoffa na linuxie), a próbka to 3 takie przedziały (czasem o parę procent więcej).

Czyli na gołe gigaherce, to paręnaście minut na próbkę na 2-3GHz jest w/g mnie OK, a że różne procesory mogą sie różnie zachowywać, to inna sprawa. Może jakoś gra tu jeszcze wersja systemu operacyjnego lub powiązanie kompilacji z procesorem - ja się już na takich subtelnościach nie znam.

Cytat: Szopler w 18 Styczeń 2009, 19:58
http://www.primegrid.com/results.php?userid=27038

No access

Rytis napisał:

Well, for some reason Windows versions is twice as slow comparing with Linux...

Czy to prawda? Jak się mają do tego testy prędkości?

Cytat: sesef w 17 Styczeń 2009, 18:54

Cytat: Jarek Wróblewski w 17 Styczeń 2009, 18:39
U mnie wersja dummy liczyła 266 sekund, a oryginalna z GMP 290 sekund na

Taki wynik został uzyskany na linuxie z tego co rozumiem??

Co do procesora zegar w zegar to daje 10% ale jakby zrobić dokładne testy do będzie więcej nawet wyłączając temu intelowi 1 rdzeń tak żeby miały "równe szanse" to Intel pochłonie tego mojego AMD więc porównując moje wyniki nie jest ogólnie tak tragicznie.

Tak, na linuxie. Ten Intel ma jeden rdzeń (formalnie ma dwa, ale z jakichś powodów administratorzy sieci włączyli tylko jeden). Nawet, gdyby miał dwa rdzenie, to sam program z tego nie korzysta (chyba, że się uruchomi dwa programy rozdzielając pracę).

Inne testy oryginalnego programu pod linuxem 64-bitowym:
731 sekund -  Intel(R) Pentium(R) D  CPU 2.66GHz (Pentium 805)
432 sekundy - AMD Athlon(tm) 64 Processor 3000+;  cpu MHz : 1809.303

Zwróć uwagę, że Gigaherce nie mówią wszystkiego - typ procesora i jego wady w przetwarzaniu różnych niewinnych operacji mogą wszystko zdominować, np. Pentium 805 miał wydajność bardzo słabą mimo sensownych Gigaherców i to już od kompilacji nie zależało, tylko od wad samego procesora. Natomiast ten nowy Intel to jedna z nowszych generacji procesorów, pewnie ma udoskonalone wykonywanie różnych instrukcji.

A co byś powiedział na takie cacko?
4-rdzeniowe Itanium 2, 1.4 GHz.
Super sprawa. Prawda? Raanan Chermoni zaczynał obliczenia na takich komputerach zanim dostał coś lepszego. Aż gębę rozdziawiłem ze zdziwienia, jaką to ma wydajność! Każdy rdzeń był 6.7 raza wolniejszy od rzeczonego wyżej Athlona, czyli był wart 0.15 Athlona.
4-rdzeniowy Itanium był w sumie wart 0.6 Athlona, bo akurat miał skopane wykonywanie jakichś instrukcji.

Cytat: sesef w 17 Styczeń 2009, 17:43
Nie bardzo rozumiem o co chodzi z DUMMY.

Skompilowałem taką wersje, przeliczenie testowego zakresu zajęło 6 min a normalna wersja działa 6 min 11 sec czyli te 11 sec schodzi na testowanie pierwszości (+ ta validacja która również testuje pierwszość:P) ??

Dziwne, że tylko 11 sekund. W każdym razie to dowodzi, że testy pierwszości nie są czasochłonne.

Validacja nic nie testuje, bo DUMMY nie znajduje żadnych ciągów. Poza tym nawet w normalnym programie validacja w całym przedziale testowym powinna pochłaniać niezauważalny ułamek sekundy.

Cytat: sesef w 17 Styczeń 2009, 17:43
Dobra intel ściągnięty.
DUMMY przeliczył w 313 sec (5:13), co nadal nie zmienia faktu że to cholernie wolno :(

U mnie wersja dummy liczyła 266 sekund, a oryginalna z GMP 290 sekund na
Intel(R) Core(TM)2 Duo CPU  E8400  @ 3.00GHz.
U Ciebie jest nieco wolniejszy procesor (o 10%), a poza tym to może zależeć od parametrów procesora, których nie sposób przewidzieć. Czas w granicach 5-6 minut jest już całkiem sensowny. Trzeba by to przetestować na różnych procesorach, żeby naprawdę ocenić wydajność.

Tu jest podstawowy problem, żeby w ogóle cokolwiek skompilować, co chodzi w miarę sensownie, a nie bić rekordy superprędkości - przynajmniej w pierwszej wersji. Honza z forum PrimeGrida miał 15 minut.

Moja sugestia:
Spróbuj skompilować najwydajniej jak Ci się udaje poprawnie działająca wersję programu z BOINC i napisz o tym na forum PrimeGrida, udostępniając skompilowany program do testów. Niech już oni sobie ocenią, czy im na początek taka prędkość pasuje, czy chcą czekać na coś lepszego.

Skompiluj i przetestuj wersję z DUMMY.

Wsadzasz

#define DUMMY

gdzieś na początku programu. To niczego nie wydrukuje, ale pokaże czas przebiegu oprócz testowania pierwszości (DUMMY bez testowania oznacza wszystkie liczby jako złożone). Nie wiemy, co to GMP robi - jeżeli sobie umyśliło testować pierwszość w stylu 32-bitowym, to może to zżerać dużo czasu.

Dzięki temu będzie wiadomo, czy testowanie pierwszości jest kompilowane w miarę wydajnie. U mnie testowanie pierwszości zajęło 8.3 %.

Wersji DUMMY nie przyspieszysz już inaczej niż kompilacją.

Różnica czasu wersji prawdziwej i DUMMY to czas spędzony na testowanie pierwszości. Przy zachowaniu proporcji powinno to być u Ciebie 50-51 sekund.

Cytat: sesef w 17 Styczeń 2009, 16:26
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.

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.