Tworzenie projektu... czyli powstanie i ewolucja Enigma@Home

[TJM]

Jest jeszcze szansa na patch źródeł - aktualnie testuję poprawkę jednej z funkcji i mam już zysk 4% w benchmarku względem poprzedniej najszybszej, po zmianie w 2 innych powinno jeszcze trochę pójść do przodu. Sęk w tym że to już dość poważna ingerencja i muszę przeliczyć kilkadziesiąt testowych zadań żeby stwierdzić czy wyniki są ok.

[maxim]

A na windowsa X32 i X64 jakas dobra optymalka to wyszla ? Powiedzcie no :) Chodzi mi o optymalke pod C2D i C2Q :D

Pozdro

[Troll81]

ja tam czekam na oficjalną optymalkę pod athlony :D

[buninek]

wstawiłem pod win na A x2 4600 i A3800.... zobaczę co będzie

Jeśli wszystko będzie ok, tzn. TJM nie będzie zgłaszał jakiś problemów to możesz wrzucić na
semprony. Masz tam ich małą gromadkę. Oprócz athlona xp.

[TJM]

Przed i po wczorajszych zmianach w kodzie. Różnica tym większa im słabszy CPU, tutaj A64 2.2GHz.

[Mori]

Na czyim kodzie, pod jakim systemem TJM?

[Bober]

Dziwne, bo pliki niby są ściagane z drugiego serwera. Trzeba coś innego wymyślić, bo pliki ze statsami ciągle rosną i prędzej czy później od samego transferu wygenerowanego przez nie braknie limitu.

Formula Boinc ma najświeższe wyniki, może pobrała...

Tu http://statsnstones.tswb.org/Team.aspx?projid=53 staty się aktualizują.

[KrzychuP]

na boincstats chyba zastój statów z Enigmy

[Mori]

nowa wersja pod win (athlon64, amd x2) zmiana w hillclimb.c
http://www.adrive.com/public/32b92489374d4c8faccd3c04b73aa8650ddcda49045569608cb08340e3c5261d.html

raczej przyniesie efekt placebo (wynik benchmarku bez zmian)

Jutro obiecuję podmienić, jak wrócę z uczelni. Zobaczymy, czy coś zmieni, czy raczej nie. No, ale zaszkodzić raczej nie zaszkodzi, więc... =]

Właśnie zupdate'owałem. awgly100 (0) było w momencie update'u przeliczone w 70%, ale w kolejce czeka następne (0) i (1), więc zobaczymy, czy będzie widać różnicę.

PS. TJM, tak patrzę na swojego hosta i Twojego ze screena i ciągle nie rozumiem, czemu liczę w podobnym czasie, a chcę więcej -- krótko mówiąc, skąd masz kod, który liczy tak szybko :P

[Troll81]

bo TJM jest tu szefem :D

[TJM]

PS. TJM, tak patrzę na swojego hosta i Twojego ze screena i ciągle nie rozumiem, czemu liczę w podobnym czasie, a chcę więcej -- krótko mówiąc, skąd masz kod, który liczy tak szybko :P

Twój host ma wyższy benchmark (nic dziwnego, odkąd pamiętam na linuksie zazwyczaj były gorsze), co jak widać nie przekłada się wcale na wydajność. Tego kodu nie nazwałbym szybkim, popatrz na to - to jest dopiero szybkość http://www.enigmaathome.net/results.php?hostid=1369

[Mori]

Twój host ma wyższy benchmark (nic dziwnego, odkąd pamiętam na linuksie zazwyczaj były gorsze), co jak widać nie przekłada się wcale na wydajność. Tego kodu nie nazwałbym szybkim, popatrz na to - to jest dopiero szybkość http://www.enigmaathome.net/results.php?hostid=1369

Ale TJM - mówisz, że 2.2GHz. Ja mam, po OC, 2.3GHz. Tego właśnie pojąć nie mogę. Chociaż w sumie jak sprawdzam czasy, to jesteś z 50-100 sekund do tyłu (tyle, że to dość niewiele).

[TJM]

Twój host ma wyższy benchmark (nic dziwnego, odkąd pamiętam na linuksie zazwyczaj były gorsze), co jak widać nie przekłada się wcale na wydajność. Tego kodu nie nazwałbym szybkim, popatrz na to - to jest dopiero szybkość http://www.enigmaathome.net/results.php?hostid=1369

Ale TJM - mówisz, że 2.2GHz. Ja mam, po OC, 2.3GHz. Tego właśnie pojąć nie mogę. Chociaż w sumie jak sprawdzam czasy, to jesteś z 50-100 sekund do tyłu (tyle, że to dość niewiele).

No ale co w tym niby dziwnego ? Host stoi na linuksie, w ogóle nie dotykany przez większość czasu (maszyna wyłącznie do kompilacji i testów); a że wydajność w BOINCowym benchmarku ma zaniżoną to wina BOINCa. Widocznie moja aplikacja jest ciut szybsza albo to system robi taką różnicę.

[3Rni]

widze ze lata optymalka oki doki, wiec wrzucam na całe moje ustrojstwo AMDekowe..procz XP choc kusi mnie tez XP zeby im dac :D

[TJM]

XPkowi też można zapodać, wzrost prędkości jest podobny.

[3Rni]

XPkowi też można zapodać, wzrost prędkości jest podobny.

dobra wale na całe AMD moje.... jutro ocenie jaki wzrosło :)
ahoj

[buninek]

TJM próbowałem takich oto wersji gcc 4.3.2, 3.4.6, 3.3.6.
Mowa o testach pod linuksem i amd x2@2700 .
wyniki benchmarków i najlepszych kompilacji
4.3.2 - 4:17
3.4.6 - 2:59
3.3.6 - słabo nawet nie zapisywałem

mała uwaga 4.3.2 kompilowane na raty tzn. bez flagi "fschedule-insn"  hillclimb.c i ic.c (błedy)
i to tylko przy mcpu=k8 inne mcpu np. pentium4, nocona oki.
Wersja 3.3.6 może być najbardziej optymalna do starszych wersji k-3, duron i athlon-xp.
Mhm. Mało już takich komputerów przelicza.

wynik aplikacji windowsowej pod win xp (xen)
3.4.2 - 4:05

[TJM]

Jeśli masz możliwość, zobacz jeszcze z wersją 3.2. Jeśli znajdę dysk na którym miałem stary dysk do kompilacji to może też sprawdzę - z tego co pamiętam z ubiegłorocznych testów, 3.2 produkował najszybszy kod.

[buninek]

Spróbuję. Choć taki downgrade jest niemożliwy na dystrybucjach, których na codzień używam.
Problem jest w x86_64. Choć mam kilka wirtualnych systemów x86.
Jak wspominałem całem szczęście, że ocalało pld ac, którego nie uruchamiałem od ponad 2 lat
a w sumie jest już zamrożone. Mimo wszystko pakiety pięknie się instalują.
Bo na ten przykład próba zbudowania mingw z gcc 3.4 ze speca w pld th skończyła się błędami.
Ten spec jest sprzed dobrych 2 lat. Wszystkie pakiety mam w najnowszych wersjach.

EDIT:
Próbowałem zbudować gcc-3.2 ze speca (rok 2003) i kiszka.
Ponowny test na gcc 3.3.6 i wyniki na poziomie nieoptymalizowanej aplikacji. Bardzo słabo 5:06.
CentOS 3.9 zawiera gcc 3.2.

[TJM]

Co rozumiesz przez 'kiszka' ? Nie kompiluje się, czy wyniki są słabe ?
Kiedyś robiliśmy już testy i wtedy właśnie exeki zbudowane pod gcc 3.2 były zdecydowanie najszybsze.

Btw, wczoraj (a w zasadzie już dziś) upgrejdnąłem cały soft serwera do najnowszej wersji. Dajcie cynk jakby co nawet o najmniejszych bugach, mając najnowszą wersję najłatwiej wyżebrać poprawki od dev-teamu więc w razie czego na bugfixy pewnie nie trzeba będzie zbyt długo czekać.

EDIT: dziwny bug - db_error przy odpowiadaniu na posty, na które nikt nie odpowiadał przez kilka dni - nie znikł, mimo że to już któryś z rzędu upgrade odkąd ten błąd się pojawił. Sprawę tego buga studiowało już parę osób i na razie nie wiadomo skąd to się bierze.

EDIT2: padam na ryj więc idę w kimono, w razie poważnych problemów mail na podany w innym temacie adres powinien mnie przebudzić  :closedeyes:

[buninek]

kiszka - nie udała się instalacja gcc-3.2 pod pld.
Cóż rozwiązałem to instalując centosa na virtualce i to nawet w wersji 64 bit.
Owszem pod gcc-3.2 się kompiluje, tylko znów jest problem z '-fschedule-insns' i cpu=athlon64. Tym razem plik 'key.c'.
Co inna wersja gcc to jakieś nowe kwiatki. >:(
Testy wydajnościowe zostawię już na jutro. No, no to już "dziś". :)

Faktycznie coś innaczej wygląda cała strona. Mhm. Ja to i tak głównie tam zaglądam za pomocą elinks (txt browser). :D
EDIT:
Przetestowałem gcc-3.2.3. Musi mieć powera.
Kompilowane bez fschedule-insns -  3:59
Częściowo z fschedule-insns - 3:03. Żeby tak poszło wszystko z tą kluczową flagą byłby napewno najlepszy wynik.

[TJM]

Pokaż co tam za błąd wyskakuje, może trzeba jakąś drobną poprawkę w źródle machnąć.

Jeśli chcesz jeszcze większej wydajności: zmieniony nieco score.c http://tjm.boo.pl/enigma/score.zip - to wersja tylko dla linuksa, windowsową mogę jutro uploadnąć bo została na innym kompie. Wzrost wydajności jest różny, najbardziej zauważalny na słabszych maszynach.

[Mori]

Update'uj, update'uj xD

PS. Takie coś dzisiaj na server_status:
Workunits waiting for deletion   2
Results waiting for deletion   2

Czemu one zostają usunięte?

[buninek]

Pokaż co tam za błąd wyskakuje, może trzeba jakąś drobną poprawkę w źródle machnąć.

logi są tu:
http://www.adrive.com/public/ebec4711d50db948bc21738b6ef5e513545e99dd44882865cf128f42b87b0339.html
Błędy dotyczą dwóch plików key.c i stecker.c.
Może one jednak nie mają żadnego wpływu na wydajność aplikacji.

[TJM]

Update'uj, update'uj xD

PS. Takie coś dzisiaj na server_status:
Workunits waiting for deletion   2
Results waiting for deletion   2

Czemu one zostają usunięte?

Wszystkie przetworzone rezultaty są usuwane, ostatnia rzecz którą bym chciał na serwerze to miliony plików w jednym katalogu

logi są tu:
http://www.adrive.com/public/ebec4711d50db948bc21738b6ef5e513545e99dd44882865cf128f42b87b0339.html
Błędy dotyczą dwóch plików key.c i stecker.c.
Może one jednak nie mają żadnego wpływu na wydajność aplikacji.

Największy wpływ na wydajność mają pliki hillclimb.c (główna pętla) i score.c gdzie są funkcje wywoływane bardzo często.
Dziwna sprawa bo u mnie na takim gcc: gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) teoretycznie wszystko się kompiluje, ale brakuje w nim z kolei flag dla nowszych procesorów.

[buninek]

Dziwna sprawa bo u mnie na takim gcc: gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk) teoretycznie wszystko się kompiluje, ale brakuje w nim z kolei flag dla nowszych procesorów.

ważne są również "małe" numery wersji
moja to dokładnie gcc 3.2.3-59
Owszem sprawdziłem uzywając gcc-3.4, te pliki nie mają żadnego wpływu na wydajność. Mowa o key.c i stecker.c.

Jeśli chcesz jeszcze większej wydajności: zmieniony nieco score.c http://tjm.boo.pl/enigma/score.zip - to wersja tylko dla linuksa, windowsową mogę jutro uploadnąć bo została na innym kompie. Wzrost wydajności jest różny, najbardziej zauważalny na słabszych maszynach.

Dziwne. U mnie nowy plik score.c zmniejsza wydajność.
najlepszy benchmark to    2:59 (gcc 3.4)
z nowym score.c         3:15-3:17

[TJM]

No to właśnie dziwne i na różnych procesorach/kompilatorach różnie się zachowuje skompilowany program.
Później zrobię jeszcze jedną wersję która powinna działać szybciej na tych procesorach, na których poprzedni score.c działa wolniej. EDIT: chociaż obecna wersja nie ma sensu, bo zysk prędkości jest na granicy błędu pomiarowego.

[TJM]

Przedpremierowa wersja nowego skryptu:

http://www.enigmaathome.net/show_topuser.php

za chwilę taki sam będzie dla teamów, jak tylko skończę w tym drobną kosmetykę.

EDIT:
http://www.enigmaathome.net/show_topteam.php

[TJM]

Od dziś serwer śledzi najlepsze wyniki użytkowników, można zobaczyć na swojej stronie http://www.enigmaathome.net/home.php
Nowe dodawane są w razie potrzeby (wyższy score) w czasie rzeczywistym, stare są przelukiwane według id usera, więc najszybciej będą mieli uaktualnione ci na początku listy. Trochę to jednak potrwa, bo wszystkich rezultatów jest prawie 2,2 miliona  :)

[buninek]

Fajne te wszystkie nowe staty. :)

Zmienił się u mnie claimed/granted.
Czyżby to wynik nowej kalibracji?
Druga sprawa bufor wu. Od wczoraj liczę na bieżąco. Nie pobiera dodatkowych zadań!! >:(

[TJM]

W bazie wszystko z twoim hostem ok, jedynie average turnaround bardzo niski - 0.06 dnia, co potwierdza to o czym piszesz. Nie zmieniałeś ustawień bufora ?

Ratio claimed/granted na pewno się będzie powoli zmieniać, bo kredyty lekko urosły i nadal rosną.


EDIT: update dwóch nowych pól z uwzględnieniem starych zadań trwa od 5 do 30 minut dla jednego użytkownika, zależnie od tego ile ich poprzeliczał - w takim tempie to do końca miesiąca może serwer zdąży wszystkim uaktualnić  :D

[Troll81]

Jako że już się troszkę pogubiłem. Czy mógłbyś podać linka do najnowszej wersji optymalki pod Athlona 64 x2  na sockecie 939?

[Mori]

Chyba ta jest ostatnią oficjalnie przez buninka wydaną: http://www.boincatpoland.org/smf/index.php/topic,1216.msg46658.html#msg46658 -- w każdym razie ja tej używam.

[buninek]

W bazie wszystko z twoim hostem ok, jedynie average turnaround bardzo niski - 0.06 dnia, co potwierdza to o czym piszesz. Nie zmieniałeś ustawień bufora ?

Jedynie go zwiększyłem z minimum 0.25 na 1/dzień.
Bufor pomałuuu się wypełnia. Mam 1wu w zapasie.

Ściągam, instaluję rózne retro-dystrybucje i kompiluję źródła enigmy za pomocą gcc.
Generalnie wyniki aplikacji kompilowanych wersjami gcc 3.2.3, 3.3.6 i 3.4.6 są na styku (2-20s)
Bywają i takie przypadki:
wersja gcc 3.4.6 (Arch Linux x86_64) - wynik benchmarku 2:59
wersja gcc 3.4.6 (CentOS 4.7 x86_64) - 3:22.
Duża rozbieżność. Wersje 4.x.x słabiutko od 4:32 do 5:05.

[Troll81]

no a czy będzie jakaś nowa wersja pod athlony??

[emik]

Od dziś serwer śledzi najlepsze wyniki użytkowników, można zobaczyć na swojej stronie http://www.enigmaathome.net/home.php
Nowe dodawane są w razie potrzeby (wyższy score) w czasie rzeczywistym, stare są przelukiwane według id usera, więc najszybciej będą mieli uaktualnione ci na początku listy. Trochę to jednak potrwa, bo wszystkich rezultatów jest prawie 2,2 miliona  :)

moje:

hceyz72 top score   1768501
awgly100 top score   2028061

[TJM]

W bazie wszystko z twoim hostem ok, jedynie average turnaround bardzo niski - 0.06 dnia, co potwierdza to o czym piszesz. Nie zmieniałeś ustawień bufora ?

Jedynie go zwiększyłem z minimum 0.25 na 1/dzień.
Bufor pomałuuu się wypełnia. Mam 1wu w zapasie.

Hm a luknij jeszcze w logi ile sekud żąda twój host. Może problem leży w schedulerze projektu, w końcu po dużym updejcie do najnowszej wersji jakieś błędy muszą być :D


Poczytałem ostatnio trochę o optymalizowaniu źródeł pod różne procesory, z tego co widzę teraz patrząc w źródła enigmy, progs jest szybszy na procach Intela ponieważ został tak napisany - konstrukcja programu w połączeniu z kompilatorem Intela daje np. możliwość równoległego wykonywania niektórych instrukcji w pętlach.

Najgorsze przy kompilowaniu nowych wersji jest to, że często poprawiając coś dla jednego procesora psuje się jednocześnie wyniki na innych, tak więc ewentualne optymalizacje się 'rozgałęziają'. Na dodatek benchmark wypadałoby lekko rozszerzyć, tzn umieścić w nim dwa ciphertexty - krótki i długi. To dlatego, że niektóre zmiany na pierwszy rzut oka nic nie dają w benchmarku, a przy przeliczaniu workunitów z dłuższymi ciphertextami może się okazać, że czas przeliczania spadnie nawet o kilkanaście procent. Na odwrót też to działa - da się uzyskać pozorny wzrost wydajności przy krótkich tekstach, który przy dłuższych zniknie.

[Troll81]

Czyli mam rozumieć że jako user athlona (mój okręt flagowy) mam liczyć na efekt placebo z ostatniej wydanej oficjalnie optymalki??

[TJM]

Efekt na pewno lepszy jest niż placebo, gdzieś tu w tym chaosie exeków i buildów na poprzednich stronach były takie, które skracały gdzieś o 10% czas przeliczania w stosunku do poprzedniej aplikacji.
Pewnie jeszcze się pojawią jakieś poprawki, najlepiej byłoby zaprosić do współpracy kogoś, kto się na tym zna - ja się muszę na bieżąco uczyć dłubiąc w źródłach, podejrzewam, że jakiś grandmaster szybko by coś wymyślił.

[buninek]

Hm a luknij jeszcze w logi ile sekud żąda twój host. Może problem leży w schedulerze projektu, w końcu po dużym updejcie do najnowszej wersji jakieś błędy muszą być :D

Sending scheduler request: To fetch work.  Requesting 7978 seconds of work, reporting 0 completed tasks
...
Sending scheduler request: To fetch work.  Requesting 12147 seconds of work, reporting 0 completed tasks

Z tym, że mam ustawiony update projektu co 1h.
EDIT:
sched_request_www.enigmaathome.net.xml
     <duration_correction_factor>0.443998</duration_correction_factor>
W logach jeszcze coś takiego
[error] Couldn't parse statistics_www.enigmaathome.net.xml

Czyli mam rozumieć że jako user athlona (mój okręt flagowy) mam liczyć na efekt placebo z ostatniej wydanej oficjalnie optymalki??

pewnie cóś przyśpieszy
Tak jak pisze TJM, trzeba osoby, która pogrzebie w źródłach. Ja tylko się bawię kompilacją.