🚀 go-pugleaf

On 14/05/2023 16:00, osobli...@gmail.com wrote:
> niedziela, 14 maja 2023 o 11:28:17 UTC+2 Bogdan napisał(a):
>> On 13/05/2023 19:43, osobli...@gmail.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