Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33526 > unrolled thread

Ile zajmie komputerowi mnożenie liczb rzędu 2^128

Back to article view | Back to pl.comp.programming

Contents

  Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-03 15:19 -0800
    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 "Radoslaw Szwed" <radekszwed@pochta.fm> - 2019-12-04 10:41 +0100
      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 "Radoslaw Szwed" <radekszwed@pochta.fm> - 2019-12-04 11:55 +0100
        Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-04 03:43 -0800
          Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2019-12-04 13:25 +0100
            Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-04 04:46 -0800
    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2019-12-04 13:02 +0100
      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-04 04:55 -0800
        Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-04 16:19 -0800
          Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-04 18:11 -0800
            Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-04 18:12 -0800
            Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-05 01:17 -0800
              Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy.nick@gmail.com - 2019-12-05 12:18 -0800
                Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-07 13:17 -0800
                  Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-10 18:09 -0800
                    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-12 05:09 -0800
                      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-12 05:16 -0800
                      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-12 21:42 -0800
                        Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2019-12-13 08:34 +0100
                          Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-13 16:59 -0800
                        Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-13 06:17 -0800
                          Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-13 16:56 -0800
                            Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-14 03:14 -0800
                Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2019-12-07 13:22 -0800
    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 "Radoslaw Szwed" <radekszwed@pochta.fm> - 2019-12-10 10:29 +0100
      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-10 18:24 -0800
    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2019-12-11 21:15 -0800
    Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2020-05-25 12:55 -0700
      Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2020-05-26 01:35 -0700
        Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 osobliwy nick <osobliwy.nick@gmail.com> - 2020-05-27 12:12 -0700
          Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2020-05-27 13:58 -0700
            Re: Ile zajmie komputerowi mnożenie liczb rzędu 2^128 fir <profesor.fir@gmail.com> - 2020-05-27 14:03 -0700

Page 1 of 2  [1] 2  Next page →

#33526 — Ile zajmie komputerowi mnożenie liczb rzędu 2^128

Cześć. Badam pewne funkcje pod kątem zastosowań kryptograficznych. I mam następujący problem. Muszę oszacować ile czasu zajmie mnożenie liczby 2^128-5, z dodawaniem. Konkretnie - w pierwszym kroku obliczamy (2^128-5)*2,5+2,5, następnie dzielimy całość przez 2. A potem znów wynik mnożymy razy 2,5 i dodajemy 2,5. I znów dzielimy wynik przez 2. Musimy w sumie wykonać 128 takich operacji, to jest 64 mnożenia z dodawaniem i 64 dzielenia przez 2.

Dosyć łatwo wykazać, że liczba końcowa będzie całkowita i każda liczba uzyskana po drodze też będzie całkowita. Ale nie chodzi mi o wynik, tylko o sprawdzenie ile komputerowi zajmie policzenie czegoś takiego. 

Zaznaczę, że dla tak dużych liczb szybko tracona jest precyzja. Jestem laikiem, ale z tego co wiem trzeba do tego albo specjalnych bibliotek albo jakichś własnych rozwiązań do wykonywania obliczeń na tak dużych liczbach (które pewnie będą znacznie wolniejsze, niż dedykowane, specjalne biblioteki, które stworzyli np. naukowcy do różnych zaawansowanych obliczeń).

Czy ktoś jest w stanie wykonać takie obliczenia i zmierzyć czas? A może możecie podsunąć jakiś sensowny sposób oszacowania tego?

[toc] | [next] | [standalone]

#33527

Użytkownik <osobliwy.nick@gmail.com> napisał w wiadomości news:b7426ee8-be56-48fc-9657-da5a18e0729b@googlegroups.com...

> Cześć. Badam pewne funkcje pod kątem zastosowań kryptograficznych. I mam następujący problem. Muszę oszacować ile czasu zajmie 
> mnożenie liczby 2^128-5, z dodawaniem. Konkretnie - w pierwszym kroku obliczamy (2^128-5)*2,5+2,5, następnie dzielimy całość przez 
> 2. A potem znów wynik mnożymy razy 2,5 i dodajemy 2,5. I znów dzielimy wynik przez 2. Musimy w sumie wykonać 128 takich operacji, 
> to jest 64 mnożenia z dodawaniem i 64 dzielenia przez 2.

> Dosyć łatwo wykazać, że liczba końcowa będzie całkowita i każda liczba uzyskana po drodze też będzie całkowita. ...

Naprawdę będzie całkowita? Tak z ciekawości sprawdziłem dla 2^64

2^64 -5= 18446744073709551611 * 2,5= 46116860184273879027,5 +2,5= 46116860184273879030 /2
=23058430092136939515 * 2,5  =57646075230342348787,5 +2,5 = 57646075230342348790 /2 =
28823037615171174395 *2,5= 72057594037927935993,75 + 2,5 ...

[toc] | [prev] | [next] | [standalone]

#33528

Użytkownik "Radoslaw Szwed" <radekszwed@pochta.fm> napisał w wiadomości news:qs7uv5$col$1@gioia.aioe.org...
>
> Użytkownik <osobliwy.nick@gmail.com> napisał w wiadomości news:b7426ee8-be56-48fc-9657-da5a18e0729b@googlegroups.com...
>
>> Cześć. Badam pewne funkcje pod kątem zastosowań kryptograficznych. I mam następujący problem. Muszę oszacować ile czasu zajmie 
>> mnożenie liczby 2^128-5, z dodawaniem. Konkretnie - w pierwszym kroku obliczamy (2^128-5)*2,5+2,5, następnie dzielimy całość 
>> przez 2. A potem znów wynik mnożymy razy 2,5 i dodajemy 2,5. I znów dzielimy wynik przez 2. Musimy w sumie wykonać 128 takich 
>> operacji, to jest 64 mnożenia z dodawaniem i 64 dzielenia przez 2.
>
>> Dosyć łatwo wykazać, że liczba końcowa będzie całkowita i każda liczba uzyskana po drodze też będzie całkowita. ...
>
> Naprawdę będzie całkowita? Tak z ciekawości sprawdziłem dla 2^64
>
> 2^64 -5= 18446744073709551611 * 2,5= 46116860184273879027,5 +2,5= 46116860184273879030 /2
> =23058430092136939515 * 2,5  =57646075230342348787,5 +2,5 = 57646075230342348790 /2 =
> 28823037615171174395 *2,5= 72057594037927935993,75 + 2,5 ...

Coś mi się źle wymnożyło :)

[toc] | [prev] | [next] | [standalone]

#33529

> > Naprawdę będzie całkowita? Tak z ciekawości sprawdziłem dla 2^64
> >
> > 2^64 -5= 18446744073709551611 * 2,5= 46116860184273879027,5 +2,5= 46116860184273879030 /2
> > =23058430092136939515 * 2,5  =57646075230342348787,5 +2,5 = 57646075230342348790 /2 =
> > 28823037615171174395 *2,5= 72057594037927935993,75 + 2,5 ...
> 
> Coś mi się źle wymnożyło :)

Chyba tak. Kilka pierwszych wyrazów:

850705917302346158658436518579420528630

425352958651173079329218259289710264315

1063382396627932698323045648224275660790

531691198313966349161522824112137830395

1329227995784915872903807060280344575990

664613997892457936451903530140172287995

1661534994731144841129758825350430719990

830767497365572420564879412675215359995

2076918743413931051412198531688038399990

1038459371706965525706099265844019199995

[toc] | [prev] | [next] | [standalone]

#33531

W dniu 2019-12-04 o 12:43, osobliwy.nick@gmail.com pisze:
>>> Naprawdę będzie całkowita? Tak z ciekawości sprawdziłem dla 2^64
>>>
>>> 2^64 -5= 18446744073709551611 * 2,5= 46116860184273879027,5 +2,5= 46116860184273879030 /2
>>> =23058430092136939515 * 2,5  =57646075230342348787,5 +2,5 = 57646075230342348790 /2 =
>>> 28823037615171174395 *2,5= 72057594037927935993,75 + 2,5 ...
>>
>> Coś mi się źle wymnożyło :)
> 
> Chyba tak. Kilka pierwszych wyrazów:
> 
> 850705917302346158658436518579420528630
> 
> 425352958651173079329218259289710264315
> 
> 1063382396627932698323045648224275660790
> 
> 531691198313966349161522824112137830395
> 
> 1329227995784915872903807060280344575990
> 
> 664613997892457936451903530140172287995
> 
> 1661534994731144841129758825350430719990
> 
> 830767497365572420564879412675215359995
> 
> 2076918743413931051412198531688038399990
> 
> 1038459371706965525706099265844019199995
> 

Jeśli się gdzieś nie pomyliłem, to komplet wyników
pośrednich (po mnożeniu, dodawaniu i dzieleniu) to:

340282366920938463463374607431768211451
425352958651173079329218259289710264315
531691198313966349161522824112137830395
664613997892457936451903530140172287995
830767497365572420564879412675215359995
1038459371706965525706099265844019199995
1298074214633706907132624082305023999995
1622592768292133633915780102881279999995
2028240960365167042394725128601599999995
2535301200456458802993406410751999999995
3169126500570573503741758013439999999995
3961408125713216879677197516799999999995
4951760157141521099596496895999999999995
6189700196426901374495621119999999999995
7737125245533626718119526399999999999995
9671406556917033397649407999999999999995
12089258196146291747061759999999999999995
15111572745182864683827199999999999999995
18889465931478580854783999999999999999995
23611832414348226068479999999999999999995
29514790517935282585599999999999999999995
36893488147419103231999999999999999999995
46116860184273879039999999999999999999995
57646075230342348799999999999999999999995
72057594037927935999999999999999999999995
90071992547409919999999999999999999999995
112589990684262399999999999999999999999995
140737488355327999999999999999999999999995
175921860444159999999999999999999999999995
219902325555199999999999999999999999999995
274877906943999999999999999999999999999995
343597383679999999999999999999999999999995
429496729599999999999999999999999999999995
536870911999999999999999999999999999999995
671088639999999999999999999999999999999995
838860799999999999999999999999999999999995
1048575999999999999999999999999999999999995
1310719999999999999999999999999999999999995
1638399999999999999999999999999999999999995
2047999999999999999999999999999999999999995
2559999999999999999999999999999999999999995
3199999999999999999999999999999999999999995
3999999999999999999999999999999999999999995
4999999999999999999999999999999999999999995
6249999999999999999999999999999999999999995
7812499999999999999999999999999999999999995
9765624999999999999999999999999999999999995
12207031249999999999999999999999999999999995
15258789062499999999999999999999999999999995
19073486328124999999999999999999999999999995
23841857910156249999999999999999999999999995
29802322387695312499999999999999999999999995
37252902984619140624999999999999999999999995
46566128730773925781249999999999999999999995
58207660913467407226562499999999999999999995
72759576141834259033203124999999999999999995
90949470177292823791503906249999999999999995
113686837721616029739379882812499999999999995
142108547152020037174224853515624999999999995
177635683940025046467781066894531249999999995
222044604925031308084726333618164062499999995
277555756156289135105907917022705078124999995
346944695195361418882384896278381347656249995
433680868994201773602981120347976684570312495
542101086242752217003726400434970855712890620

ale dalsze iteracje już są ułamkowe.

dla 2^64 całkowite są tylko do 32 iteracji:

18446744073709551611
23058430092136939515
28823037615171174395
36028797018963967995
45035996273704959995
56294995342131199995
70368744177663999995
87960930222079999995
109951162777599999995
137438953471999999995
171798691839999999995
214748364799999999995
268435455999999999995
335544319999999999995
419430399999999999995
524287999999999999995
655359999999999999995
819199999999999999995
1023999999999999999995
1279999999999999999995
1599999999999999999995
1999999999999999999995
2499999999999999999995
3124999999999999999995
3906249999999999999995
4882812499999999999995
6103515624999999999995
7629394531249999999995
9536743164062499999995
11920928955078124999995
14901161193847656249995
18626451492309570312495
23283064365386962890620
116415321826934814453105/4
582076609134674072265545/16
2910383045673370361327805/64
14551915228366851806639345/256
72759576141834259033198005/1024
363797880709171295165995145/4096
1818989403545856475829996205/16384
9094947017729282379150062945/65536
45474735088646411895750642405/262144
227373675443232059478754522745/1048576
1136868377216160297393777856605/4194304
5684341886080801486968910254545/16777216
28421709430404007434844635158805/67108864
142108547152020037174223511338345/268435456
710542735760100185871118898869005/1073741824
3552713678800500929355599863054145/4294967296
17763568394002504646778020790107205/17179869184
88817841970012523233890189849881945/68719476736
444089209850062616169451292846793405/274877906944
2220446049250313080847257838623501745/1099511627776
11102230246251565404236294690675647605/4398046511104
55511151231257827021181495443610793545/17592186044416
277555756156289135105907565178984189805/70368744177664
1387778780781445675529538177738641837345/281474976710656
6938893903907228377647692296068092740005/1125899906842624
34694469519536141888238467109839997913145/4503599627370496
173472347597680709441192358067198126418205/18014398509481984
867361737988403547205961880407983179500945/72057594037927936
4336808689942017736029809762327886087144405/288230376151711744
21684043449710088680149050252791311194280745/1152921504606846976
108420217248550443400745257028564079005638605/4611686018427387904
542101086242752217003726308201250487165132545/18446744073709551616

[toc] | [prev] | [next] | [standalone]

#33532

> ale dalsze iteracje już są ułamkowe.

Zgadza się. Traktujesz mnożenie z dzieleniem jako jedną operację. Natomiast są to dwie operacje. 
 
> dla 2^64 całkowite są tylko do 32 iteracji:

To też się zgadza. Zrobiłeś tak naprawdę 64 iteracje, wypisałeś tylko nieparzyste. Ogólnie nie można tego w żaden sposób skrócić. Trzeba liczyć tak jak jest. Czyli a*2,5+2,5=b. A dopiero później dzielimy przez 2.

To wynika z definicji funkcji, którą rozważam:

f(x) = 2,5*x+2,5  -  gdy x jest nieparzyste

f(x) = x/2  -  gdy x jest parzyste

Dla liczb 2^n-5 jest ją łatwo liczyć. Ale gdy spróbujemy 2^n-19, to nie ma dróg na skróty. Kolejne wyrazy raz są nieparzyste, raz parzyste - brak wyraźnego wzorca. Stąd w każdym trzeba sprawdzać ich parzystość i albo dzielić przez 2 albo mnożyć z dodawaniem. Dlatego nie chciałem, żebyście stosowali jakieś skróty, czy uproszczenia wynikające z matematyki, bo w większości przypadków nie da się ich zastosować.

[toc] | [prev] | [next] | [standalone]

#33530

W dniu 2019-12-04 o 00:19, osobliwy.nick@gmail.com pisze:
> Cześć. Badam pewne funkcje pod kątem zastosowań kryptograficznych. I mam następujący problem. Muszę oszacować ile czasu zajmie mnożenie liczby 2^128-5, z dodawaniem. Konkretnie - w pierwszym kroku obliczamy (2^128-5)*2,5+2,5, następnie dzielimy całość przez 2. A potem znów wynik mnożymy razy 2,5 i dodajemy 2,5. I znów dzielimy wynik przez 2. Musimy w sumie wykonać 128 takich operacji, to jest 64 mnożenia z dodawaniem i 64 dzielenia przez 2.
> 
> Dosyć łatwo wykazać, że liczba końcowa będzie całkowita i każda liczba uzyskana po drodze też będzie całkowita. Ale nie chodzi mi o wynik, tylko o sprawdzenie ile komputerowi zajmie policzenie czegoś takiego.
> 
> Zaznaczę, że dla tak dużych liczb szybko tracona jest precyzja. Jestem laikiem, ale z tego co wiem trzeba do tego albo specjalnych bibliotek albo jakichś własnych rozwiązań do wykonywania obliczeń na tak dużych liczbach (które pewnie będą znacznie wolniejsze, niż dedykowane, specjalne biblioteki, które stworzyli np. naukowcy do różnych zaawansowanych obliczeń).
> 
> Czy ktoś jest w stanie wykonać takie obliczenia i zmierzyć czas? A może możecie podsunąć jakiś sensowny sposób oszacowania tego?
> 

Rzeczywiście wychodzi liczba całkowita, ale dla pojedynczej takiej pętli 
czas jest niemierzalny w tej implementacji lispu

CL-USER> (time
	  (let ((x (- (expt 2 128) 5)))
	   (dotimes (i 64)
	     (setf x (/ (+ (* x 5/2)
			   5/2)
			2)))
	   x))

wynik:

542101086242752217003726400434970855712890620


(LET ((X (- (EXPT 2 128) 5))) (DOTIMES (I 64) (SETF X (/ (+ (* X 5/2) 
5/2) 2))) X)
took 0 microseconds (0.000000 seconds) to run.
During that period, and with 6 available CPU cores,
      0 microseconds (0.000000 seconds) were spent in user mode
      0 microseconds (0.000000 seconds) were spent in system mode
  22,592 bytes of memory allocated.

Dla 1000 powtórzeń pętli mamy

(DOTIMES (N 1000) (LET ((X (- (EXPT 2 128) 5))) (DOTIMES (I 64) (SETF X 
(/ (+ (* X 5/2) 5/2) 2))) X))
took 166,000 microseconds (0.166000 seconds) to run.
        9,762 microseconds (0.009762 seconds, 5.88%) of which was spent 
in GC.
During that period, and with 6 available CPU cores,
      156,250 microseconds (0.156250 seconds) were spent in user mode
            0 microseconds (0.000000 seconds) were spent in system mode
  22,528,064 bytes of memory allocated.

czyli wychodziłoby 166 mikrosekund na takie obliczenie.

Ale trzeba pamiętać, że to jest nieoptymalizowany program w lispie,
na pewno można napisać program, który policzy to szybciej.

[toc] | [prev] | [next] | [standalone]

#33533

> czyli wychodziłoby 166 mikrosekund na takie obliczenie.
> 
> Ale trzeba pamiętać, że to jest nieoptymalizowany program w lispie,
> na pewno można napisać program, który policzy to szybciej.

Dzięki za pomoc. Niestety to dużo za dużo. Spodziewałem się wielkości o dwa rzędy mniejszej. Nawet optymalizacja nie sprawi chyba, że mogłoby to być 0,5 mikrosekundy, nie? 

Generalnie chciałbym, aby było to dokładnie 0,1 lub okolice tych czasów. Jest pewien algorytm, który na procesorze klasy Pentium M o szybkości 1.7 GHz ma właśnie taką wydajność szyfrowania, bo o szyfrowanie cały czas chodzi. Oczywiście działa on zupełnie inaczej od mojego, ale muszę w takim razie tak dobrać parametry, aby zbliżyć się do tej prędkości.

Czy byłbyś w stanie sprawdzić mniejsze przypadki, np. liczbę 2^100-5 dla 100 iteracji? Ogólnie znaleźć takie n, że dla n iteracji na liczbie 2^n-5 ten czas będzie wynosił ok. 0,1 mikrosekundy?

[toc] | [prev] | [next] | [standalone]

#33534

W dniu środa, 4 grudnia 2019 13:55:15 UTC+1 użytkownik osobli...@gmail.com napisał:
> > czyli wychodziłoby 166 mikrosekund na takie obliczenie.
> > 
> > Ale trzeba pamiętać, że to jest nieoptymalizowany program w lispie,
> > na pewno można napisać program, który policzy to szybciej.
> 
> Dzięki za pomoc. Niestety to dużo za dużo. Spodziewałem się wielkości o dwa rzędy mniejszej. Nawet optymalizacja nie sprawi chyba, że mogłoby to być 0,5 mikrosekundy, nie? 
> 
> Generalnie chciałbym, aby było to dokładnie 0,1 lub okolice tych czasów. Jest pewien algorytm, który na procesorze klasy Pentium M o szybkości 1.7 GHz ma właśnie taką wydajność szyfrowania, bo o szyfrowanie cały czas chodzi. Oczywiście działa on zupełnie inaczej od mojego, ale muszę w takim razie tak dobrać parametry, aby zbliżyć się do tej prędkości.
> 
> Czy byłbyś w stanie sprawdzić mniejsze przypadki, np. liczbę 2^100-5 dla 100 iteracji? Ogólnie znaleźć takie n, że dla n iteracji na liczbie 2^n-5 ten czas będzie wynosił ok. 0,1 mikrosekundy?

troche nudne to pytanie, ale mozesz zalozyc ze proste operacje (dodawanie, mnozenei , shift) na 64 bitowym incie zajmuje w granicach 1-5 cykli (powiedzmy) 

czyli w temacie zgrubnego ogarniecia mozesz zalozyc ze jedna operacje zajmuje okolo 1 nanosekunde

z tym ze taki mnozenie przez 2.5 to raczej jest mnozenie x przez dwa i dodanie polowy x czyli

((x<<1) + (x>>1)) + 2.5

4 operacje, zalozmy ze to zajmuje 4 ns (mozliwe ze w praktyce zajmie ciut mniej, moze ze 2 ns)

wiec sto iteracji tego zajmie 400 ns (200 ns?) 

to przy zalozeniu ze mowimy o obliczeniach ktore sie da zrobi na 64 bitowych integerach, jak robi sie to na 128 bitowych integereach mysle ze zjamie to minimum 2 razy tyle (zief)

swoje droga esli to jest iteracja na stalej 2^128 - 5 to wynik konkretnej liczby iteracji na tym (np 100) jest znany i nie trzeba tego liczyc wiec wyliczenie tego wynosi 0 czasu (i dlatego tez niekonkretne pytaia sa nie tylko niecialawe ale i denerwujace (ziew))

[toc] | [prev] | [next] | [standalone]

#33535

> swoje droga esli to jest iteracja na stalej 2^128 - 5 to wynik konkretnej liczby iteracji na tym (np 100) jest znany i nie trzeba tego liczyc wiec wyliczenie tego wynosi 0 czasu (i dlatego tez niekonkretne pytaia sa nie tylko niecialawe ale i denerwujace (ziew))

To jest tylko część bardziej złożonego problemu nad którym się głowię. Może on wyda Ci się ciekawszy. Rozważmy funkcje rekurencyjne o następującej definicji:

f(x) = a/2*x+b/2  -  gdy x jest nieparzyste
f(x) = x2  -  gdy x jest parzyste

a i b to jakieś liczby nieparzyste, a x może być dowolną liczbą naturalną. Określając a i b dostajemy jakiś ciąg zdefiniowany za pomocą funkcji rekurencyjnej. Najsłynniejszym z nich jest ciąg Collatza, którego dotyczy nierozwiązania do dziś hipoteza. Ciąg Collatza dostaniemy dla a=3 i b=1. Weźmy pary a, b z przedziału (-7,-5, ..., 5, 7). Będzie ich tyle co wariacji z powtórzeniami, 2-wyrazowych, w zbiorze 8-elementowym, czyli 64. Dla każdej z takich 64 par a i b mamy zdefiniowaną jakąś funkcję rekurencyjną. To co chcę oszacować, to ile zajmie policzenie w każdej z tych 64 funkcji n iteracji dla kolejnych liczb naturalnych z przedziału od 1 do 2^n. Np. dla a=5 i b=3 oraz n=3 mamy do policzenia iteracje dla liczb 1,2,3,...,8:

1,4,2,1
2,1,4,2
3,9,24,12
4,2,1,4
5,14,7,19
6,3,9,24
7,19,49,124
8,4,2,1

Rzecz w tym, że interesują mnie duże n, rzędu minimum 50, a najlepiej rzędu 100. Nie wiem, czy to jest bardziej interesujące? Na pewno żaden komputer tego nie policzy w żadnym czasie np. dla n=128. Łatwo policzyć, że, jeśli średnio taki ciąg jest liczony np. przez 100 mikrosekund, to obliczenia dla 64 par a i b zajmą 64*100*1/1000000*2^128 sekund, czyli może jeszcze nastąpi to przed śmiercią cieplną Wszechświata, a może nie. Dlatego trzeba policzyć średni przypadek i ten, który podałem jest średnim przypadkiem, można bowiem udowodnić, że średnio w tych ciągach w przedziale liczb od 1 do 2^n wystąpi tyle samo mnożeń z dodawaniem, co dzieleń. Natomiast potrzebuję to oszacować, bo zamierzam stworzyć algorytm, który będzie się wymagał obliczenia losowego x z przedziału od 1 do 2^n dla losowej pary a i b. I chcę wiedzieć ile średnio zajmie to czasu. W szczególności jakie maksymalne n mogę przyjąć, aby taki pojedynczy ciąg był liczony około 0,1 mikrosekundy.

[toc] | [prev] | [next] | [standalone]

#33536

Jeszcze raz definicja:

f(x) = a/2*x+b/2  -  gdy x jest nieparzyste
f(x) = x/2  -  gdy x jest parzyste

Zjadłem znak dzielnika dla x parzystych.

[toc] | [prev] | [next] | [standalone]

#33537

W dniu czwartek, 5 grudnia 2019 03:11:18 UTC+1 użytkownik osobli...@gmail.com napisał:
> > swoje droga esli to jest iteracja na stalej 2^128 - 5 to wynik konkretnej liczby iteracji na tym (np 100) jest znany i nie trzeba tego liczyc wiec wyliczenie tego wynosi 0 czasu (i dlatego tez niekonkretne pytaia sa nie tylko niecialawe ale i denerwujace (ziew))
> 
> To jest tylko część bardziej złożonego problemu nad którym się głowię. Może on wyda Ci się ciekawszy. Rozważmy funkcje rekurencyjne o następującej definicji:
> 
> f(x) = a/2*x+b/2  -  gdy x jest nieparzyste
> f(x) = x2  -  gdy x jest parzyste
> 
> a i b to jakieś liczby nieparzyste, a x może być dowolną liczbą naturalną. Określając a i b dostajemy jakiś ciąg zdefiniowany za pomocą funkcji rekurencyjnej. Najsłynniejszym z nich jest ciąg Collatza, którego dotyczy nierozwiązania do dziś hipoteza. Ciąg Collatza dostaniemy dla a=3 i b=1. Weźmy pary a, b z przedziału (-7,-5, ..., 5, 7). Będzie ich tyle co wariacji z powtórzeniami, 2-wyrazowych, w zbiorze 8-elementowym, czyli 64. Dla każdej z takich 64 par a i b mamy zdefiniowaną jakąś funkcję rekurencyjną. To co chcę oszacować, to ile zajmie policzenie w każdej z tych 64 funkcji n iteracji dla kolejnych liczb naturalnych z przedziału od 1 do 2^n. Np. dla a=5 i b=3 oraz n=3 mamy do policzenia iteracje dla liczb 1,2,3,...,8:
> 
> 1,4,2,1
> 2,1,4,2
> 3,9,24,12
> 4,2,1,4
> 5,14,7,19
> 6,3,9,24
> 7,19,49,124
> 8,4,2,1
> 
> Rzecz w tym, że interesują mnie duże n, rzędu minimum 50, a najlepiej rzędu 100. Nie wiem, czy to jest bardziej interesujące? Na pewno żaden komputer tego nie policzy w żadnym czasie np. dla n=128. Łatwo policzyć, że, jeśli średnio taki ciąg jest liczony np. przez 100 mikrosekund, to obliczenia dla 64 par a i b zajmą 64*100*1/1000000*2^128 sekund, czyli może jeszcze nastąpi to przed śmiercią cieplną Wszechświata, a może nie. Dlatego trzeba policzyć średni przypadek i ten, który podałem jest średnim przypadkiem, można bowiem udowodnić, że średnio w tych ciągach w przedziale liczb od 1 do 2^n wystąpi tyle samo mnożeń z dodawaniem, co dzieleń. Natomiast potrzebuję to oszacować, bo zamierzam stworzyć algorytm, który będzie się wymagał obliczenia losowego x z przedziału od 1 do 2^n dla losowej pary a i b. I chcę wiedzieć ile średnio zajmie to czasu. W szczególności jakie maksymalne n mogę przyjąć, aby taki pojedynczy ciąg był liczony około 0,1 mikrosekundy.

dla mnie to wogole nie jest interesujace, a jesli chcesz odpowiedz to raczej staraj sie zadac pytanie w jakis zachecajacy sposob (bez glupot i dziur logicznych oraz w miare krotki i nie mulace - bo ludzie sa leniwi, zwlaszcza na starosc ;c)


jak oszacowac czas obliczen napisalem 
takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez 2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z 15-20 cykli)

takie cos 
> f(x) = a/2*x + b/2  -  gdy x jest nieparzyste
> f(x) = x2  -  gdy x jest parzyste

(w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma obcinac bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie oszacowac na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio optymistycznie) (jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3 razy wolniej)

napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki - podejrzewam ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie dawal nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego - ale jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w okolicach kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w granicach 5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)

oczywiste jest ze nie w czasie tego kawalka jest problem tylko w tej kombinatoryce a ja trzeba jakos optymalizowac w inny sposob (matematycznie, hackerskom itd..nie che mis ie w to wnikac bo to za nudne dla mnie)

[toc] | [prev] | [next] | [standalone]

#33538

 > dla mnie to wogole nie jest interesujace
Kwestia gustu, mnie fascynują te problemy, zwłaszcza, że mają istotne związki z hipotezą Collatza. Chaos deterministyczny, Wolfram rules, automaty komórkowe - dla mnie to wszystko ciekawe rzeczy.

> a jesli chcesz odpowiedz to raczej staraj sie zadac pytanie w jakis zachecajacy sposob (bez glupot i dziur logicznych oraz w miare krotki i nie mulace - bo ludzie sa leniwi, zwlaszcza na starosc ;c)
Nie wiem jaki to jest zachęcający sposób, ale wnioskuję, że po prosty zwięzły i konkretny, to masz pewnie na myśli.

> jak oszacowac czas obliczen napisalem 
> takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez 2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z 15-20 cykli)
Ok, rozumiem.

> takie cos 
> > f(x) = a/2*x + b/2  -  gdy x jest nieparzyste
> > f(x) = x2  -  gdy x jest parzyste
> 
> (w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma obcinac bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie oszacowac na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio optymistycznie) (jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3 razy wolniej)
Ok, daje mi to jakieś ogólne pojęcie.

> napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki - podejrzewam ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie dawal nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego - ale jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w okolicach kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w granicach 5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)
Rozumiem. Czyli wszystko w sumie rozbija się w tym przypadku o napisanie konkretnego programu od A do Z i sprawdzenie tego. Dodam tylko, że nie umiem programować, zapomniałem swój kurs programowania z podstaw w C ze studiów, nie pamiętam jak uruchomić program, w czym to się kompilowało itd. Dlatego pytam Was i nie sprawdzę sobie tego sam, dopóki nie zrobię solidnej powtórki. Poza tym chciałem mieć tylko ogólne pojęcie nt. tego, czy realne jest zbliżenie się przy parametrze n=100 do czasów 0,5 mikrosekundy. Wydaje się to być możliwe, ale tak na 100% nie wiadomo.

[toc] | [prev] | [next] | [standalone]

#33546

W dniu czwartek, 5 grudnia 2019 21:18:48 UTC+1 użytkownik osobliwy nick napisał:
> > dla mnie to wogole nie jest interesujace
> Kwestia gustu, mnie fascynują te problemy, zwłaszcza, że mają istotne związki z hipotezą Collatza. Chaos deterministyczny, Wolfram rules, automaty komórkowe - dla mnie to wszystko ciekawe rzeczy.
> 
> > a jesli chcesz odpowiedz to raczej staraj sie zadac pytanie w jakis zachecajacy sposob (bez glupot i dziur logicznych oraz w miare krotki i nie mulace - bo ludzie sa leniwi, zwlaszcza na starosc ;c)
> Nie wiem jaki to jest zachęcający sposób, ale wnioskuję, że po prosty zwięzły i konkretny, to masz pewnie na myśli.
> 
> > jak oszacowac czas obliczen napisalem 
> > takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez 2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z 15-20 cykli)
> Ok, rozumiem.
> 
> > takie cos 
> > > f(x) = a/2*x + b/2  -  gdy x jest nieparzyste
> > > f(x) = x2  -  gdy x jest parzyste
> > 
> > (w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma obcinac bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie oszacowac na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio optymistycznie) (jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3 razy wolniej)
> Ok, daje mi to jakieś ogólne pojęcie.
> 
> > napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki - podejrzewam ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie dawal nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego - ale jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w okolicach kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w granicach 5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)
> Rozumiem. Czyli wszystko w sumie rozbija się w tym przypadku o napisanie konkretnego programu od A do Z i sprawdzenie tego. Dodam tylko, że nie umiem programować, zapomniałem swój kurs programowania z podstaw w C ze studiów, nie pamiętam jak uruchomić program, w czym to się kompilowało itd. Dlatego pytam Was i nie sprawdzę sobie tego sam, dopóki nie zrobię solidnej powtórki. Poza tym chciałem mieć tylko ogólne pojęcie nt. tego, czy realne jest zbliżenie się przy parametrze n=100 do czasów 0,5 mikrosekundy. Wydaje się to być możliwe, ale tak na 100% nie wiadomo.

z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne

wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest glupkowate i przez to traci czas ludziom

jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno tlum chetnych

[toc] | [prev] | [next] | [standalone]

#33555

> z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne

Ma to być algorytm szyfrujący. Operacje, które zadałem są, według moich przewidywań, średnim przypadkiem, który będzie trzeba obliczać. Wykonanie takich obliczeń jest równoznaczne zaszyfrowaniu 2^n * 1/20 bitów (bo trzeba wykonać 20 rund złożonych z identycznego rodzaju obliczeń), w zależności od tego jak dobierzemy n. Nie może być ono jednak za małe, bo obniży to bezpieczeństwo algorytmu. Jeśli 2^n=128, tak jak to określiłem w pierwszym poście, to oznacza, że algorytm będzie działał na blokach 128-bitowych i każdemu takiemu blokowi przypisze inny 128-bitowy, pseudolosowy blok. Szyfry 128-bitowe są takim standardem dzisiaj. Więc, jeśli czas pracy będzie niezadowalający, to może się okazać, że algorytm wielkiej kariery nie zrobi.

Tak jak pisałem, niedoścignionym ideałem, powszechnie dzisiaj stosowanym jest AES, który potrafi szyfrować, jak pisze wikipedia:

On Intel Core i3/i5/i7 and AMD Ryzen CPUs supporting AES-NI instruction set extensions, throughput can be multiple GB/s (even over 10 GB/s).

Czyli nawet 10 GB/s. Przy 166 mikrodekundach mój algorytm byłby w stanie zaszyfrować:

1000000/166*128/20*1/2^20= 0.037 MB/s

To mizernie, ale jeszcze pewnie gdzieś na pograniczu praktycznych zastosowań.

> wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest glupkowate i przez to traci czas ludziom

Ważne dla kogo? Dla mnie jest ważne. Dla ludzi zajmujących się problemem Collatza i kryptografią to pewnie też ważny temat badań. Apple zgłosiło na przykład wniosek patentowy na funkcję hashującą opartą o tego rodzaju funkcje (odrzucony):

https://patents.google.com/patent/US20130108038A1/en

Ktoś opublikował inną funkcję hashującą, korzystającą z tych ciągów (swoją drogą oceniam ją bardzo pozytywnie, myślę, że ma potencjał):

https://arxiv.org/pdf/1801.05079.pdf

Jest też generator liczb (pseudo)losowych bazujący na ciągach Collatza:

https://link.springer.com/article/10.1007/s41870-019-00307-9

Jest praca dotycząca szyfrowania obrazów, przy użyciu ciągów Collatza (na moje oko jednak dosyć naiwna i elementarna, więc raczej chleba z tej mąki nie będzie):

https://www.mdpi.com/1099-4300/20/12/901

Jest oto dosyć niszowa dziedzina matematyki teoretycznej, zaś od niedawna co niektórzy zaczęli dostrzegać w trudnościach związanych z hipotezą Collatza potencjał kryptograficzny. Nikt nie zaproponował jednak jak dotąd funkcji szyfrującej opartej o te ciągi, choć myślę, że jest tylko kwestią czasu, gdy to się stanie (wydaje się to jeszcze poza zasięgiem środowiska naukowego albo poza polem zainteresowań, większość mimo wszystko porywa się na słynną hipotezę lub twierdzenia poboczne, mające przybliżyć nas do jej rozwiązania). Dla kogoś z boku może i nie jest to ważny temat. Ale myślę, że takie Apple z pocałowaniem ręki przyjęłoby kogoś, kto sformułowałby dla nich taki algorytm i są ludzie oraz firmy, które po prostu nad tym pracują. Inna sprawa, że jest to po prostu wyabstrahowana część problemu i algorytmu, która sama w sobie może się wydawać nieinteresująca. Jednocześnie nie chcę publikować algorytmu ot tak w internecie, dopóki nie ocenię jego potencjału i nie podejmę decyzji, co z nim zrobić.

> jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno tlum chetnych

Współpracowałem już z programistami w różnych, prywatnych celach. Raz zleciłem napisanie programu związanego z rozwiązaniem pewnej hipotezy pobocznej związanej z hipotezą Collatza, innym razem pracowałem z pewnym programistą nad strategiami i algorytmami do gry na giełdzie. 200 zł to nie jest dla mnie problem i pewnie prędzej, czy później podejmę z kimś doraźną współpracę, żeby zrobić kompleksowe testy, w tym testy Dieharda, nie tylko pod kątem prędkości działania algorytmu. Tym bardziej, że chciałbym skomercjalizować temat, jeśli dobrze mi się wydaje, że jest coś wart. Ale, żeby udać się np. do jakiegoś funduszu zalążkowego, centrum transferu technologii, na uczelnię, czy skontaktować się z jakąś spółką technologiczną typu IBM, trzeba wiedzieć choć trochę na czym się stoi (stąd współpraca odpłatna i wstępne napisane kodu oraz testy są nieuniknione, wiem o tym). Zanim to jednak zrobię chciałem się choć wstępnie zorientować na co się nastawiać.

[toc] | [prev] | [next] | [standalone]

#33564

W dniu środa, 11 grudnia 2019 03:09:16 UTC+1 użytkownik osobliwy nick napisał:
> > z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne
> 
> Ma to być algorytm szyfrujący. Operacje, które zadałem są, według moich przewidywań, średnim przypadkiem, który będzie trzeba obliczać. Wykonanie takich obliczeń jest równoznaczne zaszyfrowaniu 2^n * 1/20 bitów (bo trzeba wykonać 20 rund złożonych z identycznego rodzaju obliczeń), w zależności od tego jak dobierzemy n. Nie może być ono jednak za małe, bo obniży to bezpieczeństwo algorytmu. Jeśli 2^n=128, tak jak to określiłem w pierwszym poście, to oznacza, że algorytm będzie działał na blokach 128-bitowych i każdemu takiemu blokowi przypisze inny 128-bitowy, pseudolosowy blok. Szyfry 128-bitowe są takim standardem dzisiaj. Więc, jeśli czas pracy będzie niezadowalający, to może się okazać, że algorytm wielkiej kariery nie zrobi.
> 
> Tak jak pisałem, niedoścignionym ideałem, powszechnie dzisiaj stosowanym jest AES, który potrafi szyfrować, jak pisze wikipedia:
> 
> On Intel Core i3/i5/i7 and AMD Ryzen CPUs supporting AES-NI instruction set extensions, throughput can be multiple GB/s (even over 10 GB/s).
> 
> Czyli nawet 10 GB/s. Przy 166 mikrodekundach mój algorytm byłby w stanie zaszyfrować:
> 

10 GB/s ? moze oni licza to dla jakichs 32 rdzeniowych procesorow wtedy moze - nie wiem jak wydajne sa te instrukcje aes-ni ale 10 GB/s to raczej dla wielu procesorow na raz a i tak to wychodziloby kilka/kilkanascie cykli na zaszyfrowanie inta czyli bardzo malo.. mz idzie to wytlumaczyc tylko tym ze to sa dane dla wielu rdzeni 

> 1000000/166*128/20*1/2^20= 0.037 MB/s
> 


kolega jest chyab niezle pijany...
pisalem wyzej ze jedna taka iteracja na incie (4 bajty) moze zjac gdzies w granicach 10 ns (powiedzmy, plus minus, byc moze jest to zbytni pesymizm moze zajelo by tylko 3 ns) sto zajmie wiec w okolicach 1 mikrosekundy, na sekunde wiec wyjdzie to 1M intow czyli 4 MB (na rdzen)

(byc moze jest to zbyt pesymistyczne ale chodzilo mi o zarysowanie rzedu wielkosci, jesli wziac optymistycznie ze to bedzie ze 3 razy szybsze i masz 32 rdzenie to wyjdzie 12*32 = 384 MB/s, a jesli sa te specjalne instrukcje przyspieszajace to kilka razy to moze byc kilka razy wiecej ale i tak z tym 10 GBs tu wydaje sie przesada, chyab ze to na GPU)

(jesli chodzi tylko o wywolywane tych iteracji, nie wiem czego ten algorytm wymaga i jest to za nudne dla mnie odrywac sie od ciekawszych rzeczy i tym zajmowac, sory)

ciezko sie z kolega rozmawia bo kolega ma kalasyczny syndropm nooba czyli wyglaszanie jako pewniki zbioru zalozen ktore kolega uwaza za wazne a ktore widac ze sa mozna watpliwe lub ewidentnie falszywe

> To mizernie, ale jeszcze pewnie gdzieś na pograniczu praktycznych zastosowań.
> 
> > wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest glupkowate i przez to traci czas ludziom
> 
> Ważne dla kogo? Dla mnie jest ważne. Dla ludzi zajmujących się problemem Collatza i kryptografią to pewnie też ważny temat badań. Apple zgłosiło na przykład wniosek patentowy na funkcję hashującą opartą o tego rodzaju funkcje (odrzucony):
> 
> https://patents.google.com/patent/US20130108038A1/en
> 
> Ktoś opublikował inną funkcję hashującą, korzystającą z tych ciągów (swoją drogą oceniam ją bardzo pozytywnie, myślę, że ma potencjał):
> 
> https://arxiv.org/pdf/1801.05079.pdf
> 
> Jest też generator liczb (pseudo)losowych bazujący na ciągach Collatza:
> 
> https://link.springer.com/article/10.1007/s41870-019-00307-9
> 
> Jest praca dotycząca szyfrowania obrazów, przy użyciu ciągów Collatza (na moje oko jednak dosyć naiwna i elementarna, więc raczej chleba z tej mąki nie będzie):
> 
> https://www.mdpi.com/1099-4300/20/12/901
> 
> Jest oto dosyć niszowa dziedzina matematyki teoretycznej, zaś od niedawna co niektórzy zaczęli dostrzegać w trudnościach związanych z hipotezą Collatza potencjał kryptograficzny. Nikt nie zaproponował jednak jak dotąd funkcji szyfrującej opartej o te ciągi, choć myślę, że jest tylko kwestią czasu, gdy to się stanie (wydaje się to jeszcze poza zasięgiem środowiska naukowego albo poza polem zainteresowań, większość mimo wszystko porywa się na słynną hipotezę lub twierdzenia poboczne, mające przybliżyć nas do jej rozwiązania). Dla kogoś z boku może i nie jest to ważny temat. Ale myślę, że takie Apple z pocałowaniem ręki przyjęłoby kogoś, kto sformułowałby dla nich taki algorytm i są ludzie oraz firmy, które po prostu nad tym pracują. Inna sprawa, że jest to po prostu wyabstrahowana część problemu i algorytmu, która sama w sobie może się wydawać nieinteresująca. Jednocześnie nie chcę publikować algorytmu ot tak w internecie, dopóki nie ocenię jego potencjału i nie podejmę decyzji, co z nim zrobić.
> 
> > jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno tlum chetnych
> 
> Współpracowałem już z programistami w różnych, prywatnych celach. Raz zleciłem napisanie programu związanego z rozwiązaniem pewnej hipotezy pobocznej związanej z hipotezą Collatza, innym razem pracowałem z pewnym programistą nad strategiami i algorytmami do gry na giełdzie. 200 zł to nie jest dla mnie problem i pewnie prędzej, czy później podejmę z kimś doraźną współpracę, żeby zrobić kompleksowe testy, w tym testy Dieharda, nie tylko pod kątem prędkości działania algorytmu. Tym bardziej, że chciałbym skomercjalizować temat, jeśli dobrze mi się wydaje, że jest coś wart. Ale, żeby udać się np. do jakiegoś funduszu zalążkowego, centrum transferu technologii, na uczelnię, czy skontaktować się z jakąś spółką technologiczną typu IBM, trzeba wiedzieć choć trochę na czym się stoi (stąd współpraca odpłatna i wstępne napisane kodu oraz testy są nieuniknione, wiem o tym). Zanim to jednak zrobię chciałem się choć wstępnie zorientować na co się nastawiać.

[toc] | [prev] | [next] | [standalone]

#33565

W dniu czwartek, 12 grudnia 2019 14:09:22 UTC+1 użytkownik fir napisał:
> W dniu środa, 11 grudnia 2019 03:09:16 UTC+1 użytkownik osobliwy nick napisał:
> > > z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne
> > 
> > Ma to być algorytm szyfrujący. Operacje, które zadałem są, według moich przewidywań, średnim przypadkiem, który będzie trzeba obliczać. Wykonanie takich obliczeń jest równoznaczne zaszyfrowaniu 2^n * 1/20 bitów (bo trzeba wykonać 20 rund złożonych z identycznego rodzaju obliczeń), w zależności od tego jak dobierzemy n. Nie może być ono jednak za małe, bo obniży to bezpieczeństwo algorytmu. Jeśli 2^n=128, tak jak to określiłem w pierwszym poście, to oznacza, że algorytm będzie działał na blokach 128-bitowych i każdemu takiemu blokowi przypisze inny 128-bitowy, pseudolosowy blok. Szyfry 128-bitowe są takim standardem dzisiaj. Więc, jeśli czas pracy będzie niezadowalający, to może się okazać, że algorytm wielkiej kariery nie zrobi.
> > 
> > Tak jak pisałem, niedoścignionym ideałem, powszechnie dzisiaj stosowanym jest AES, który potrafi szyfrować, jak pisze wikipedia:
> > 
> > On Intel Core i3/i5/i7 and AMD Ryzen CPUs supporting AES-NI instruction set extensions, throughput can be multiple GB/s (even over 10 GB/s).
> > 
> > Czyli nawet 10 GB/s. Przy 166 mikrodekundach mój algorytm byłby w stanie zaszyfrować:
> > 
> 
> 10 GB/s ? moze oni licza to dla jakichs 32 rdzeniowych procesorow wtedy moze - nie wiem jak wydajne sa te instrukcje aes-ni ale 10 GB/s to raczej dla wielu procesorow na raz a i tak to wychodziloby kilka/kilkanascie cykli na zaszyfrowanie inta czyli bardzo malo.. mz idzie to wytlumaczyc tylko tym ze to sa dane dla wielu rdzeni 
> 
> > 1000000/166*128/20*1/2^20= 0.037 MB/s
> > 
> 
> 
> kolega jest chyab niezle pijany...
> pisalem wyzej ze jedna taka iteracja na incie (4 bajty) moze zjac gdzies w granicach 10 ns (powiedzmy, plus minus, byc moze jest to zbytni pesymizm moze zajelo by tylko 3 ns) sto zajmie wiec w okolicach 1 mikrosekundy, na sekunde wiec wyjdzie to 1M intow czyli 4 MB (na rdzen)
> 
> (byc moze jest to zbyt pesymistyczne ale chodzilo mi o zarysowanie rzedu wielkosci, jesli wziac optymistycznie ze to bedzie ze 3 razy szybsze i masz 32 rdzenie to wyjdzie 12*32 = 384 MB/s, a jesli sa te specjalne instrukcje przyspieszajace to kilka razy to moze byc kilka razy wiecej ale i tak z tym 10 GBs tu wydaje sie przesada, chyab ze to na GPU)
> 
> (jesli chodzi tylko o wywolywane tych iteracji, nie wiem czego ten algorytm wymaga i jest to za nudne dla mnie odrywac sie od ciekawszych rzeczy i tym zajmowac, sory)
> 
> ciezko sie z kolega rozmawia bo kolega ma kalasyczny syndropm nooba czyli wyglaszanie jako pewniki zbioru zalozen ktore kolega uwaza za wazne a ktore widac ze sa mozna watpliwe lub ewidentnie falszywe
> 
> > To mizernie, ale jeszcze pewnie gdzieś na pograniczu praktycznych zastosowań.
> > 
> > > wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest glupkowate i przez to traci czas ludziom
> > 
> > Ważne dla kogo? Dla mnie jest ważne. Dla ludzi zajmujących się problemem Collatza i kryptografią to pewnie też ważny temat badań. Apple zgłosiło na przykład wniosek patentowy na funkcję hashującą opartą o tego rodzaju funkcje (odrzucony):
> > 
> > https://patents.google.com/patent/US20130108038A1/en
> > 
> > Ktoś opublikował inną funkcję hashującą, korzystającą z tych ciągów (swoją drogą oceniam ją bardzo pozytywnie, myślę, że ma potencjał):
> > 
> > https://arxiv.org/pdf/1801.05079.pdf
> > 
> > Jest też generator liczb (pseudo)losowych bazujący na ciągach Collatza:
> > 
> > https://link.springer.com/article/10.1007/s41870-019-00307-9
> > 
> > Jest praca dotycząca szyfrowania obrazów, przy użyciu ciągów Collatza (na moje oko jednak dosyć naiwna i elementarna, więc raczej chleba z tej mąki nie będzie):
> > 
> > https://www.mdpi.com/1099-4300/20/12/901
> > 
> > Jest oto dosyć niszowa dziedzina matematyki teoretycznej, zaś od niedawna co niektórzy zaczęli dostrzegać w trudnościach związanych z hipotezą Collatza potencjał kryptograficzny. Nikt nie zaproponował jednak jak dotąd funkcji szyfrującej opartej o te ciągi, choć myślę, że jest tylko kwestią czasu, gdy to się stanie (wydaje się to jeszcze poza zasięgiem środowiska naukowego albo poza polem zainteresowań, większość mimo wszystko porywa się na słynną hipotezę lub twierdzenia poboczne, mające przybliżyć nas do jej rozwiązania). Dla kogoś z boku może i nie jest to ważny temat. Ale myślę, że takie Apple z pocałowaniem ręki przyjęłoby kogoś, kto sformułowałby dla nich taki algorytm i są ludzie oraz firmy, które po prostu nad tym pracują. Inna sprawa, że jest to po prostu wyabstrahowana część problemu i algorytmu, która sama w sobie może się wydawać nieinteresująca. Jednocześnie nie chcę publikować algorytmu ot tak w internecie, dopóki nie ocenię jego potencjału i nie podejmę decyzji, co z nim zrobić.
> > 
> > > jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno tlum chetnych
> > 
> > Współpracowałem już z programistami w różnych, prywatnych celach. Raz zleciłem napisanie programu związanego z rozwiązaniem pewnej hipotezy pobocznej związanej z hipotezą Collatza, innym razem pracowałem z pewnym programistą nad strategiami i algorytmami do gry na giełdzie. 200 zł to nie jest dla mnie problem i pewnie prędzej, czy później podejmę z kimś doraźną współpracę, żeby zrobić kompleksowe testy, w tym testy Dieharda, nie tylko pod kątem prędkości działania algorytmu. Tym bardziej, że chciałbym skomercjalizować temat, jeśli dobrze mi się wydaje, że jest coś wart. Ale, żeby udać się np. do jakiegoś funduszu zalążkowego, centrum transferu technologii, na uczelnię, czy skontaktować się z jakąś spółką technologiczną typu IBM, trzeba wiedzieć choć trochę na czym się stoi (stąd współpraca odpłatna i wstępne napisane kodu oraz testy są nieuniknione, wiem o tym). Zanim to jednak zrobię chciałem się choć wstępnie zorientować na co się nastawiać.

do tego oczywiscie powiedzialbym cos wiecej gdybym sie tym ineteresowal ale nei znam sie na szyfrowaniu i nei interesuje sie tym..umiem z grubsza iszaciowac ile cos moze zajac na cpu ale
to tez wymaga ode mnei wiedzy o co dokladie chodzi - a poztym podejrzewam ze cale to pytanie jest niewiele warte

kolega powinien zrozumeic ze jak to dobrze napisac to zajmie to tyle samo jak innym ludziom ktorzy to dobrze napisali 

oczywiscie jak nad czyms popracowac i czlowiek jest dobry to mzoe wymyslec jakis inny algorytm ale to wymaga sporo roboty i raczej ta optymalizacja bedzie wlasnie na poziomie matematyki czy budowania jakichs ciekawych konstrukcji w kodzie a nie na poziomie asemblera

[toc] | [prev] | [next] | [standalone]

#33569

> 10 GB/s ? moze oni licza to dla jakichs 32 rdzeniowych procesorow wtedy moze - nie wiem jak wydajne sa te instrukcje aes-ni ale 10 GB/s to raczej dla wielu procesorow na raz a i tak to wychodziloby kilka/kilkanascie cykli na zaszyfrowanie inta czyli bardzo malo.. mz idzie to wytlumaczyc tylko tym ze to sa dane dla wielu rdzeni 

Nie wiem dokładnie jak działa AES. Tutaj jest popularno-naukowe wyjaśnienie:

https://www.youtube.com/watch?v=O4xNJsjtN6E

nie wiem jednak, czy może być coś warte na poziomie szczegółowości, którego potrzebujemy. Przeglądałem jakiś czas temu dokumentację AES'a zamieszczoną przez NSA, ale tylko ją przejrzałem, nie mogę powiedzieć, że wiem dokładnie jak działa ten algorytm.

Natomiast dobrze udokumentowanym algorytmem jest w wielu aspektach podobny do niego DES. Łatwo znaleźć informacje co robi DES - to są mniej więcej tego rodzaju przekształcenia. Nie mam natomiast kompletnie pojęcia, czy mogą być one realizowane aż tak szybko. Nie umiem też stwierdzić na podstawie notek wikipedii co za procesory tam były używane. Jak pisze wikipedia:

"W przypadku mikroprocesorów klasy Pentium Pro, szyfrowanie za pomocą AES'a wymaga 18 cykli zegara na każdy bajt, co jest równoznaczne z wydajnością rzędu 11 MB/s dla procesora 200 MHz. Z kolei na procesorze klasy Pentium M o szybkości 1.7 GHz wydajność wynosi ok. 60 MB/s.

Na procesorach Intel Core i3/i5/i7, AMD APU a także na procesorach AMD FX wspierających zestaw instrukcji AES, wydajność może przekroczyć 700 MB/s na każdy wątek."

Procesor klasy pentium M o szybkości 1,7 GHz, to po prostu procesor 1,7 GHz, ma chyba jeden rdzeń. Nie wiem, nie znam się na procesorach, wiem tyle, co przeczytałem o tym procesorze na wikipedii.

> > 1000000/166*128/20*1/2^20= 0.037 MB/s
> > 
> 
> 
> kolega jest chyab niezle pijany...
> pisalem wyzej ze jedna taka iteracja na incie (4 bajty) moze zjac gdzies w granicach 10 ns (powiedzmy, plus minus, byc moze jest to zbytni pesymizm moze zajelo by tylko 3 ns) sto zajmie wiec w okolicach 1 mikrosekundy, na sekunde wiec wyjdzie to 1M intow czyli 4 MB (na rdzen)

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.

> (byc moze jest to zbyt pesymistyczne ale chodzilo mi o zarysowanie rzedu wielkosci, jesli wziac optymistycznie ze to bedzie ze 3 razy szybsze i masz 32 rdzenie to wyjdzie 12*32 = 384 MB/s, a jesli sa te specjalne instrukcje przyspieszajace to kilka razy to moze byc kilka razy wiecej ale i tak z tym 10 GBs tu wydaje sie przesada, chyab ze to na GPU)

No tak, przy 32 rdzeniach wygląda to świetnie. Ale te dane dla AES'a na procesorze klasy Pentium M o szybkości 1.7 GHz chyba nie dotyczą 32 rdzeni, tylko jednego?

> ciezko sie z kolega rozmawia bo kolega ma kalasyczny syndropm nooba czyli wyglaszanie jako pewniki zbioru zalozen ktore kolega uwaza za wazne a ktore widac ze sa mozna watpliwe lub ewidentnie falszywe

Chodzi Ci o te szacunki dot. AES'a? Tutaj:

https://crypto.stackexchange.com/questions/52958/is-there-an-encryption-algorithm-which-is-a-magnitude-faster-than-aes-with-wea

ktoś pisze, że:

"A classical table-based AES implementation would achieve about 160 MB/s on my current computer (a fairly recent MacBook Pro)"

Czyli jeszcze więcej. Może czegoś z tego nie rozumiem. Ile rdzeni ma ten MacBook Pro? Chyba 6-8? Raczej nie 32.

[toc] | [prev] | [next] | [standalone]

#33570

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 :).

[toc] | [prev] | [next] | [standalone]

#33575

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pl.comp.programming

csiph-web