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

[TJM]

EDIT: Fragment o wywalaniu dzielenia nieaktualny dla używanej wersji aplikacji, więc wycinam żeby nie mięszać.

Na pewno z oryginalnego źródła można wywalić z funkcji icscore testowanie if len < 2, bo workunity mają stały len, do tej pory było to 72 i 100. Można jednak tą funkcję zmodyfikować jeszcze co najmniej na dwa sposoby, sęk w tym, że często modyfikacja na jednym procesorze dawała zysk, na innym gwóźdź do trumny...

i/c debug: 0.036364
i/c debug: 0.036566
i/c debug: 0.036768
i/c debug: 0.037778
i/c debug: 0.039596
i/c debug: 0.040000
i/c debug: 0.042222
i/c debug: 0.042424
i/c debug: 0.044040
i/c debug: 0.046061
i/c debug: 0.046667
i/c debug: 0.050101
i/c debug: 0.052121
i/c debug: 0.052727
i/c debug: 0.053131
i/c debug: 0.054141
i/c debug: 0.054545
i/c debug: 0.057980
i/c debug: 0.058182
i/c debug: 0.059798
i/c debug: 0.062020
i/c debug: 0.062222
i/c debug: 0.063636
i/c debug: 0.066667
i/c debug: 0.066667
i/c debug: duuuupa
i/c debug: 0.034949
i/c debug: 0.036566
i/c debug: 0.036970
i/c debug: 0.037374
i/c debug: 0.043030
i/c debug: 0.043838
i/c debug: 0.046869
i/c debug: 0.050303
i/c debug: 0.051515
i/c debug: 0.052323
i/c debug: 0.052929
i/c debug: 0.054141
i/c debug: 0.054747
i/c debug: 0.057576
i/c debug: 0.059596
i/c debug: 0.059798
i/c debug: 0.060000
i/c debug: 0.060202
i/c debug: 0.060404
i/c debug: 0.063232
i/c debug: 0.063636
i/c debug: 0.064646
i/c debug: 0.066263
i/c debug: 0.066465
i/c debug: 0.067475
i/c debug: 0.067879
i/c debug: 0.067879
i/c debug: duuuupa
i/c debug: 0.039394
i/c debug: 0.041212
i/c debug: 0.041616
i/c debug: 0.041818
i/c debug: 0.045051
i/c debug: 0.045253
i/c debug: 0.047273
i/c debug: 0.047677
i/c debug: 0.047879
i/c debug: 0.048081
i/c debug: 0.048485
i/c debug: 0.049091
i/c debug: 0.049495
i/c debug: 0.049697
i/c debug: 0.050101
i/c debug: 0.051111
i/c debug: 0.052121
i/c debug: 0.052323
i/c debug: 0.053131
i/c debug: 0.053535
i/c debug: 0.054343
i/c debug: 0.054949
i/c debug: 0.055354
i/c debug: 0.056970
i/c debug: 0.057980
i/c debug: 0.058990
i/c debug: 0.060404
i/c debug: 0.061010
i/c debug: 0.061010
i/c debug: duuuupa
i/c debug: 0.041818
i/c debug: 0.042020
i/c debug: 0.043434
i/c debug: 0.044242
i/c debug: 0.045455
i/c debug: 0.045657
i/c debug: 0.045859
i/c debug: 0.046061
i/c debug: 0.047071
i/c debug: 0.048485
i/c debug: 0.048687
i/c debug: 0.049091
i/c debug: 0.049899
i/c debug: 0.050505
i/c debug: 0.051111
i/c debug: 0.052323
i/c debug: 0.052727
i/c debug: 0.059596
i/c debug: 0.061010
i/c debug: 0.061414
i/c debug: 0.062020
i/c debug: 0.062222
i/c debug: 0.064848
i/c debug: 0.067273
i/c debug: 0.067879
i/c debug: 0.069495
i/c debug: 0.069495

duuupa rozdziela jeden pełny przebieg po ustawieniach - cały cykl pętli hillclimb.c
Nie widziałem, żeby na jakimkolwiek normalnym WU przekroczyło chociażby 0,08.

Tymczasem zostawiam aplikację logującą najlepsze ic score i idę w kimę, jutro normalnie na stronce będę mógł przeglądać w stderr rezultatów logi.

EDIT: no i śmigała aplikacja parę godzin, maksimum dla normalnego icscore i 100 znaków tekstu można przyjąć na poziomie 0,1...

[TJM]

Zrobiłem coś takiego, z hillclimb.c wywaliłem wszystko co się dało oprócz deklaracji (w ten sposób mam działający szkielet programu który mogę odpalać jak normalną enigmę), w środek wstawiłem benchmark, np:

Kod [Zaznacz] Rozwiń


   bestelapsedic1 = 500000;
   for (i=0;i<30;i++) {
   start = GetTickCount();
   for (counter=0;counter<400000;counter++) {
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       bestic = icscore(ckey.stbrett, ciphertext, len);
       }
   end = GetTickCount();
   elapsed = end-start;
   if (elapsed < bestelapsedic1) {
      bestelapsedic1 = elapsed;
   }
   printf("elapsed %f\n",elapsed);
}
   printf("best elapsed %f\n",bestelapsedic1);


Tutaj dwa kolejne wyniki: na zwykłej funkcji i po minimalnej zmianie - wycięciu if len < 2

C:\Documents and Settings\TJM\Pulpit\project_source_code\bench>enigma -R -o nul
00trigr.naval 00bigr.naval m4_awgly100_1
2009-08-17 10:01:26  enigma: working on range ...
elapsed 3925.000000
elapsed 3818.000000
elapsed 4088.000000
elapsed 4898.000000
elapsed 4221.000000
elapsed 4075.000000
elapsed 4245.000000
elapsed 4083.000000
elapsed 3956.000000
elapsed 4144.000000
elapsed 4094.000000
elapsed 3904.000000
elapsed 4125.000000
elapsed 3982.000000
elapsed 4170.000000
elapsed 3994.000000
elapsed 3806.000000
elapsed 4123.000000
elapsed 4167.000000
elapsed 4069.000000
elapsed 4021.000000
elapsed 3989.000000
elapsed 3942.000000
elapsed 3834.000000
elapsed 4026.000000
elapsed 4056.000000
elapsed 3898.000000
elapsed 3963.000000
elapsed 3964.000000
elapsed 3918.000000
best elapsed 3806.000000

C:\Documents and Settings\TJM\Pulpit\project_source_code\bench>enigma -R -o nul
00trigr.naval 00bigr.naval m4_awgly100_1
2009-08-17 10:05:55  enigma: working on range ...
elapsed 3834.000000
elapsed 3916.000000
elapsed 3887.000000
elapsed 3765.000000
elapsed 3801.000000
elapsed 4056.000000
elapsed 3929.000000
elapsed 3728.000000
elapsed 3999.000000
elapsed 3843.000000
elapsed 3753.000000
elapsed 3915.000000
elapsed 3902.000000
elapsed 3873.000000
elapsed 3891.000000
elapsed 3878.000000
elapsed 3881.000000
elapsed 3509.000000
elapsed 4005.000000
elapsed 3848.000000
elapsed 3727.000000
elapsed 3765.000000
elapsed 3770.000000
elapsed 3791.000000
elapsed 4031.000000
elapsed 3952.000000
elapsed 3812.000000
elapsed 4035.000000
elapsed 3925.000000
elapsed 3880.000000
best elapsed 3509.000000

C:\Documents and Settings\TJM\Pulpit\project_source_code\bench>

[TJM]

No to teraz parę ciekawostek.

Dziwne rzeczy, co się najstarszym fizjononom w głowie nie mieszczą.

Kosmetyczna zmiana na końcu funkcji, usunięcie dzielenia. Czas wykonania spada do lekko poniżej 3000ms na 500000 iteracji (standardowy czas jest wyżej). Zmienna zwracana jako double, ale jest to nadal integer.

No to myślę sobie, zmienię typ danych na integer, będzie jeszcze szybciej. W deklaracji funkcji zmieniłem więc double icscore na int icscore, usunąłem casta na double z return oraz w zmiennej przyjmującej wartość funkcji typ danych zmieniłem na integer. Dzielenie oczywiście dalej usunięte. I co ? A no czas wykonania skoczył na średnio 3800ms, 800ms powyżej tego samego z typem danych double.

Ciekawe dlaczego, nie jestem w stanie tego wytłumaczyć. Możliwe, że działania na liczbach zmiennoprzecinkowych wpadają na jednostkę zmiennoprzecinkową, która wykonuje je szybciej niż stałoprzecinkowa ? Ewentualnie druga hipoteza, że w ten sposób co niektóre instrukcje lecą na FPU, odciążając CPU - procesory na pewno dają radę niektóre instrukcje wykonywać równolegle, widać to po samej pętli w funkcji icscore - jedna pętla wykonuje na raz 4 dodawania na 4 zmiennych i na koniec je sumuje, gdy zmieni się to na tradycyjne dodawanie do jednej zmiennej, wydajność spada na łeb.


Zamieniając coś takiego

Kod [Zaznacz] Rozwiń


  S0 = S1 = S2 = S3 = 0;
  for (i = 0; i < 23; i += 4) {
    S0 += f[i]*(f[i]-1);
    S1 += f[i+1]*(f[i+1]-1);
    S2 += f[i+2]*(f[i+2]-1);
    S3 += f[i+3]*(f[i+3]-1);
  }
  S0 += f[24]*(f[24]-1);
  S1 += f[25]*(f[25]-1);


w coś takiego

Kod [Zaznacz] Rozwiń


  S0 = S1 = S2 = S3 = 0;
    S0 += f[0]*(f[0]-1);
    S1 += f[2]*(f[2]-1);
    S2 += f[3]*(f[3]-1);
    S3 += f[4]*(f[4]-1);
    S0 += f[5]*(f[5]-1);
    S1 += f[6]*(f[6]-1);
    S2 += f[7]*(f[7]-1);
    S3 += f[8]*(f[8]-1);
    S0 += f[9]*(f[9]-1);
    S1 += f[10]*(f[10]-1);
    S2 += f[11]*(f[11]-1);
    S3 += f[12]*(f[12]-1);
    S0 += f[13]*(f[13]-1);
    S1 += f[14]*(f[14]-1);
    S2 += f[15]*(f[15]-1);
    S3 += f[16]*(f[16]-1);
    S0 += f[17]*(f[17]-1);
    S1 += f[18]*(f[18]-1);
    S2 += f[19]*(f[19]-1);
    S3 += f[20]*(f[20]-1);
    S0 += f[21]*(f[21]-1);
    S1 += f[22]*(f[22]-1);
    S2 += f[23]*(f[23]-1);
    S3 += f[24]*(f[24]-1);
    S0 += f[25]*(f[25]-1);


Czas wykonywania spada o 300ms... Odpada licznik pętli i dodawanie w nawiasach kwadratowych kosztem czytelności kodu, ale to żadna strata.

Próbowałem również z różną ilością sum pomocniczych - przy 1 jest najwolniej, przy 2-4 prędkość jest praktycznie taka sama, powyżej zaczyna znów spadać. Myślałem, że przy 5 będzie najszybciej (ze względu na to, że ilość działań to wielokrotność 5), ale nie jest. Wszystko to póki co jedynie dla architektury c2d.
Jest ktoś w stanie przeprowadzić te same testy na AMD ?

[Karlik]

Kod [Zaznacz] Rozwiń


  S0 = S1 = S2 = S3 = 0;
  for (i = 0; i < 23; i += 4) {
    S0 += f[i]*(f[i]-1);
    S1 += f[i+1]*(f[i+1]-1);
    S2 += f[i+2]*(f[i+2]-1);
    S3 += f[i+3]*(f[i+3]-1);
  }
  S0 += f[24]*(f[24]-1);
  S1 += f[25]*(f[25]-1);


w coś takiego

Kod [Zaznacz] Rozwiń


  S0 = S1 = S2 = S3 = 0;
    S0 += f[0]*(f[0]-1);
    S1 += f[2]*(f[2]-1);
    (...)


Specjalnie usunąłeś dodawanie f[1] czy przez przypadek?

[TJM]

Skasował mi się jeden wpis przy kopiowaniu, jedynka też musi być. Bez tego pewnie kaszanka w icscore by była.
Niestety sama funkcja icscore jest dość szybka, przez co mimo częstego używania w programie (praktycznie 1/3 głównej pętli) kilka-kilkanaście procent przyrostu prędkości na samym ic praktycznie nie jest zauważalne w całości. No ale zawsze jakieś sekundy odpadną na najdłuższych zadaniach.

[gielo]

a jaki jest sens liczenia tego projektu ? Po za nabijaniem punktów oczywiście. Czy nie lepiej liczyć coś co przyczynia się do rozwoju nauki czy medycyny?

[TJM]

Dla mnie sens jest duży, zaszyfrowane wiadomości to nieznany na chwilę obecną kawałek historii który kiedyś może da się odkryć.

Sesef - wyślę zaraz na priva link do źródeł które budują się pod visualami, ale będziesz musiał sobie odświeżyć zawartość przed nadpisanie świeżym, Windowsowym źródłem ze strony - jak zobaczysz strukturę archiwum od razu rozkminisz co i jak - te moje były edytowane z milion razy i właśnie okazało się, że połowa rzeczy które tu pisałem o dopalaniu funkcji icscore to głupości, bo w aktualnej wersji progsa funkcja jest trochę inna i doskonale tłumaczy użycie typu double dla danych.

I od razu prośba do wszystkich budujących jakieś aplikacje na ewentualny użytek publiczny - wrzucajcie do źródeł jakiś tag, po którym potem da się na stronie rozpoznać jaka aplikacja coś liczyła. Wystarczy znaleźć w hillclimb.c to

Kod [Zaznacz] Rozwiń


#endif
    hillclimb_log("enigma: working on range ...");
  }


i dopisać linijkę, która będzie wyrzucana do stderr a wiec widoczna później także na stronie:

Kod [Zaznacz] Rozwiń


#endif
    hillclimb_log("Win32 Intel/C2D executable v1.0 by ChudyGienek");
    hillclimb_log("enigma: working on range ...");
  }


W ten sposób w razie kłopotów z aplikacją łatwo będzie można znaleźć wszystkich userów, którzy z niej korzystają i poinformować ich, że coś jest nie tak. Aktualnie gdzieś w sieci na 100% krąży jakaś niedorobiona aplikacja która 1/3 zadań wysypuje a z pozostałych 2/3 mniej więcej 1/4 się nie validuje. Pewnie paru userów zainstalowało, zobaczyli że przeliczyła parę rezultatów i zostawili, a teraz dziennie przelatuje przez ich kompy po kilkadziesiąt zadań które tylko się sypią i zaśmiecają bazy serwera. Powoli wychwytuję ich po logach, ale zanim wszystkich znajdę i się z nimi skontaktuję minie trochę czasu.

[sesef]

W ten sposób w razie kłopotów z aplikacją łatwo będzie można znaleźć wszystkich userów, którzy z niej korzystają i poinformować ich, że coś jest nie tak. Aktualnie gdzieś w sieci na 100% krąży jakaś niedorobiona aplikacja która 1/3 zadań wysypuje a z pozostałych 2/3 mniej więcej 1/4 się nie validuje. Pewnie paru userów zainstalowało, zobaczyli że przeliczyła parę rezultatów i zostawili, a teraz dziennie przelatuje przez ich kompy po kilkadziesiąt zadań które tylko się sypią i zaśmiecają bazy serwera. Powoli wychwytuję ich po logach, ale zanim wszystkich znajdę i się z nimi skontaktuję minie trochę czasu.

Zapuścić skrypt jak od 3 dni ma jakiś konkretniejszy error rate to mu dayli quoat ustawić na 20 i po problemie, jak mu zacznie punktów ubywać to się kapnie, że coś jest nie tak. Bo jak takich hostów trochę się trafi to jednak trochę to bazę przymula i generuje niepotrzebny transfer, przy okazji łatwiej będzie odfiltrować hosty które mają niskie daily quota i w razie potrzeby kontaktować się z właścicielem.

[TJM]

Daemon czyszczący bazy i generujący niektóre statsy jako skutek uboczny w logu wyświetla statystyki wywalonych próbek (zresztą sam BOINC też to ma wbudowane), więc wystarczy przeglądać i klikać na linkach do profilu usera. Niestety ciężko czasami odróżnić zwykłe wysypywanie się próbek np. przez nieumiejętną podmianę aplikacji (dużo ludzi próbuje podmieniać na włączonym BOINCu) czy też podmianę na złą wersję, gdzie user skapnie się po chwili sam, że wszystko się sypie od skaszanionych wersji - trzeba po prostu obserwować i notować.

Wysyłam właśnie PMa z linkiem do źródeł, przed chwilą sprawdzałem czy da się je przenosić między komputerami - elegancko są przenośne, otwiera je bez problemu i kompiluje Visual Studio 2008 i Visual C++ 2008 Express (w tym były ostatnio zapisane i testowałem czy działa build), nie wiem czy da się backportnąć do wersji 2005/2005 Express - projekt to automatyczna konwersja właśnie z tych starszych wersji do 2008.
W konfiguracji Win32/Release są ustawione opcje które jak do tej pory okazały się najszybsze.

[sesef]

Niestety ciężko czasami odróżnić zwykłe wysypywanie się próbek np. przez nieumiejętną podmianę aplikacji (dużo ludzi próbuje podmieniać na włączonym BOINCu) czy też podmianę na złą wersję, gdzie user skapnie się po chwili sam, że wszystko się sypie od skaszanionych wersji - trzeba po prostu obserwować i notować.

Dlatego pisałem wcześniej, żeby skrypt brał np 3 ostatnie dni pod uwagę, chyba nie ma takich nieogarniętych co przez 3 dni będą wgrywać optymalki, albo nie kapną się, że coś jest nie tak, bo tutaj problemy z tego co rozumiem generują głównie hosty typu "wgraj i zapomnij".

[TJM]

Tak, głównie takie hosty są problemem, zwłaszcza jeśli przeliczają część zadań poprawnie. Natura BOINCa taka, że daily quota spada przy błędach, ale również rośnie przy prawidłowo przeliczonych zadaniach. Stąd zapomniany host z całkowicie zwaloną aplikacją będzie kaszanił 1*ilość rdzeni zadań dziennie lub nawet tylko jedno (nie pamiętam jak to jest rozwiązane, teoretycznie daily quota mnożone jest x liczba CPU), gdy tymczasem host przeliczający część zadań poprawnie będzie mógł też sporo dziennie skaszanić. Po przeliczonym zadaniu daily quota podbijane jest o 2, więc 4 rdzeniowy host po przeliczeniu 2 zadań poprawnie będzie mógł ściągnąć 8 a następnie odesłać je skaszanione.

[sesef]

Tak, głównie takie hosty są problemem, zwłaszcza jeśli przeliczają część zadań poprawnie. Natura BOINCa taka, że daily quota spada przy błędach, ale również rośnie przy prawidłowo przeliczonych zadaniach. Stąd zapomniany host z całkowicie zwaloną aplikacją będzie kaszanił 1*ilość rdzeni zadań dziennie lub nawet tylko jedno (nie pamiętam jak to jest rozwiązane, teoretycznie daily quota mnożone jest x liczba CPU), gdy tymczasem host przeliczający część zadań poprawnie będzie mógł też sporo dziennie skaszanić. Po przeliczonym zadaniu daily quota podbijane jest o 2, więc 4 rdzeniowy host po przeliczeniu 2 zadań poprawnie będzie mógł ściągnąć 8 a następnie odesłać je skaszanione.

To może wprowadzić coś w rodzaju bana na dany host. Jak host powiedzmy po 3 dniach ma dość duży error rate to dostaje bana na WU + komunikat od serwera przy requescie ze ma bana (manager takie na czerwono wyświetla) i dana osoba ma się skontaktować z administratorem. BOINC po kilku nie udanych próbach połączenia złapie dość duży request time więc często requestami nie będzie sypać, a i problem z błędami się skończy.

[TJM]

BOINC teoretycznie obsługuje bany na hosta, ale nigdy ich jeszcze nie testowałem.
Teraz problem jest już zminimalizowany, nowy zestaw daemonów na zapleczu lepiej sobie z tym radzi - hosty które notorycznie zwracają duże ilości błędnych WU przy pierwszym zwróconym błędzie mają daily quota ustawiane od razu na 1 i nresults_today na max_results_day * liczba rdzeni +1, więc tego dnia nic już nie ściągną.
Natomiast przez ostatni miesiąc to była porażka, na 3 zadania ściągnięte z serwera M4 jedno wracało od razu, a pozostałe dwa pierw odbijały się od kaszaniących hostów.

[TJM]

Podpiąłem 'offline' tabelę z wszystkimi unikatowymi rezultatami dla hceyz72 pod prosty interfejs do ich przeglądania:

http://www.enigmaathome.net/results_hceyz72.php?page=1

Można sobie zobaczyć jak to wygląda od kuchni, jak ktoś ma chęć może wszystkie teksty (1,3 miliona) przeczytać i sprawdzić, czy nie ma tam przypadkiem jakiegoś sensownego niemieckiego tekstu %)

[TJM]

Taki nowy bajer, niedługo będzie zlinkowane na stronie głównej projektu (po poprawkach) http://www.enigmaathome.net/cpu_os.php

[AiDec]

Nudzilo Ci sie?  ;). Fajny bajerek :).

[TJM]

Ciekawych rzeczy można się dowiedzieć z tabelki, np. że i7 920/940/950 są wolniejsze niż większość procesorów AMD, które to w tym projekcie uważane są raczej za powolne...
Podana prędkość jest oczywiście wyliczoną średnią z prawdziwych czasów przeliczania WU.

[AiDec]

Ja bym raczej powiedzial ze wlasciciele i7 nie stosuja optymalek :). Kupili szybkie proce i rozleniwili sie. Natomiast Ci co maja powolne AMD robia wszystko co sie da zeby tylko dogonic lepszych...

Jak czesto zamierzasz aktualizowac tabele?

Przydalby sie news o tym...

[Peciak]

powolne AMD

no chyba się obrażę  :wth:

[TJM]

No niestety nie jest to tajemnica, że AMD poniżej silnych Phenomów i Enigma to nie jest najlepsze połączenie - bez kombinowania z optymalizacjami speed jest delikatnie mówiąc nienajlepszy %)
Tabele są aktualizowane w czasie rzeczywistym przez assimilatora, ale na czas prac zatrzymuję skrypty, żeby coś się nie pogibało.

[buninek]

Od trzech dni probuję się zalogować na własne konto. Niestety bez powodzenia. >:(
Przekierowuje mnie na jakiś dziwny adres neostrady.

http://83.10.229.196:443/enigma/home.php

Co jest grane?

[TJM]

To nie jest 'dziwny adres neostrady' tylko prawdziwe IP projektu. Zaraz obadam co jest grane, bo nie ty pierwszy o tym wspominasz. Możliwe, że coś się popierniczyło w konfigu serwera reverse-proxy.

EDIT: Możesz sprawdzić teraz, czy wszystko OK ? Coś się musiało zmienić w źródłach projektu, wcześniej wszystkie requesty leciały na project_url/skrypt.php a teraz do niektórych dorzuca project_url/project_name/skrypt.php. Dorzuciłem na proxy workaround z double redirectem, ale trzeba to potestować nieco.
Chyba dla bezpieczeństwa wyedutuję skrypty, żeby to project_name nigdzie się nie pojawiało...

[buninek]

Teraz jest ok.

To nie jest 'dziwny adres neostrady' tylko prawdziwe IP projektu.

Ja nie mam możliwości sprawdzenia, kto się za nim kryje.

[TJM]

No już powinno wszystko trybić, zmieniłem trochę konfig proxy żeby pasował pod te nowsze skrypty.
Wkurza trochę coś takiego, zmienią czasem jakiś detal w kodzie PHP serwera i nie ma nawet o tym wzmianki, a później powstają właśnie takie zonki jak to dzisiaj.

[buninek]

Jeszcze taki mały bug.
Zdarza się często, że nie pojawia się "panel" z pocztą.
Dziś również była czkawka. Raz był, następnym już nie.

[TJM]

Mówisz o home.php ? Jeśli tak, to czasami strona po prostu nie była ucięta ?

[buninek]

Spójrz na ten screen, zrobiony 10 minut temu.

db error + brak "panelu"

Logowałem się przed chwilą i tym razem był. :D

[Pigu]

pytanie lenia idącego na łatwiznę: jakie opto dla vista64? wiem, że to pewnie jest gdzieś zakopane na forum... %)

[sesef]

pytanie lenia idącego na łatwiznę: jakie opto dla vista64? wiem, że to pewnie jest gdzieś zakopane na forum... %)

tak samo jak do x86

[Pigu]

widzę, że nie się nie do końca zrozumieliśmy  %) linków szukam hehe

[TJM]

A jaki proc ?

[Pigu]

hehe u mnie bez mian q6600@2.8 4GB DDR2@800 EAH4870 VISTA64 BUSINESS %)

[TJM]

http://plikens.no-ip.net/1299xfizob/c2d.zip

[Pigu]

dzięki

[TJM]

Znalazłem swój stary benchmark pod Windows, jeszcze z czasów pre-BOINC wersji serwera:

http://dl.getdropbox.com/u/1912652/win_bench.7z

opis działania: podmienić enigma.exe na wybraną wersję (w razie potrzeby zmienić nazwę) i kliknąć benchmark. Podczas benchmarku w trayu siedzi ikonka, po zakończeniu wyskakuje okienko z czasem podanym w sekundach.
Oczywiście można testować dowolne aplikacje, nie tylko te z dołączonego archiwum.

[Peciak]

Mam taką prośbę  :respect: czy autor sztandarowego projektu polskiego - Enigma mógłby uporządkować i podać w jednym miejscu jakie są aktualnie optymalizacje na poszczególne rodzaje komputerów i systemów. Trochę to śmieszne że lepiej są opisane na stronie projektu Enigma zaś w naszym forum wszystko jest poplątane  |-?, pisane gwarą komputerową, cofanie się, poprawianie, pisanie o benchmarkach itp. Dla kogoś kto w projekcie uczestniczy od początku i na bieżąco śledził wątek Enigma jego rozwój i pojawianie się optymalizacji być może jest to zrozumiałe, ale dla mnie - nie. Optymalizacje opisane na stronie Enigma próbowałem wgrać na różne kompy: na systemieXP i proc intel było szybciej ale już na Phenoma II pod Vistą 64 wyraźnie gorzej. Skoro promujemy ten projekt to wypadało by pomóc rodzimym liczydłowym nie znającym języka.

[X X X]

Na AMD odpuść sobie ten projekt, wyraźnie preferuje Intela.

[TJM]

Na AMD faktycznie jest słabo, ale po wrzuceniu optymalizacji nie jest przynajmniej tragicznie.
Nadal chyba najbardziej uniwersalny jest ten exek który znajdziesz w temacie na forum projektu w paczce z paroma różnymi buildami. Jest najbardziej uniwersalny i przyspieszenie powinno być widoczne na każdym AMD klasy 64/Phenom.
Zresztą najlepiej pobawić się tym benchmarkiem który jest akurat ciut wyżej i po prostu wybrać najszybszy exek. Benchmark pokazuje czas wykonania testu, wiadomo że mniej = lepiej.
Z innych exeków to tutaj na forum musiałbyś poprzeglądać temat i po prostu wybrać coś działającego i szybkiego. Gotowej instrukcji nie ma bo 1) nie mam żadnego hosta AMD z windowsem 2) dziwne sprawy wychodziły przy testach, na jednych kompach optymalka potrafiła być szybsza o paręnaście procent, na innych wolniejsza. Nie mam pojęcia od czego to zależy.

[TJM]

Umarł dziś prawdopodobnie jeden z dysków w serwie, tak więc daemony off do czasu aż zdiagnozuję problem i ewentualnie podmienię dysk.
Co gorsza trafiło bazę danych, na szczęście jedynie tabelę z logiem wrappera, gdzie dane są nieistotne z punktu widzenia działania projektu, tak więc myślę, że obędzie się nawet bez przywracania backupu - będę musiał się jedynie pomotać, żeby odbudować jakoś strukturę uszkodzonej tabeli (prawdopodobnie skopiuję po prostu z online backupu).

[Pantarhei]

W maju zeszłego roku TJM, na moje pytania - dlaczego trzecia wiadomość nie została jeszcze złamana skoro pierwsze dwie rozszyfrowano po kilku miesiacach - odpowiedział:

Prawdopodobnie wynika to z charakterystyki samej maszyny i algorytmów których używa aplikacja.
Jeśli weźmiesz ten sam tekst i zaszyfrujesz go kilka razy z tymi różnymi ustawieniami, a później będziesz próbować deszyfrować podając tylko część poprawnych danych (żeby skrócić zakres, bo nie ma sensu robić testów na całym przecież) na pewno okaże się, że większość z tych testowych tekstów złamie się bardzo szybko (np. po 2-3 'restartach' - czyli przebiegach po całym poszukiwanym zakresie); ale będą też takie, które wytrzymają znacznie więcej, np. kilkanaście lub kilkadziesiąt. Ekstremalne przypadki potrafią wytrzymać 1000+, ale to już musi być wyjątkowo nieszczęśliwy zbieg ustawień i tekstu.

Na dodatek pojawiają się inne czynniki, np. w przechwyconym tekście może brakować jakiejś litery. Zakłóca to automatycznie prawidłową kolejność przeskoków rotorów, więc tekst po brakującej literze jest nie do odczytania nawet dla kogoś, kto zna ustawienia. Tekst z brakującą literą automatycznie dostaje ogromny 'bonus' do odporności na złamanie, pół biedy jeśli litery brakuje blisko początku lub końca - wtedy algorytm sobie może z tym poradzić, bo kilka skaszanionych liter wiele nie zakłóci. Jeśli jednak brakuje gdzieś w środku, to złamanie takiej wiadomości hillclimbem graniczy raczej z cudem.
Na szczęście i na to jest sposób, wystarczy ciąć wiadomość na kawałki i każdy z nich traktować jako osobną - w ten sposób można liczyć na to, że ewentualny uszkodzony fragment się ominie, to właśnie zostało zrobione z ostatnią wiadomością w projekcie M4 - kilka razy już zmieniane były fragmenty, aktualnie dostępne są dwa, pewnie wkrótce jeden zostanie znów zmieniony, bo zakres poszukiwań zbliża się ekspresowo do końca.


Czy aktualnie można określić na jakim etapie jest projekt w swojej drodze do złamania czwartej wiadomości i czy można coś więcej powiedzieć o problemach które stoją temu na przeszkodzie?  :book: