Załóżmy, że pewien algorytm działa z prędkością 1 cykl na bajt. Chcę oszacować ile GB
przetworzy komputer z Core i7 8665U w ciągu sekundy.

Wiem, że ten procesor ma 4 rdzenie i to taktowane 2,1-4,8 GHz. Pomijając, że to duży
rozstrzał, to, czy mam zakładać, że będzie on pracował na 4 rdzeniach, każdy
taktowany np. po 2,1 GHz? Wtedy przetworzy 2,1*4 GB/s. Czy może do szacunków przyjąć
po prostu taktowanie 2,1 GHz i zakładać, że przetworzy on 2,1 GB/s?

do góry

2021-05-26 o 08:54 -0700, o...@g...com napisał:
> Wiem, że ten procesor ma 4 rdzenie i to taktowane 2,1-4,8 GHz.
> Pomijając, że to duży rozstrzał, to, czy mam zakładać, że będzie on
> pracował na 4 rdzeniach, każdy taktowany np. po 2,1 GHz?

To zależy od implementacji algorytmu. Jeśli ta jest w stanie utworzyć 4
wątki i pchać w nie dane bez przestojów na synchronizację czy semafory,
to tak. W przeciwnym wypadku nie - procesowi zostanie przydzielony
tylko jeden rdzeń.

Mateusz

do góry

> To zależy od implementacji algorytmu.

Tak. Jeżeli to jest algorytm typu "jeden cykl na ciągle ten sam bajt", to da radę.
Ale jeżeli to jest "jeden cykl na kolejny bajt z długiego ciągu bajtów", to mamy
wąskie gardło w transmisji między procesorem a pamięcią. Czy gdzie tam te dane są na
początku (na dysku pewnie? albo nie, jeszcze lepiej - "w chmurze"?).

> Jeśli ta jest w stanie utworzyć 4
> wątki i pchać w nie dane bez przestojów na synchronizację czy semafory,
> to tak.

Tak. Synchronizacja między wątkami to jedno z ograniczeń. Transfer między różnymi (i
coraz wolniejszymi) poziomami pamięci to drugie.

> W przeciwnym wypadku nie - procesowi zostanie przydzielony
> tylko jeden rdzeń.

Niekoniecznie. Proces może mieć wiele (n) wątków, którym przydzielono wiele (m)
rdzeni. W szczególności wszystkie dostępne rdzenie. Ale i tak nie będzie to miało
znaczenia, jeśli będą musiały (te wątki) na coś czekać i wtedy, aktywne będzie np.
średnio 3.5% rdzenia, w dodatku nie zawsze tego samego. Koncepcja "przydzielenia
tylko jednego rdzenia" jest tu zupełnie niepotrzebna.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Saturday, June 5, 2021 at 12:19:23 PM UTC+2, slawek wrote:
> Przy "dużych" CPU (takich jak Intel I9, w odróżnieniu od jakichś
> popierdułek w rodzaju 8 bitowego ATmega8) jest jeszcze
> ciekawiej:
>
> 1. Jest zegar, np. 3.5 GHz.
> 2. Ale w trybie boost leci do 5GHz - jeżeli jeden rdzeń tylko pracuje.
> 3. przetworzenie rozkazu może zająć kilka faktów (wczytanie
> rozkazu, wczytanie danych, zapisanie danych)

To jest szczegół techniczny, o którym należy zapomnieć. W rzeczywistości
potoki są głębokie (co najmniej kilkanaście etapów). Dekodowanie rozkazów,
ich scheduling na fizyczne jednostki wykonawcze i ich faktyczne
wykonywanie są asynchroniczne. Procesor Skylake może obsługiwać ponad
200 rozkazów w jednej chwili.

Z punktu widzenia programisty istotne są tylko dwie liczby charakteryzujące
instrukcje:
- opóźnienie (latency) - po ilu cyklach zegara wynik instrukcji będzie dostępny,
- przepustowość (throughput) - co ile cykli zegara można odpalać dany rozkaz.

Np. mnożenie ma latency=3, ale throughput=1, co znaczy, że jak masz wykonać
10 mnożeń, to ich wynik może być dostępny w najgorszym przypadku po 10*3
cyklach, a w najlepszym po 3 + 9*1 cyklach.

Albo latency=1, throughput=0.33 dla dodawania całkowitoliczbowego oznacza, że
wynik będzie po cyklu, ale jak scheduler da radę i będą wolne jednostki wykonawcze,
to trzy dodawania zostaną przekazane do wykonania w 1 cyklu.

> 4. Ale jest pipeline i na jednym core jest na raz kilka rozkazów
> (na różnych etapach realizacji)
> 5. Są rozkazy SIMD i rejestry o długości tak z 2KB - teoretycznie
> operacje na nich też są "w jednym cyklu"

Nie istnieją takie duże rejestry SIMD. Największe obecnie to 64 bajty
w AVX512 i niektórych implementacjach SVE; większość to 16 lub 32 bajty.
Latency dla dużej części operacji wektorowych wynosi jeden cykl,
bez cudzysłowu. Dlatego procesory się grzeją. :)

w.

do góry