Parametry procesorów - teoretyczna wydajność procesora

0

Gdzie można znaleźć (w miarę wiarygodne) informacje na temat parametrów różnych modeli procesorów Intela? Szczególnie zależy mi na wskaźniku IPC, którego nie sposób znaleźć nawet na stronie producenta, chyba, że do reszty oślepłem: Xeon E3, i7 Skylake - ze zgadywanek dla obu (AVX2 ->256b rejestry wektorowe -> 4 x double) wychodzi mi IPC ~ 4 dla arytmetyki podwójnej precyzji, co niezbyt trzyma się kupy, bo dostaję z tego teoretyczną wydajność ~57GFlops, choć z tego, co kojarzę powinno być ok. 230GFlops.

Wynik z benchmarków niestety niezbyt mnie urządza, potrzebuję wydajności teoretycznej właśnie ;)

Znalazłem artykuł na WikiChip aczkolwiek nie wiem, na ile to źródło jest wiarygodne. Dla architektury Skylake wychodziłoby, że mam ponownie AVX2, czyli 256bit rejestry wektorowe, czyli 4 liczby DP w jednym rejestrze, do tego procesor superskalarny z 2 wektorowymi FPU pod spodem, co dawałoby 2 uops / takt po 4 liczby DP -> IPC = 8 i teoretycznie ok. 20,8GFlops/rdzeń przy 2.6GHz... Obstawiam, że nawet 2-3 generacje wyżej procesor konsumencki, w dodatku mobile może wyciągać z bólem 40% wydajności procesora serwerowego na 1 rdzeniu, mylę się?

Jest na sali ktoś, kto siedzi na codzień blisko sprzętu i mógłby podpowiedzieć, czy kombinuję we właściwym kierunku? :)

1
superdurszlak napisał(a):

Obstawiam, że nawet 2-3 generacje wyżej procesor konsumencki, w dodatku mobile może wyciągać z bólem 40% wydajności procesora serwerowego na 1 rdzeniu, mylę się?

Powołując się na informacje wygooglane na szybko:
https://en.wikipedia.org/wiki/Instructions_per_cycle
, wskaźnik IPC to wskaźnik wynikający z praktyki, z wykonania kodu.
**Teoretyczną **wydajność oblicza się następująco:

To get a theoretical GFLOPS (Billions of FLOPS) rating for a given CPU, multiply the number in this chart by the number of cores and then by the stock clock (in GHz) of a particular CPU model. For example, a Coffee Lake i7-8700K theoretically handles 32 Single-Precision floats per cycle, has 6 cores and a 3.7 GHz base clock. This gives it 32 x 6 x 3.7 = 710.4 GFLOPS.

Odnośnie założenia o 40% wydajności, czy masz na myśli wydajność teoretyczną, czy praktyczną?
Chciałbym zauważyć, że procesor desktop, mobile, server jest prawie zawsze rżnięty z jednego i tego samego kawałka krzemu, a dopiero proces koszykowania (binning) powoduje, że procki z lepszymi wskaźnikami typu iloraz realne TDP do taktowania, max stabilne taktowanie, powodują zakwalifikowanie danego kawałka krzemu do danego koszyka.
Różnicy w wydajności teoretycznej nie powinno być więc wcale dla tego samego taktowania, różnica w wydajności praktycznej może być ogromna, ze względu np. na rozmiar cache L3, który w procesorach serwerowych może być ogromnych rozmiarów. To czy procek śpi czekając na dane przez 20% czy 80% obliczeń ma kolosalny wpływ na realną wydajność, tj. na IPC (wydajność praktyczną).

0
Tig napisał(a):

Powołując się na informacje wygooglane na szybko:
https://en.wikipedia.org/wiki/Instructions_per_cycle

Dzięki, jak szukałem haseł w stylu "Intel Skylake IPC" Google złośliwie ukrył przede mną Wikipedię. Poważnie.

Ale ok, mea culpa, użyłem sformułowania IPC na określenie wskaźnika teoretycznego, a nie praktycznego.

, wskaźnik IPC to wskaźnik wynikający z praktyki, z wykonania kodu.
**Teoretyczną **wydajność oblicza się następująco:

To get a theoretical GFLOPS (Billions of FLOPS) rating for a given CPU, multiply the number in this chart by the number of cores and then by the stock clock (in GHz) of a particular CPU model. For example, a Coffee Lake i7-8700K theoretically handles 32 Single-Precision floats per cycle, has 6 cores and a 3.7 GHz base clock. This gives it 32 x 6 x 3.7 = 710.4 GFLOPS.

I wszystko kręci się wokół tego, ile instrukcji zmiennoprzecinkowych procesor jest w stanie teoretycznie przemielić w jednym takcie. Problem mam ze znalezieniem wiarygodnego źródła tej informacji, nie z przemnożeniem trzech liczb. Nie kłamię.

Obstawiam, że odpowiedzią może być fpus_per_core * doubles_per_vector_register, ale nie mam całkowitej pewności i chciałbym się upewnić. Dla laptopowego Skylake i7 dawałoby to 2 FPU * 4 DP/rejestr, czyli teoretycznie 8 operacji zmiennoprzecinkowych podwójnej precyzji w cyklu, co z kolei daje ~20GFlops na jednym rdzeniu. Miałoby to sens, gdyby Xeon rzeczywiście miał większe rejestry wektorowe (a najprawdopodobniej nie ma) lub więcej potoków przetwarzania operacji wektorowych (czego nie wiem) - alternatywą jest błędna metodologia wyznaczania liczby operacji na cykl, dlatego chcę się upewnić. Oczywiście pomijam latencję, iloczyn skalarny raczej nie jest operacją zdolną rozwalić przetwarzanie potokowe.

Odnośnie założenia o 40% wydajności, czy masz na myśli wydajność teoretyczną, czy praktyczną?

Teoretyczną. Praktyczna z benchmarków i tak mnie w tym przypadku nie urządza.

Chciałbym zauważyć, że procesor desktop, mobile, server jest prawie zawsze rżnięty z jednego i tego samego kawałka krzemu, a dopiero proces koszykowania (binning) powoduje, że procki z lepszymi wskaźnikami typu iloraz realne TDP do taktowania, max stabilne taktowanie, powodują zakwalifikowanie danego kawałka krzemu do danego koszyka.

Wspaniale, tylko w tej chwili nie ma dla mnie znaczenia, czy różnice w poszczególnych modelach jednej serii wprowadzane są celowo, czy może jeden model to w rzeczywistości udane procesory z serii X, a drugi to wybrakowane procesory z serii X, w których nie działa pewien ficzer. Dla mnie istotna jest finalna specyfikacja danego modelu.

Różnicy w wydajności teoretycznej nie powinno być więc wcale dla tego samego taktowania

Pod warunkiem, że dane dwa modele faktycznie wywodzą się z jednej architektury, jednej serii i miałyby tyle samo potoków, tej samej szerokości rejestry wektorowe itp. itd. Choć i tak nie ma gwarancji, bo skoro czasem coś się rypnie i procesor ma 2 sprawne rdzenie zamiast 4 albo musi pracować na obniżonej częstotliwości, to równie dobrze może mieć 2 sprawne potoki przetwarzania zamiast 4 itd.

różnica w wydajności praktycznej może być ogromna, ze względu np. na rozmiar cache L3, który w procesorach serwerowych może być ogromnych rozmiarów. To czy procek śpi czekając na dane przez 20% czy 80% obliczeń ma kolosalny wpływ na realną wydajność, tj. na IPC (wydajność praktyczną).

Od paru miesięcy wałkuję optymalizowanie dostępu do pamięci, żeby podbić wydajność praktyczną tego i tamtego. Wprawdzie nie komercyjnie, ale i tak możemy dość odważnie założyć, że kwestia wpływu rozmiaru cache, wielodrożności, mechanizmów zwalniania cache, prefetchingu, miss rate w L1/LL cache i całej reszty zagadnień przynajmniej raz musiała obić mi się o uszy, a w dodatku nie jest odpowiedzią na mój problem.

Problem mam ze znalezieniem wiarygodnego źródła parametrów procesora ciut bardziej... szczegółowych niż te, o których każdy huczy w celach marketingowych. Potrzebuję ich po to, by wiedzieć, ile operacji zmiennoprzecinkowych procesor teoretycznie jest w stanie rozpocząć w jednym takcie, tak, by móc z tego wyznaczyć teoretyczną wydajność tego czy siamtego procesora. Czemu akurat tak - bo muszę do czegoś odnieść uzyskiwaną wydajność praktyczną. Czemu nie mogę do benchmarku - raz, bo nie ja decyduję, dwa, że i tak nie miałbym jak zrobić porządnego przy tym, co mam i w sensownym czasie.

1

Wydajność, którą obliczali przy mnie inżynierowie Intela na konfie w locie liczona była mniej więcej tak:
https://saiclearning.wordpress.com/2014/04/08/how-to-calculate-peak-theoretical-performance-of-a-cpu-based-hpc-system/

Nie wiem czy komuś chce się zagłębiać w bardziej dokładne obliczenia.
Praktycznie i tak dużo zależy od konkretnego sprzętu (wielkość cache na rdzeń, wydajność magistrali, rodzaj RAM, FMA).
Jak chcesz kupić coś mocniejszego to raczej celuj w AVX-512.

Jeśli chcesz kupić Xeona do domu to pamiętaj, że one są słabsze niż i7/i9 w zadaniach jedno- i niewielo-rdzeniowych (np. gry).

0
vpiotr napisał(a):

Wydajność, którą obliczali przy mnie inżynierowie Intela na konfie w locie liczona była mniej więcej tak:
https://saiclearning.wordpress.com/2014/04/08/how-to-calculate-peak-theoretical-performance-of-a-cpu-based-hpc-system/

Ten wzór to w zasadzie to samo co było już podawane, a @superdurszlak ma (jak rozumiem z wyjaśnień) problem ze znalezieniem wyczerpującej, wiarygodnej dokumentacji odnośnie tego, ile dokładnie tych instrukcji na cykl jest w dowolnie wybranym modelu procesora (w linku ww. będzie to składnik wzoru pt. instruction per cycle).

Praktycznie i tak dużo zależy od

Tak jak @superdurszlak pisał, nie interesuje go praktyczna wydajność, a teoretyczna.

Wracając do tematu, proponuję aby @superdurszlak poszukał informacji na forum anglojęzycznym ze względu na światowy zasięg (może Intel albo jakaś strona poważna o sprzęcie). Myślę, że wtedy warto zastanowić się nad sformułowaniem pytania, bo opis oryginalny jest mało precyzyjny, nieco chaotyczny.

0
Tig napisał(a):

Wracając do tematu, proponuję aby @superdurszlak poszukał informacji na forum anglojęzycznym ze względu na światowy zasięg (może Intel albo jakaś strona poważna o sprzęcie). Myślę, że wtedy warto zastanowić się nad sformułowaniem pytania, bo opis oryginalny jest mało precyzyjny, nieco chaotyczny.

Od poszukiwań w źródłach anglojęzycznych zacząłem, jednak tej informacji nie znalazłem nawet w dokumentacji sprzętu u producenta. A przejrzałem zarówno specyfikację, jak i datasheets dla 6tej generacji. Jedyne, co na ten temat mam z anglojęzycznych źródeł, to wpis na WikiChip, którą linkowałem w pytaniu. Na Tom's Hardware też są raczej opisy benchmarków i ew. definicja IPC bez danych. Pomyślałem, że może ktoś z 4p się w takich rzeczach babra i wie, skąd wyciągnąć te informacje.

Anyway, problem z dokopaniem się do tej informacji występuje nie od dziś i być może nikt mi głowy nie urwie, jeśli przy tej ilości niewiadomych nie wywróżę poprawnie z tego, co mam.

0
superdurszlak napisał(a):

Gdzie można znaleźć (w miarę wiarygodne) informacje na temat parametrów różnych modeli procesorów Intela? Szczególnie zależy mi na wskaźniku IPC, którego nie sposób znaleźć nawet na stronie producenta, chyba, że do reszty oślepłem: Xeon E3, i7 Skylake - ze zgadywanek dla obu (AVX2 ->256b rejestry wektorowe -> 4 x double) wychodzi mi IPC ~ 4 dla arytmetyki podwójnej precyzji, co niezbyt trzyma się kupy, bo dostaję z tego teoretyczną wydajność ~57GFlops, choć z tego, co kojarzę powinno być ok. 230GFlops.

Fantastyka.

Nawet 10GFlops nie wyciągnie żaden pecet.

co łatwo uzasadnić: przepustowość ramu to jakieś 16GB/s w porywach, co daje raptem 4GFlops, bo float ma 4 bajty.

i żadna kosmiczna liczba rejestrów, ani rdzeni, nic tu nie pomoże, niestety.

1
Smutny Kret napisał(a):

Fantastyka.

Nawet 10GFlops nie wyciągnie żaden pecet.

Odpal LINPACK / LAPACK, to się zdziwisz :)

co łatwo uzasadnić: przepustowość ramu to jakieś 16GB/s w porywach, co daje raptem 4GFlops, bo float ma 4 bajty.

i żadna kosmiczna liczba rejestrów, ani rdzeni, nic tu nie pomoże, niestety.

Po pierwsze, pamięć wielokanałowa może wyciągnąć znacznie więcej. 16GB/s to chyba na jeden kanał.

Po drugie, dużo zależy od tego, ile danych i które dane zmieścisz w cache procesora. To samo dotyczy rejestrów.

Po trzecie, równie dużo zależy od tego, ile operacji będziesz w stanie wykonać za jednym zamachem, pobierając/zapisując daną tylko raz w RAM.

Po czwarte, każdy rdzeń ma swoją pamięć cache, więc wykorzystując 4 rdzenie i odpowiednio dzieląc zadanie możesz wykorzystać 4x więcej L1 cache, która jest najszybsza (i najmniejsza), niż z jednym rdzeniem.

0

Te hipotetyczne osiągi wyliczasz tak:

4 GHz x 8 floatów (na rejestr 256bits) x 4 (cztery operacje są robione naraz) i x 8 rdzeni =
4 x 8 x 4 x 8 = 32 x 32 = 1024GFlops

0

To chyba nie do konca to o co pytasz, ale fajna stronka do szybkiego porownania konkretnych CPU: https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700K-vs-Intel-Core2-Quad-Q6600/3502vs1980

0
Smutny Kret napisał(a):

Fantastyka.

Nawet 10GFlops nie wyciągnie żaden pecet.

co łatwo uzasadnić: przepustowość ramu to jakieś 16GB/s w porywach, co daje raptem 4GFlops, bo float ma 4 bajty.

i żadna kosmiczna liczba rejestrów, ani rdzeni, nic tu nie pomoże, niestety.

Gdyby przepustowość ALU czy FPU miała być zawsze ograniczana przepustowością RAMu to nie tylko dla CPU wskaźniki by spadły. Dla przykładu Nvidia Quadro GV100 ma przepustowość RAM 868.4 GB/s a podaną przez producenta wydajność w liczbach pojedynczej precyzji 16671 GFLOPS (przy włączonym turbo). Według twoich równań FLOPSów powinno być 868.4 / 4 (ilość bajtów w SP float) = 217 GFLOPS czyli wynik prawie 80x mniejszy niż podawany przez producenta.

Algorytmy wektorowe projektuje się tak, by miały wysoki wskaźnik FLOP/byte (inaczej - miały wysoką Arithmetic Intensity), obojętnie czy na CPU, GPU, DSP, FPGA, itd byte tutaj oznacza bajt przesłany z lub do głównego RAMu. Cache procesora (znowu - obojętne czy CPU, GPU, czy czegoś innego) jest zawsze wielokrotnie szybsze niż główny RAM (inaczej miałoby niewiele sensu, no może oprócz niedużego obniżenia poboru prądu).

Inną sprawą jest to, że CPU wcale nie ładuje pamięci w 4 bajtowych kawałkach. Minimum to jedna linia pamięci podręcznej (cache line) co dzisiaj typowo wynosi 64 bajty. Ponadto każde oczekiwanie na RAM to wiele straconych taktów, a nawet spekulatywne wykonywanie nie sprawi, że losowy dostęp do pamięci osiągnie maksymalną wydajność - ograniczeniem tutaj jest limit na ilość jednoczesnych odwołań do pamięci. Stąd maksymalną przepustowość uzyskuje się głównie, gdy zdecydowana większość dostępu do pamięci jest liniowa (tzn wczytujemy lub zapisujemy strumieniowo w miarę duże bloki pamięci). Utrzymywanie maksymalnie liniowego dostępu do głównego RAMu jest więc równie ważne co redukowanie dostępu do tego RAMu w ogóle (poprzez zwiększanie hit ratio dla cache procesora).

0

Maksymalną wydajność uzyskujemy pracując bez dostępu do pamięci (tylko na rejestrach), ale to raczej w gołym ASM i w szczególnych przypadkach.

2

Wracając do teoretycznej maksymalnej mocy obliczeniowej - prawdopodobnie wystarczy wziąć instrukcję procesora, która wykonuje najwięcej operacji w jednym takcie i to będzie maksymalna wartość FLOP/cycle (tak to mniej więcej działa na prockach Intela, bo są zwykle tylko dwa silne potoki w rdzeniu, czyli tylko dwa potoki mogą generować dużą ilość FLOPów, a reszta czeka na inne rodzaje instrukcji).. Na stronie http://instlatx64.atw.hu/ mamy listingi instrukcji procesorów wraz z opóźnieniami i przepustowościami. Nas interesują przepustowości, czyli maksimum wydajności przy ciągu tych samych instrukcji.

Dla SkylakeX wyniki są np tu: http://users.atw.hu/instlatx64/GenuineIntel0050654_SkylakeX_InstLatX64.txt
Weźmy np instrukcję:
2433 AVX512F :VFMADD132PS zmm, zmm, zmm L: 1.21ns= 4.0c T: 0.15ns= 0.50c
FMA = Multiply and Add
T = 0.50c oznacza iż średnio możemy wykonać dwie takie instrukcje w ciągu jednego taktu. FMA to dwie operacje (możenie i dodawanie). W rejestrze 512 bitowym możemy mieć 16 floatów pojedynczej przecyzji. Sumarycznie mamy: 2 (instrukcje na takt) * 2 (operacje w instrukcji) * 16 (elementów w wektorze) = 64 FLOP/takt.

Mogłem się walnąć podczas obliczeń :] (polecam podejść do tego posta z pewną rezerwą)

Natomiast wskaźnik IPC (instructions per cycle) jest zależny nie tylko od procesora, ale też od oprogramowania. Nie ma stałego IPC, gdyż różne instrukcje zajmują różną ilość czasu, a zarazem różne programy mają inne rozkłady wykorzystania poszczególnych instrukcji. Stąd np w jednych benchmarkach słabe procesory dorównują mocnym procesorom (bo te benchmarki akurat wykorzystują głównie instrukcje, które dobrze działają także w tych słabych procesorach), a w innych jest przepaść mimo iż w żadnym benchmarku nie ma np oczekiwania na dysk, sieć czy cokolwiek poza CPU i RAMem.

0

Szczegóły nowych Ryzenów.
https ://www .purepc.pl/procesory/amd_ryzen_9_3800x_znamy_szczegoly_chipu_i_nowej_serii_ryzen

0
Wibowit napisał(a):
Smutny Kret napisał(a):

Fantastyka.

Nawet 10GFlops nie wyciągnie żaden pecet.

co łatwo uzasadnić: przepustowość ramu to jakieś 16GB/s w porywach, co daje raptem 4GFlops, bo float ma 4 bajty.

i żadna kosmiczna liczba rejestrów, ani rdzeni, nic tu nie pomoże, niestety.

Gdyby przepustowość ALU czy FPU miała być zawsze ograniczana przepustowością RAMu to nie tylko dla CPU wskaźniki by spadły. Dla przykładu Nvidia Quadro GV100 ma przepustowość RAM 868.4 GB/s a podaną przez producenta wydajność w liczbach pojedynczej precyzji 16671 GFLOPS (przy włączonym turbo). Według twoich równań FLOPSów powinno być 868.4 / 4 (ilość bajtów w SP float) = 217 GFLOPS czyli wynik prawie 80x mniejszy niż podawany przez producenta.

Algorytmy wektorowe projektuje się tak, by miały wysoki wskaźnik FLOP/byte (inaczej - miały wysoką Arithmetic Intensity), obojętnie czy na CPU, GPU, DSP, FPGA, itd byte tutaj oznacza bajt przesłany z lub do głównego RAMu. Cache procesora (znowu - obojętne czy CPU, GPU, czy czegoś innego) jest zawsze wielokrotnie szybsze niż główny RAM (inaczej miałoby niewiele sensu, no może oprócz niedużego obniżenia poboru prądu).

Inną sprawą jest to, że CPU wcale nie ładuje pamięci w 4 bajtowych kawałkach. Minimum to jedna linia pamięci podręcznej (cache line) co dzisiaj typowo wynosi 64 bajty. Ponadto każde oczekiwanie na RAM to wiele straconych taktów, a nawet spekulatywne wykonywanie nie sprawi, że losowy dostęp do pamięci osiągnie maksymalną wydajność - ograniczeniem tutaj jest limit na ilość jednoczesnych odwołań do pamięci. Stąd maksymalną przepustowość uzyskuje się głównie, gdy zdecydowana większość dostępu do pamięci jest liniowa (tzn wczytujemy lub zapisujemy strumieniowo w miarę duże bloki pamięci). Utrzymywanie maksymalnie liniowego dostępu do głównego RAMu jest więc równie ważne co redukowanie dostępu do tego RAMu w ogóle (poprzez zwiększanie hit ratio dla cache procesora).

Dla grafiki - GPU inaczej to obliczasz: GHz * ROPs * TMUs * 2;

co np. dla karty klasy GTX 750 i dla 1GHz daje: 1 x 16 x 32 x 2 = 1024GFlops

Ten numer: rops x tmus = 16 x 32 = 512, jest tu zwykle nazywany błędnie jako liczba rdzeni, co jest błędne, bo to są tylko takie strasznie długie rejestry - analogiczne do tych z SSE, a nie żadne rdzenie.

a ten czynnik: 2 bierze się stąd, że tam zapis wyniku do pamięci (karty) jest łączony z operacją arytmetyczną - w jednym takcie.

1

Dlaczego w przypadku CPU przepustowość RAM miałaby mieć znaczenie, a w przypadku GPU już nie?

Poza tym: ROP * TMU ? Po co mnożyć losowe wartości, które w ogóle nie mają nic wspólnego z wykonywaniem shaderów obliczeniowych? ROP i TMU leżą kompletnie odłogiem jeśli nie renderujesz obrazu i nie korzystasz z tekstur, więc dlaczego miałyby mieć jakikolwiek wpływ na moc obliczeniową?

0
Wibowit napisał(a):

Dlaczego w przypadku CPU przepustowość RAM miałaby mieć znaczenie, a w przypadku GPU już nie?

W kartach graficznych ram ma szybkość dopasowaną do szybkości obliczeń;
gdyby było inaczej, wówczas używanie tego urządzenia nie miałoby zbyt dużego sensu:
zwykły CPU mógłby wtedy to obliczać z podobną wydajnością, czyli na poziomie tych kilku GFlopsów zaledwie.

Poza tym: ROP * TMU ? Po co mnożyć losowe wartości, które w ogóle nie mają nic wspólnego z wykonywaniem shaderów obliczeniowych? ROP i TMU leżą kompletnie odłogiem jeśli nie renderujesz obrazu i nie korzystasz z tekstur, więc dlaczego miałyby mieć jakikolwiek wpływ na moc obliczeniową?

Te liczby: ROPs i TMUs są zależne od oprogramowania - konkretnie: od sterowników karty graficznej.
A fizycznie tam jest chyba tylko jakaś ogromna seria rejestrów (identycznych), np. 512 sztuk, które można grupować... jakoś tam, tworząc obliczeniowe struktury logiczne...
nie chce misie grzebać w dokumentacji, aby to precyzyjniej opisać, o ile w ogóle to opisują - być może to są już tajne sprawy producenta.

1

W kartach graficznych ram ma szybkość dopasowaną do szybkości obliczeń;
gdyby było inaczej, wówczas używanie tego urządzenia nie miałoby zbyt dużego sensu:
zwykły CPU mógłby wtedy to obliczać z podobną wydajnością, czyli na poziomie tych kilku GFlopsów zaledwie.

Pokaż mi jak przepustowość RAMu ogranicza CPU i GPU. Pokazałem, że przepustowość RAMu w GPU jest ok 80x mniejsza od podanej przez producenta wydajności zmiennoprzecinkowej.

Te liczby: ROPs i TMUs są zależne od oprogramowania - konkretnie: od sterowników karty graficznej.

Serio? To po co projektować nowe GPU, skoro można sterownikami zwiększać ich wydajność w nieskończoność?

0
Smutny Kret napisał(a):

W kartach graficznych ram ma szybkość dopasowaną do szybkości obliczeń;
gdyby było inaczej, wówczas używanie tego urządzenia nie miałoby zbyt dużego sensu:
zwykły CPU mógłby wtedy to obliczać z podobną wydajnością, czyli na poziomie tych kilku GFlopsów zaledwie.

Nope, nope, nope.

Współczesna karta graficzna ma pamięć DRAM szybszą od pamięci DRAM z którą komunikuje się CPU, ale to nadal nie wystarczy. Gdyby spróbować wykonać kartę graficzną tak, by pamięć główna nadążyła za rdzeniami karty, to nawet gdyby się udało, kosztowałaby krocie. Po to jest pamięć lokalna / wspólna (współdzielona przez grupę roboczą) - znacznie szybsza od DRAM GPU, ale o małej pojemności.

Na GPU arithmetic intensity liczy się nie mniej, niż w przypadku CPU - do tego dochodzi trudność polegająca na tym, że trzeba się starać w pełni wykorzystywać wavefront (32 wątki wykonywane w synchronizacji sprzętowej) czyli m.in. jak najmniej bloków warunkowych, a w dodatku uważać na konflikty w dostępie do banków pamięci. Plus killer w postaci komunikacji między hostem a GPU - czyli przesył z/do DRAM GPU po PCIe.

0
Wibowit napisał(a):

W kartach graficznych ram ma szybkość dopasowaną do szybkości obliczeń;
gdyby było inaczej, wówczas używanie tego urządzenia nie miałoby zbyt dużego sensu:
zwykły CPU mógłby wtedy to obliczać z podobną wydajnością, czyli na poziomie tych kilku GFlopsów zaledwie.

Pokaż mi jak przepustowość RAMu ogranicza CPU i GPU. Pokazałem, że przepustowość RAMu w GPU jest ok 80x mniejsza od podanej przez producenta wydajności zmiennoprzecinkowej.

Nie mówię, że szybkość ram ma być identyczna z flopsami, lecz dopasowana.

W przypadku grafiki wystarczy, że ram ma przepustowość ze 16 a może i 32 razy mniejszą od flopsów,
bo to na oko widać: ile obliczeń wymaga jeden piksel?

kolor+alfa = RGBA = 4 floaty
rzuty, transformacje itp. operacje - ile do tego potrzeba - z 16 floats?

dalsze sprawy: nakładanie tekstur, światła, i inne bajery...

wyjdzie tego właśnie z 30 danych (floatów) na piksel, zatem to ma być wyliczone w czasie 1 taktu, i zapisane finalnie do ram - też w 1 takcie!

I wtedy możesz mówić, że to zasuwa 16 - 30 x szybkość ram!

No i tak faktycznie jest!
GPU o mocy obliczeniowej 1000GFlops wymaga ram o szybkości (minimum!): 1000/16 = 64GB/s.

Te liczby: ROPs i TMUs są zależne od oprogramowania - konkretnie: od sterowników karty graficznej.

Serio? To po co projektować nowe GPU, skoro można sterownikami zwiększać ich wydajność w nieskończoność?

Fizycznie masz to limitowane, np. karta ma 1024 rejestrów, które stery dzielą sobie potem na matrycę: 32 x 32 albo 64 x 16, itp., razem pozostaje te 1024.

0
superdurszlak napisał(a):
Smutny Kret napisał(a):

W kartach graficznych ram ma szybkość dopasowaną do szybkości obliczeń;
gdyby było inaczej, wówczas używanie tego urządzenia nie miałoby zbyt dużego sensu:
zwykły CPU mógłby wtedy to obliczać z podobną wydajnością, czyli na poziomie tych kilku GFlopsów zaledwie.

Nope, nope, nope.

Współczesna karta graficzna ma pamięć DRAM szybszą od pamięci DRAM z którą komunikuje się CPU, ale to nadal nie wystarczy. Gdyby spróbować wykonać kartę graficzną tak, by pamięć główna nadążyła za rdzeniami karty, to nawet gdyby się udało, kosztowałaby krocie. Po to jest pamięć lokalna / wspólna (współdzielona przez grupę roboczą) - znacznie szybsza od DRAM GPU, ale o małej pojemności.

Na GPU arithmetic intensity liczy się nie mniej, niż w przypadku CPU - do tego dochodzi trudność polegająca na tym, że trzeba się starać w pełni wykorzystywać wavefront (32 wątki wykonywane w synchronizacji sprzętowej) czyli m.in. jak najmniej bloków warunkowych, a w dodatku uważać na konflikty w dostępie do banków pamięci. Plus killer w postaci komunikacji między hostem a GPU - czyli przesył z/do DRAM GPU po PCIe.

No i co to za rewelacje?

Na CPU zawsze gorzej wyjdzie, bo to nie jest dostosowane do przetwarzania obrazków,
gdzie jest zaledwie kilka prostych operacji, powtarzanych miliony razy dookoła.

CPU wykonuje dowolne algorytmy, i dlatego te teoretyczne GFlopsy są tu bezużytecznym parametrem.

A nawet podejrzewam, że gdyby napisać kod, który jedzie optymalnie - po cztery instrukcje w pętli, plus niewielka pula danych, itp. skecze,
to i tak nie uzyska tej teoretycznej szybkości, po zapuszczeniu na wszystkich rdzeniach, np. 8 sztuk.

Wtedy moc TDP całego procesora, przekroczyłaby zapewne fabryczny limit, więc byłoby to automatycznie zredukowane do tego limitu - jak?
Jasne że poprzez zmniejszenie częstotliwości pracy, bo inaczej procek spaliłby się i tyle.

1

Nie mówię, że szybkość ram ma być identyczna z flopsami, lecz dopasowana.
W przypadku grafiki wystarczy, że ram ma przepustowość ze 16 a może i 32 razy mniejszą od flopsów,
bo to na oko widać: ile obliczeń wymaga jeden piksel?

A dlaczego chcesz zawsze liczyć piksele i to według tego samego schematu? Przecież GPGPU jest używane do masy różnych zastosowań. Przykładowo - łamanie haszy. Łamanie lekkich haszy (czyli np SHA1 bez brycptów, scryptów, etc) nie wymaga prawie żadnej pamięci, więc są łamacze, które prawie w ogóle nie tykają VRAMu. Ładują dane do cache i mielą je tam cały czas.

I wtedy możesz mówić, że to zasuwa 16 - 30 x szybkość ram!
No i tak faktycznie jest!
GPU o mocy obliczeniowej 1000GFlops wymaga ram o szybkości (minimum!): 1000/16 = 64GB/s.

A więc nVidia też kłamie? Wcześniej pokazałem przykład jak podawana przez producenta wydajność w obliczeniach jest 80x większa niż ta wynikająca z przepustowości RAMu. 80x to dużo więcej niż 16x - 30x

Dla przykładu Nvidia Quadro GV100 ma przepustowość RAM 868.4 GB/s a podaną przez producenta wydajność w liczbach pojedynczej precyzji 16671 GFLOPS (przy włączonym turbo). Według twoich równań FLOPSów powinno być 868.4 / 4 (ilość bajtów w SP float) = 217 GFLOPS czyli wynik prawie 80x mniejszy niż podawany przez producenta.

.

Fizycznie masz to limitowane, np. karta ma 1024 rejestrów, które stery dzielą sobie potem na matrycę: 32 x 32 albo 64 x 16, itp., razem pozostaje te 1024.

Polecam w takim razie sprawdzić jakieś rozsądne artykuły opisujące architekturę GPU, np artykuł o architekturze GeForce GTX 1080: https://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review/4
Masz tam takie obrazki, pokazujące fizyczny podział GPU (w sensie opisujący fizyczną strukturę, a nie proporcje) na części składowe:
GeForce_GTX_1080_SM_Diagram_FINAL.png
GeForce_GTX_1080_Block_Diagram_FINAL.png

Sterownikami nie zmienisz fizycznego podziału GPU na jednostki przetwarzające dane. Za to z poziomu API możesz sterować ilością jednocześnie odpalonych wątków (work itemów). Jako że ID wątku może być używane do liczenia współrzędnych np piksela czy elementu tablicy to ID może być jedno-, dwu- lub trójwymiarowe (czyli po prostu składać się z jednego, dwóch lub trzech liczb). Limity w OpenCL dla GTX 1080 podane są tutaj: https://openbenchmarking.org/system/1606043-HA-QUICKTEST73/Device/clinfo

  Max work item dimensions                        3
  Max work item sizes                             1024x1024x64
  Max work group size                             1024
  Preferred work group size multiple              32

Przypominam, że są to limity na kolejne wymiary IDków wątków, a nie parametry kontrolujące fizyczny podział rdzenia (to byłby totalny absurd).

Co do TMU i ROP to totalnie strzeliłeś jak kulą w płot. TMU to texture mapping unit, czyli element GPU zajmujący się pobieraniem tekseli z tekstur. ROP natomiast to raster operations pipeline, która składa informacje z poprzednich faz do końcowych pikseli wysyłanych na ekran. Obie nie mają zupełnie związku z obliczeniami na GPU, które nie korzystają z tekstur ani nie renderują obrazów.

PS: wiem, że wątek w kontekście GPU i w kontekście CPU oznaczają zupełnie co innego. Nie sądzę, że trzeba się tym brandzlować. Wątek z CPU jest podobny do warpu (nVidia) czy wavefrontu (AMD) na GPU.

0
Smutny Kret napisał(a):

No i co to za rewelacje?

Na CPU zawsze gorzej wyjdzie, bo to nie jest dostosowane do przetwarzania obrazków,
gdzie jest zaledwie kilka prostych operacji, powtarzanych miliony razy dookoła.

Co ma wspólnego dostosowanie do przetwarzania obrazków z np. operacjami na macierzach? Chyba dorabiasz sobie poboczną fabułę do tego wątku i odpowiadasz na rzeczy, które moje czy @Wibowit alter ego wypowiedziało w Twojej fabule.

CPU wykonuje dowolne algorytmy, i dlatego te teoretyczne GFlopsy są tu bezużytecznym parametrem.

No tak, zapomniałem że OpenCL i C for CUDA tylko mi się przyśniły, a na GPU można pisać tylko shadery i liczyć kolory pikseli. Na architekturze fizycznie rekonfigurowanej sterownikami pisanymi przez różne smutne krety.

A nawet podejrzewam, że gdyby napisać kod, który jedzie optymalnie - po cztery instrukcje w pętli, plus niewielka pula danych, itp. skecze,
to i tak nie uzyska tej teoretycznej szybkości, po zapuszczeniu na wszystkich rdzeniach, np. 8 sztuk.

Czy używasz kompasu tylko po to, by iść koniecznie na północ i zdobywać biegun w japonkach, czy aby mieć punkt odniesienia?

0

Tam faktycznie wychodzi większa różnica, no bo 1GB/s to przecież 1/4 GFlopsa, z uwagi na 4 bytes per float.

16 instrukcji na piksel = 64 bajty, co daje poprawne wyniki:
1000GFlops == 4000GB/s
stąd masz: 4TB/64 = 64GB/s == 16GFlops/s.

Wspomniana karta: GTX 750 ma przepustowość ram 80GB/s,
no bo jest jest optymalne dla jej szybkości obliczeń: 1Tflops = 32Rops x 16Tums x 2 lub 512 rejestrów x 2.

Można sprawdzić inne GPUs i pewnie też będzie git: flops =~ ram /10, co znaczy faktycznie 4x10 = 40, z powodu na: 1float = 4bytes.

0

flops =~ ram /10, co znaczy faktycznie 4x10 = 40, z powodu na: 1float = 4bytes

Wszystko jasne. Można dzielić przez 10, można przez 40 albo i przez 150, byleby wyszło jak trzeba. Jesteś geniuszem.

32Rops x 16Tums

Zastanawia mnie to mnożenie. To tak jakby mnożyć ilość gaźników przez ilość cylindrów. Albo ilość siedzeń w samochodzie przez ilość biegów w skrzyni biegów. Przecież ilości ROPów jak i TMU są podawane sumarycznie na całe GPU, a nie w postaci ilość TMU/ ROP ani ROP/ TMU. Od wielu generacji GPU zresztą ilości ROP i TMU są od siebie niezależne. W jednym compute unit jest wiele TMU i ROPów. Na powyższych obrazkach to widać wprost - ani Tex nie jest zawarty w Raster Engine ani odwrotnie. Raster Engine jest poza SM (SM to compute unit), więc np SM możesz fizycznie wyłączać bez zmian w ilości Raster Engines (co oznacza iż stosunek Tex do Raster Engine jest definitywnie zmienny).

0
superdurszlak napisał(a):
Smutny Kret napisał(a):

No i co to za rewelacje?

Na CPU zawsze gorzej wyjdzie, bo to nie jest dostosowane do przetwarzania obrazków,
gdzie jest zaledwie kilka prostych operacji, powtarzanych miliony razy dookoła.

Co ma wspólnego dostosowanie do przetwarzania obrazków z np. operacjami na macierzach? Chyba dorabiasz sobie poboczną fabułę do tego wątku i odpowiadasz na rzeczy, które moje czy @Wibowit alter ego wypowiedziało w Twojej fabule.

CPU wykonuje dowolne algorytmy, i dlatego te teoretyczne GFlopsy są tu bezużytecznym parametrem.

No tak, zapomniałem że OpenCL i C for CUDA tylko mi się przyśniły, a na GPU można pisać tylko shadery i liczyć kolory pikseli. Na architekturze fizycznie rekonfigurowanej sterownikami pisanymi przez różne smutne krety.

A nawet podejrzewam, że gdyby napisać kod, który jedzie optymalnie - po cztery instrukcje w pętli, plus niewielka pula danych, itp. skecze,
to i tak nie uzyska tej teoretycznej szybkości, po zapuszczeniu na wszystkich rdzeniach, np. 8 sztuk.

Czy używasz kompasu to po to, by iść koniecznie na północ i zdobywać biegun w japonkach, czy aby mieć punkt odniesienia?

grafika to gównie macierze i wektory... niestety.

OpenCL i CUDA stosujesz do obróbki dużych ilości danych: symulacje fizyczne typu: multi/many-body problem - molecular physics, ... czyli w zasadzie same wektory i macierze./;

0

Znalazłem artykuł obrazujący zmiany w FLOP/ byte:
http://www.cudahandbook.com/2017/10/dont-move-the-data/

  | G80 | GP100 | GV100
---------------- | -------------------
GFLOPS (SP) | 384 | 10600 | 15000
GPU↔GPU memory | 84 GB/s | 720 GB/s | 900 GB/s
FLOP/Byte | 4.5 | 14.7 | 16.67

FLOP/Byte rośnie. Czy to oznacza iż nVidia coraz bardziej kłamie? A może oznacza, że kiedyś przepustowości było niepotrzebnie dużo? W takim razie czemu także w starych kartach była znacząca różnica w wydajności w grach (czyli przy obróbce pikseli) przy zmianie typu VRAMu (np szybki GDDR5 w droższych wariantach vs dużo wolniejszy DDR3 w tańszych, bądź 256-bitowa szyna RAMu w droższych wariantach vs 128-bitowa szyna w tańszych)?

0
Wibowit napisał(a):

flops =~ ram /10, co znaczy faktycznie 4x10 = 40, z powodu na: 1float = 4bytes

Wszystko jasne. Można dzielić przez 10, można przez 40 albo i przez 150, byleby wyszło jak trzeba. Jesteś geniuszem.

16 było takim moim minimum... teoretycznym,
a z przykładowej GTX 750 wychodzi: 100/80 = 12.5, co jest powyżej minimum, więc co chcesz?

Sprawdź inną kartę, a wtedy zobaczymy czy wyjdzie istotnie inaczej.

32Rops x 16Tums

Zastanawia mnie to mnożenie. To tak jakby mnożyć ilość gaźników przez ilość cylindrów. Albo ilość siedzeń w samochodzie przez ilość biegów w skrzyni biegów. Przecież ilości ROPów jak i TMU są podawane sumarycznie na całe GPU, a nie w postaci ilość TMU/ ROP ani ROP/ TMU. Od wielu generacji GPU zresztą ilości ROP i TMU są od siebie niezależne. W jednym compute unit jest wiele TMU i ROPów. Na powyższych obrazkach to widać wprost - ani Tex nie jest zawarty w Raster Engine ani odwrotnie. Raster Engine jest poza SM (SM to compute unit), więc np SM możesz fizycznie wyłączać bez zmian w ilości Raster Engines (co oznacza iż stosunek Tex do Raster Engine jest definitywnie zmienny).

Nie ma takich problemów.

Sam mam kartę, która podaje różne liczby tych rops i tmus po przeinstalowaniu sterowników.

1

Sprawdź inną kartę, a wtedy zobaczymy czy wyjdzie istotnie inaczej.

We wcześniejszym poście wrzuciłem tabelkę z przykładami.

Nie ma takich problemów.
Sam mam kartę, która podaje różne liczby tych rops i tmus po przeinstalowaniu sterowników.

Co to za karta i jakie liczby podają sterowniki?

Prawdopodobnie pomyliło ci się https://en.wikipedia.org/wiki/Product_binning z magicznym wpływem sterowników na fizyczną strukturę procesora. Jeśli np producent programowo (np mikrokodem/ firmware) zablokuje jeden rdzeń z 4-rdzeniowego procesora, a potem tobie uda się programowo odblokować ten rdzeń no to sorry - wszystko odbyło się programowo, a fizyczny podział procesora został nietknięty.

0
Wibowit napisał(a):

Nie ma takich problemów.
Sam mam kartę, która podaje różne liczby tych rops i tmus po przeinstalowaniu sterowników.

Co to za karta i jakie liczby podają sterowniki?

GTX 750;

obecnie podaje mi: 16 x 48, a na innych sterach jest inaczej.. chyba 24 x 32.

Prawdopodobnie pomyliło ci się https://en.wikipedia.org/wiki/Product_binning z magicznym wpływem sterowników na fizyczną strukturę procesora. Jeśli np producent programowo (np mikrokodem/ firmware) zablokuje jeden rdzeń z 4-rdzeniowego procesora, a potem tobie uda się programowo odblokować ten rdzeń no to sorry - wszystko odbyło się programowo, a fizyczny podział procesora został nietknięty.

Te ropy to nie są fizyczne parametry, lecz... takie tylko umowne - z tradycji;
był okres w rozwoju kart graficznych, gdy to było fizycznie zaklepane... z 10 lat temu?

1 użytkowników online, w tym zalogowanych: 0, gości: 1