On 14/05/2023 16:00, o...@g...com wrote:
> niedziela, 14 maja 2023 o 11:28:17 UTC+2 Bogdan napisał(a):
>> On 13/05/2023 19:43, o...@g...com wrote:
>>> Swoją drogą mierzę sobie względną szybkość generatorów PRNG za pomocą:
>>>
>>> https://quick-bench.com
>>>
>>> Jedyne sensowne zestawienie, po zliczeniu przez mnie ręcznie liczby cykli na
operacje (wynik 22 do 13), które wykonują algorytmy, dostaję, gdy włączam optim=None.
Jeżeli zaś włączę OFast xoroshiro dostaje takiego przyspieszenia, że wyprzedza drugi
PRNG, według tego benchmarku.
>>>
>>> W samym xoroshiro liczę operację:
>>>
>>> const uint64_t s0 = s[0];
>>>
>>> jako jeden cykl, bo następuje wywołanie zmiennej z tablicy. Ale nie jestem
pewien, czy to tak należy szacować.
>> To zależy od poziomu optymalizacji.
>> Bez optymalizacji na samo to wziąłbym 1 cykl na kopię z pamięci do
>> rejestru i 1 na kopię z rejestru do innej pamięci. Ale wspomniany
>> dokument podaje np. 3 cykle na kopiowanie do pamięci, więc nawet to
>> nie jest takie oczywiste.
>> Z optymalizacją jest szansa, że "s0" siedzi w rejestrze, więc
>> wystarczy pewnie 1 cykl na załadowanie.
>> Oczywiście, jeśli s[0] jest ułożone na równym adresie.
>> Oczywiście, jeśli s[0] siedzi w cache, bo jeśli nie, to w najgorszym
>> przypadku mogą być może dziesiątki, jak nie setki cykli na pobranie z
>> głównej pamięci.
>> I pewnie jeszcze różne inne warunki, więc tabelki tabelkami, ale
>> najlepiej albo pomierzyć (RDTSC), albo użyć narzędzi mówiących, co ile
>> potrwa (kiedyś było np. jakieś VTune Analyzer).
>> --
>> Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
>> Kurs asemblera x86 (DOS, GNU/Linux): http://bogdro.evai.pl
>> Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
>> www.Xiph.org www.TorProject.org Soft(EN): http://bogdro.evai.pl/soft
>
> Ok, czyli liczę to raczej prawidłowo. Przykładowe szacunki:
>
> class xoroshiro256plus {
>
> uint64_t s[4] = { 5, 11, 13, 99 };
>
> static uint64_t rotl(const uint64_t x, int k)
> {
> return (x << k) | (x >> (64 - k));
> }
>
> public:
> uint64_t next() noexcept
> {
> const uint64_t result = s[0] + s[3]; // 3 cycles
>
> const uint64_t t = s[1] << 17; // 2 cycles
>
> s[2] ^= s[0]; // 4 cycles
> s[3] ^= s[1]; // 4 cycles
> s[1] ^= s[2]; // 4 cycles
> s[0] ^= s[3]; // 4 cycles
>
> s[2] ^= t; // 2 cycles
>
> s[3] = rotl(s[3], 45); // 6 cycles
>
> return result;
> }
> };
>
> //Xoroshiro256+ ma 29 cykli.


Jak już pisałem - to może zależeć od konkretnego modelu procesora...
Nie tylko od tego, że jest 64-bitowy. I od poziomu optymalizacji.

result = s[0] + s[3];
// jeśli result idzie do pamięci
// mov + mov + add + mov = 2+2+1+3
// mov + add + mov = 2+6+3
// jeśli result idzie do rejestru
// mov + mov + add = 2+2+1
// mov + add = 2+6

const uint64_t t = s[1] << 17;
// jeśli t idzie do pamięci
// mov + shl + mov = 2+1+3
// jeśli t idzie do rejestru
// mov + shl = 2+1

I tak dalej...

--
Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux): http://bogdro.evai.pl
Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org Soft(EN): http://bogdro.evai.pl/soft