🚀 go-pugleaf

W dniu piątek, 13 grudnia 2019 08:34:44 UTC+1 użytkownik Piotr Chamera napisał:
> W dniu 2019-12-13 o 06:42, osobliwy nick pisze:
> > 166 mikrosekund wziąłem z wyliczeń Piotra Chamera. Z tego co Ty napisałeś wynika zaś, że można to zrobić 50 razy szybciej. 10 nanosekund dla 64-bitowych liczb na iterację, dla 128-bitowych - 3 razy wolniej, czyli 30 nanosekund. To daje 128*30=3840 nanosekund na 128 iteracji (czyli 3,84 mikrosekund). Wówczas wychodzi:
> > 
> > 1000000/3,84*128/20*1/2^20 = 1,59 MB/s
> > 
> > Nie rozumiem w takim razie tylko skąd taka rozbieżność pomiędzy tym co piszesz Ty, a tym co policzył Piotra Chamera.
> 
> Muszę się odezwać, bo tu jakieś absurdy wychodzą. Napisałem na szybko 
> zupełnie niezoptymalizowany program, który policzył przykładowy algorytm 
> w 166 ms. O czym to świadczy? Tylko o tym, że bez wysiłku można taki 
> czas uzyskać. Trzeba też wziąć pod uwagę, że jest to program zupełnie 
> bez ograniczeń na to jak duże są liczby, czy są całkowite itp.
> 
> Kolega fir oszacował, że ten sam algorytm można policzyć wielokrotnie 
> szybciej i to też prawda. Szczególnie jeśli da się ustalić, że wszystko 
> da się np. policzyć na 128 bitowych liczbach całkowitych bez znaku :)
> O ile to będzie szybciej okaże się kiedy ktoś to napisze w konkretnym 
> języku, skompiluje i uruchomi na konkretnym procesorze (50 razy szybciej 
> względem mojego przykładu jest jak najbardziej realne :).

Ok, rozumiem. Nie sądziłem, że rozbieżności w zależności od tego jak napiszemy program mogą być aż tak duże. Dobrze jednak, że istnieje potencjał na usprawnienie tego aż o powiedzmy 2 rzędy wielkości. Reszta jest, jak rozumiem, kwestią konkretnych testów. Będę myślał zatem o takich testach, na razie jednak takie wstępne szacunki mi wystarczą. Wcześniej mam do rozwiązania jeszcze kilka innych problemów związanych z algorytmem.