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

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

Jak liczyć cykle na bajt?

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

Contents

  Jak liczyć cykle na bajt? "osobli...@gmail.com" <osobliwy.nick@gmail.com> - 2021-05-26 08:54 -0700
    Re: Jak liczyć cykle na bajt? Mateusz Viste <mateusz@xyz.invalid> - 2021-05-26 18:09 +0200
      Re: Jak liczyć cykle na bajt? "osobli...@gmail.com" <osobliwy.nick@gmail.com> - 2021-05-26 09:11 -0700
      Re: Jak liczyć cykle na bajt? Maciej Sobczak <see.my.homepage@gmail.com> - 2021-05-26 13:09 -0700
      Re: Jak liczyć cykle na bajt? slawek <x.y@org.org> - 2021-06-05 12:19 +0200
        Re: Jak liczyć cykle na bajt? Wojciech Muła <wojtek.mula@gmail.com> - 2021-06-14 22:46 -0700

#34485 — Jak liczyć cykle na bajt?

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?

[toc] | [next] | [standalone]

#34486

2021-05-26 o 08:54 -0700, osobli...@gmail.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

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

#34487

Ok, dzięki.

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

#34488

> 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

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

#34490

Mateusz Viste <mateusz@xyz.invalid> Wrote in message:
> 2021-05-26 o 08:54 -0700, osobli...@gmail.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?


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)
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"

W praktyce zdarzyło mi się mieć program zużywający mniej niż pół
 cyklu zegara na przetworzenie bajtu, tj 1KB w czasie 500 cykli i
 to na jednym rdzeniu.

Jak do tego dodać wielordzeniowość i hyperthreading...


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

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

#34492

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.

[toc] | [prev] | [standalone]

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

csiph-web