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.