🚀 go-pugleaf

On Tuesday, January 7, 2020 at 1:11:08 PM UTC+1, Piotr Gałka wrote:
> W dniu 2020-01-07 o 11:15, M.M. pisze:
> 
> > Ja skupiłem się na testach tylko niektórych generatorów i na ich
> > rozbudowanych wersjach:
> 
> Mógłbyś kilka słów jaki jest cel testów.

Czasami jestem między młotem a kowadłem. Gdy używam dobrego generatora, to
część mocy obliczeniowej idzie na generowanie liczb losowych. Gdy używam
szybkiego, to boję się, się losowość liczb jest zbyt słaba do rozwiązywania
problemów przy pomocy algorytmów ewolucyjnych, symulowanego wyżarzania, itd.

Chciałbym mieć bardzo szybki algorytm o niskim ryzyku że zadanie zostanie
gorzej rozwiązane z powodu słabej jakości liczb losowych - w sumie to 
jest mój główny cel. Zrobiłem jednolity interfejs żeby łatwo (bez
ryzyka uszkodzenia generatora) przełączać się pomiędzy generatorami i
porównywać je w testach. 

Wcześniej myślałem że generatory Fibonacciego spełniają zarówno wymagania
szybkości jak i jakości generowanych liczb. Doskonale przechodziły testy w
programie dieharder, a Mersenne Twister nie przechodził i działał wyraźnie
wolniej. Jednak w programie PractRand wyniki testów dla generatorów
Fibonacciego zazwyczaj były kiepskie - to ostatecznie przechyliło szalę 
żeby zrobić kilka eksperymentów z różnymi generatorami. 


> Chodzi o szybkość działania, czy chcesz wyłapać jakieś niedoskonałości 
> generatorów.

Chcę przede wszystkim mieć dużą kontrolę nad jakością generowanych liczb 
przy maksymalnej wydajności. Gdy jakość generowanych liczb nie musi być
wysoka, ale szybkość generowania jest ważna, to chcę wiedzieć czy nie
mam błędów z powodu agresywnej optymalizacji i chcę wiedzieć jak spada
jakość generowanych liczb w testach: do tego celu mam parametryzowalne 
adaptery: add-rot, xor, rndbuf, rndfbuf. Adaptery też można wrzucić do
testów i sprawdzić jak szybko działają i jak spadają wyniki w testach.
Przyznać jednak muszę, że przy tak wydajnym generatorze jak wyhash64 
używanie niektórych adapterów może okazać się bezcelowe. 

Jeśli z użyciem tego kodu napisze się odpowiednio program, to można
potem wygodnie zrobić szereg kolejnych testów. Wystarczy sterować warunkową
kompilacją (identycznie jak w testach samych generatorów) i widać jak na 
dłoni czy jakość rozwiązania spada, czy czas obliczeń rośnie. Jeśli czas
obliczeń nie spada po użyciu adapterów, to można je bezpiecznie wyłączyć
kompilacją warunkową bez ingerencji w kod. 


> Nie jestem programistą - nie wczytywałem się w kody generatorów ani testów.
> 
> Ja sobie napisałem generator inspirując się opisem z książki: Ferguson, 
> Schneier "Kryptografia w praktyce". Wydaje mi się (dawno było), że tak 
> totalnie to uprościłem (szczególnie gromadzenie entropii), że może nawet 
> nie powinienem pisać 'inspirując się'.
> Mój generator oparty jest na funkcji SHA512d.
> Literka d oznacza SHA512(SHA512(dane)) bo autorzy nie do końca ufają 

Moje udoskonalenie(?) wyhash mniej-więcej na tym:

if( i1 >= size(dane1) ) i1 = 0;
dane1[ i1 ] += liczba_pierwsza1;

if( i2 >= size(dane2) ) i2 = 0;
dane2[ i2 ] += liczba_pierwsza2;

DANE = dane1[i1] ^ dane2[i2];
i1 = i1 + 1;
i2 = i2 + 1;

return hash( DANE );


> funkcjom SHA i nie znając się postanowiłem po prostu przyjąć ich racje.
> Szybkości działania mnie w ogóle nie interesowała.

Niektóre moje programy wyraźnie przyspieszają po zmianie generatora na
szybszy. Dlatego mnie bardzo interesuje szybkość generowanych liczb. Gdyby
mnie nie interesowała to bym wziął ranlux48. Zresztą mój kod jak najbardziej
umożliwia użycie standardowego ranluxa48 i Mersenne Twister. Standardowego
Knutha i ministd zakomentowałem bo zawieszały diehardera i dawały same 
faile w programie PractRand ;-)


Pozdrawiam