🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.programming
6 messages
6 total messages Started by osobli... Wed, 26 May 2021 15:54
Jak liczyć cykle na bajt?
#217468
Author: osobli...
Date: Wed, 26 May 2021 15:54
3 lines
1737 bytes
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?
Re: Jak liczyć cykle na bajt?
#217469
Author: Mateusz Viste
Date: Wed, 26 May 2021 16:09
11 lines
1306 bytes
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
Re: Jak liczyć cykle na bajt?
#217470
Author: osobli...
Date: Wed, 26 May 2021 16:11
1 lines
1153 bytes
Ok, dzięki.
Re: Jak liczyć cykle na bajt?
#217471
Author: Maciej Sobczak
Date: Wed, 26 May 2021 20:09
18 lines
2532 bytes
> 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
Re: Jak liczyć cykle na bajt?
#217472
Author: slawek
Date: Sat, 05 Jun 2021 10:19
26 lines
2004 bytes
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/
Re: Jak liczyć cykle na bajt?
#217473
Author: Wojciech Muła
Date: Tue, 15 Jun 2021 05:46
40 lines
3311 bytes
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.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads