Poprawiłem dziś dość poważny bug, który bezczelnie powodował, że niektóre zadania nigdy nie miały chęci się pobierać a w innych czasami znienacka wskakiwały validation errory. Wszystko przez konwersję z długich ciągów liczb na ciągi liczbowe i z powrotem, jedna z funkcji miała błąd przez co niektóre ciągi liczb były kodowane z błędem.

Takie rozwiązanie byłby najprostsze, ale wtedy następuje 1 problem mianowicie checkpointy, chyba że jesteś w stanie wygenerować wu, które da się podzielić na ~5k mniejszych i na tyle długich żeby np taki pentium III 800-1000 mhz liczył takie jedno małe WU koło minuty.

BTW. Większych zakresów liczbowych niż 32 bit w enigmie nie ma?

Trzeba jakoś specjalnie definiować liczbę jako 64 bitową ?
Po samym usunięciu dzielenia program niestety sypie się w niektórych przypadkach (np. benchmarkowy testcase), więc prawie na pewno następuje przepełnienie zwykłego INTa.
Jednak moje doświadczenie z 64 bitami jest delikatnie mówiąc nienajlepsze (żeby nie powiedzieć żadne ), stąd nie wiem co zrobić, żeby to działało i przy tym zgodne było z jakimiś standardami.
Dzielenie jest dość czasochłonne, więc jest szansa że usunięcie go z funkcji która jest jedną z głównych w programie powinno coś pomóc. Prawie na pewno program przyspieszy o kilka-kilkanaście procent, przyspieszenie to widać nawet zastępując oryginalną funkcję ic-score inną, bardziej skomplikowaną ale jednocześnie bez końcowego dzielenia (niestety generującą przy tym niekompatybilne wyniki, więc nie można ich używać zamiennie).

W progsie jest pętla w której wynik powstaje przez kilka(naście) -> n kolejnych mnożeń, a że powstająca liczba jest okrutnie wielka, zastosowane jest tam też dzielenie (przez n właśnie), dzięki czemu mieści się w rozsądnym zakresie.
Dążę do tego, żeby ta liczba mogła być okrutnie wielka (czyli w praktyce 64 bitowy INT), wtedy obejdzie się bez dzielenia, czyli powinno to zaoszczędzić trochę czasu procesora.
Teraz jednak pojawia się pytanie: czy dla 64 bitowego procesora, aplikacji i systemu działania na 64 bitach będą równie szybkie jak na 32 ? W aplikacji ewentualnie powstający 64 bitowy wynik będzie ciągle porównywany z innymi (najlepszy jest przechowywany), więc jeśli okaże się, że porównanie dwóch 64 bitowych liczb jest wolniejsze niż dla 32 bitowych, to przyrost prędkości aplikacji może okazać się ujemny...
Jeszcze muszę luknąć jak to wygląda w oryginalnych źródłach obecnejaplikacji, bo to w czym obecnie dłubię to stara i dużo wolniejsza wersja, ale przez to lepsza do testów, bo wszelkie zmiany są bardziej widoczne.

Dłubałem dziś sporo przy aplikacji, testowałem wydajność głównie pod linuksem ze względu na dostęp do 4 kompilatorów - 2 wersje gcc, Intel i Open64.
Wyżej wspomniane kombinowanie z 64 bitami ma sens raczej tylko jako dodatek do innych optymalizacji. Samodzielny przyrost prędkości jest raczej mizerny, na dodatek 64 bitowe kompilacje na procesorach Intela są po prostu wolniejsze od starych aplikacji zbudowanych przy użyciu gcc 3.2, tak więc nawet z przyspieszeniem po usunięciu paru drobiazgów przyrost prędkości przy przesiadce 32->64bit jest ujemny.

Nie rozumiem jednak wielu rzeczy. Na przykład tego:


Score które jest zwykłą sumą liczone jest na 4 zmiennych i na sam koniec po prostu sumowane. Oczywiście można wywalić te 4 zmienne i zostawić jedną, odpada też wtedy suma na końcu, ale pojawiają się ciekawe efekty:

-na procesorach typu PIII i pochodnych ogromny spadek wydajności
-na Athlonach 64/64 x2 lekki przyrost wydajności (rzędu 2%)
-na architekturze c2d nie widać zmian

Na dodatek dużo zależy tu od kompilatora, z tego co pamiętam właśnie z tym oryginalnym kodem na 4 zmiennych aplikacja skompilowana kompilatorem Intela na linuksie po prostu zmiata wydajnością wszystkie inne, wydajność jest tak ogromna, że gdyby istniały 4GHz PIII byłyby to najprawdopodobniej najlepsze procesory w projekcie - wydajność z każdego MHz lepsza jest chyba tylko na najmocniejszych C2D.

Z tego co czytałem w podręczniku kompilatora Intela, dość możliwe jest, że takie rozbite niezależne działania procesor jest w stanie wykonywać jednocześnie. Ale nie tłumaczy to, dlaczego w takim razie aplikacja zbudowana pod C2D, PIV czy inne nowsze procesory działa tak samo szybko, niezależnie od tego czy operuje na jednej zmiennej czy na czterech. Próbowałem nawet na 8 i 16 ale zmian nie widać.

Kolejna sprawa to tajemnicze -fschedule-insns na procesorach AMD.
Na procesorach Intela najwyższą wydajność uzyskuje się przez ręczne rozwinięcie kodu, tzn wszystkie wywołania drobniejszych funkcji zastępuję po prostu tą funkcją wklejoną w miejsce wywołania. Kod źródłowy jest po takiej akcji kobylasty, a plik wykonywalny wielki jak drzwi od stodoły, ale przyspieszenie na procesorach klasy c2d rzędu 10-15% więc nie do pogardzenia. Tak działa obecnie używana aplikacja dla c2d.
Na procesorach AMD jednak taki numer nie przechodzi, bo gcc wywala błędy przy próbie kompilacji tak rozwiniętego kodu z flagą -fschedule-insns, która jak zostało udowodnione jest kluczowa dla wydajności na prockach AMD. Bez tej flagi kod się kompiluje, ale zysk prędkości biorący się z braku wywołań funkcji zatraca się poprzez stratę wydajności przy braku -fschedule-insns. Z Open64 i rozwiniętym kodem również były jakieś zgrzyty kompilacji.

Jedno jeszcze mnie dziwi - na forum projektu mdoerner zarzucił kompilacje z Open64 m.in. właśnie dla Athlona 64 i 64x2 - te jego exeki chodzą w miarę przyzwoicie, śmiem nawet przypuszczać, że są to obecnie najszybsze dla tych Athlonów pod 32 bitowe systemy.
Jednak dziś próbowałem wykrzesać coś więcej z tego kompilatora i choćbym na rzęsach chodził po suficie nie mogłem uzyskać nawet zbliżonego wyniku; co więcej nie mogłem nawet uzyskać wyniku zbliżonego do byle chłamowatej kompilacji z gcc... Średnia kiepskich gcc-buildów w benchmarku którego dziś używałem (krótki, żeby nie zasnąć oczekując) to 24s, podobną wydajność osiągał exek skomplilowany Intelem z flagami generic x86 tak żeby progs działał również na AMD. Najszybszy exek z Open64 jaki udało mi się wykrzesać osiągnął 28s i co ciekawe, obojętnie jakie opcje bym do kompilacji nie dodawał czas ten znacznie się nie zmienia - są praktycznie tylko dwa stany: 1) progs się kompiluje i osiąga te 28s 2) wyskakuje błąd informujący o złych opcjach albo błąd kompilacji po włączeniu jakiejś opcji. WTF ?

Wygląda na to, że w źródłach czai się jeszcze spora rezerwa prędkości do wyciśnięcia, tylko trzeba porzucić jedno, wspólne źródło i spróbować z co najmniej dwoma róznymi wersjami: Intel/AMD lub co gorsza jeszcze jakieś wersje pośrednie, bo podejrzewam, że między Athlonami a Phenomem też różnice będą spore...

Oprócz tego, że 'brakuje' aplikacji Windows/AMD, wszystkie inne da się przyspieszyć modyfikując źródła pod konkretny procesor i używając właściwych flag. Niestety, kombinacji jest łącznie tyle, że po paru godzinach zabawy już się nie pamięta co z czym i jak łączyć. Trzeba by jakoś usystematyzować wiedzę i wprowadzać kolejne zmiany w źródłach, sprawdzać na każdym procku jakie są efekty i kompilować z różnymi flagami.
Aplikacji 64 bitowej pod AMD chwilowo nie przetestuję, bo nie mam pod ręką kompa z Athlonem i 64bitowym systemem.

Nie wiem, wypadałoby zrobić benchmark i po prostu wybrać najszybszy. Gdzieś na poprzednich stronach tego wątku jest opis jak wykonywać pomiary. Sprowadza się to do uruchomienia exeka z odpowiednimi parametrami i sprawdzenia ile czasu procesora użył do momentu zakończenia pracy.

To ciekawa informacja. A jak do tego mają się zadania przerwane przez użytkownika? Jestem "karany" za coś takiego, czy jest to neutralne? Chodzi mi o ogólną zasadę, nie tylko o ustawy Enigmy.

Jestem tu nowy i wciąż eksperymentuję z różnymi projektami. Czasem, żeby dostać jakąś próbkę muszę ustawić zapas na kilka dni. Niestety "przy okazji" z takiego np. PG zdąży wpaść i 50 wu, które później wywalam. Wiem, że należy nastawić "nie pobieraj", ale czasem zdarza się zapomnieć.

Dokładnie tak to działa, na dodatek w starszych wersjach serwera przerwanie podbijało error_rate hosta, czy nadal tak jest nie sprawdzałem. To drugie jest totalnie bez sensu, bo anulowanie zadań jest na pewno lepszym sposobem niż ich kiszenie aż przekisną w wypadku nadmiaru - z anulowanym zadaniem serwer radzi sobie doskonale wysyłając od razu resenda, kiszone wisi w bazie aż do timeouta, po czym również następuje resend, ale workunit jako taki ma wpisy w bazie ze 2 razy dłużej.
Tutaj jednak sytuacja jest jeszcze trochę inna, podczas procesu walidacji serwer może początkowo obniżyć daily quota za anulowanie zadań (pozostałość BOINCowego kodu validatora), ale i tak przywróci maksymalną wartość przy pierwszym poprawnym zwróconym wyniku, bo daemon który zajmuje się ustalaniem aktualnej wartości nresults_today i daily_quota ma po prostu w nosie takie drobiazgi, jak anulowanie zadań. Dla niego liczą się tylko poprawność/niepoprawność wyniku.

Rozważam jeszcze możliwość wprowadzenia bonusu dla 'reliable hostów' - komputery które w momencie odsyłania wyniku miałyby error_rate = 0, mogłyby dostawać jakiś dodatek do punktów za zadanie. Takie komputery są szczególnie cenne z punktu widzenia każdego projektu, bo trafiają do nich zadania które często nie będą miały więcej szans na przeliczenie. Przykładowo, w enigmie zadanie ma około 28 dni na powrót do serwera M4, to daje możliwość przekiszenia zadania dwa razy, ale trzeci resend zostanie wysłany ze skróconym deadline i jeśli nie wróci w czasie, serwer M4 takiego rezultatu nie przyjmie. Co prawda serwer nadal potrafi obsłużyć taki rezultat (czeka na inny workunit z serwera M4 z tymi samymi danymi, do których rezultat będzie pasował), jednak kosztem bardzo obciążających operacji na bazie danych.

Zbudowałem z ciekawości nowy set optymalizowanych aplikacji, w VS 2008. Są tylko dwie sensowne: SSE i SSE2.
Na razie szału nie ma, uzyskałem wyniki na poziomie zbliżonym do starych najlepszych aplikacji. Ale myślę, że zmieniając w opcjach co nieco da się jeszcze dorzucić jakiś bonus do prędkości, więc niewykluczone, że dałoby radę zbudować coś szybszego. Niestety nie używam VS na codzień, więc nie bardzo wiem od czego zacząć.
Orientuje się ktoś, czy jeśli ustawię inline functions -> any suitable, to nadal kompilator będzie brał pod uwagę funkcje oznaczone jako _inline_ ? GCC miał z tym poważne problemy, musiałem całe źródło przepisać, tak żeby w ogóle nie było tych funkcji.

EDIT: oraz fajnie by było, gdyby ktoś z AMD/Win32 przetestował jak się miewa prędkość, może dla AMD będzie na dzieńdobry lepiej niż standard z MinGW.

Nie potrafię w ogóle podpiąć kompilatora Intela pod Visual Studio, kiedyś ostro z tym walczyłem ale miałem poważne problemy. Udało mi się jedynie pod Visual C++.
Źródło później gdzieś wrzucę, mam chwilowo jedynie jakieś niechlujne na którym dużo rzeczy testowałem, ale projekt i patch da się spokojnie nałożyć na domyślne.

Nie wiesz jak wygląda sytuacja z inline funkcjami w visualu ? Domyślnie nie wciąga nawet najprostszych funkcji jako inline (widzę to od razu po wielkości exeka), a z doświadczenia wiem, że daje to spory przyrost prędkości. Z kolei gdy zdeklaruję coś z inline, __inline lub __forceinline, kompilacja sypie się z błędami linkera.

No cóż, widocznie będę musiał ręcznie rozwinać źródło, jak dla gcc który też coś sapał. Wtedy niedziałanie inline samego kompilatora nie jest problemem.

Co do VS, to mam full wersję, ale mimo to miałem jakieś problemy. Niestety wyczerpałem 30-day triala na obu zainstalowanych systemach, więc póki co nawet nie potestuję czy da się coś jeszcze z tym zrobić.

U mnie trial przywiesił się na ostatnich dniach, ale ostatecznie w końcu kompilator i tak się przyblokował.

Nie rozumiem jednej rzeczy kurcze.



To jest funkcja, gdzie myślałem o zmianie double na 64 bit integera, bo pamiętałem jeszcze z listy mailingowej M4 wzmianki o ogromnych liczbach jakie tu występują. A tymczasem:


ciekawe, gdzie tkwi haczyk...

Teoretycznie ciphertext może być o wiele dłuższy, ale według podręcznika operatora enigmy, nie wolno bylo przekroczyć chyba koło 300 znaków.


Zastanawiają mnie też porównania tego typu


Skoro po usunięciu dzielenia, które praktycznie nic nie wnosi (przecież i bez dzielenia lepszy score zawsze będzie lepszy, a gorszy będzie gorszy) liczba mieści się powiedzmy w  1000, to po co użyty typ double i jeszcze takie dziwne porównania   DBL_EPSILON zdefiniowany jest jako 0.000000001.
Zastanawiam się, jakie to może mieć znaczenie dla logiki programu.
Możliwe, że dzielenie ma wnieść jakąś dodatkową zależność score od długości tekstu, ale skoro aplikacja cały czas pracuje na tekście jednej długości, to po co to   Chyba spróbuję to pousuwać razem z tym DBL_EPSILONem i przetestować jak zachowa się aplikacja.
Nie wiem na ile bezpieczne są takie modyfikacje, bo aplikacja może działać poprawnie i zwracać poprawne wyniki, ale jakość hillclimba może spaść na łeb i cały soft nie będzie w stanie nic złamać.