🚀 go-pugleaf

W dniu piątek, 13 grudnia 2019 06:42:35 UTC+1 użytkownik osobliwy nick napisał:
> > 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.

tlumaczyl;em  ci jak to sie szacuje byc zrozumial i nie bil piany na grupie, znasz chyba jakies elementarne podstawy asemblera?

takie cos 

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

w asemblerze bedzie wygladalo z grubsza jako

loop:
 mov eax, x
 jp l2
 shr eax, 1
 mov x, eax
 jmp loop
l2:
 mov eax, a  
 shr eax, 1   ; eax =  a/2
 mul eax, x   ; eax = a/2*x
 mov ebx, b
 shr ebx, 1
 add eax, ebx ; eax = a/2*x + b/2
 mov x, eac
jmp loop

choc w praktyce to zapisywanie do x'a byloby pominiete

ile to zajmie liczy sie tak ze mozesz z grubsza zalocyc ze jedno mov zajmuje okolo 1 cykla , shr okolo 2 cykl, mul okolo 2 cykle , skoki okolo 2 cykle (kiedys to bylo wiecej, zalezy od procka) 

ile zajmuje kazda komenda dla konkretnego procesora mozesz sprawdzic tutaj

https://www.agner.org/optimize/instruction_tables.pdf

patrz na kolumny latency i troughput, 
troughput to jest wydajnosc gdy poszzegolne komendy nie blokuja sie za bardzo tj gdy np kolejna nie musi czekac na wynik poprzednie, latency to jest ta
bardziej pesymistyczna wartosc gdy komendy od siebie zaleza

ja patrzylem dla skylake czyli okolo strony 240 

zrozum podstawy i przestaniesz bic piane,
pytanie jest zasadniczo ok ale jako ze malo znasz si ena tym temacie to gdy piszesz rozne eleboraty to jakby siejesz niekompetencje i to jest troche denerwujace

ile to konkretnie trwa najlepiej nalezy sprawdzi samemu, trzeba to wtedy napsiac w c lub w asmie i samemu odpalic, komputer umozliwia r obienie doklednych testow i nei ma z tym problemu... jak masz kilka stowek czy tysiaka do wydania to moge ci potestowac za kase co tam chcesz i udzilic ci tez konsultacji ale nie pale sie do tego bo jestem zmeczony leniwy i nie mam wprawy w zalatwianiu formalnosci  - z drugiej strony robic tego za darmo mi sie nie chce bo mam ciekawsze rzezy do roboty. pzdr