Pierwsze zdjęcia struktury wewnętrznej rdzeni procesorów Ryzen 3000
Autor: Zbyszek | 05:34
(34)
W serwisie Flickr pojawiło się pierwsze zdjęcie przedstawiające szczegóły wewnętrznej struktury rdzeni procesora Ryzen trzeciej generacji (nazwa kodowa Matisse). Zdjęcie wykonane w podczerwieni (z odpowiednim filtrem) przedstawia procesor Ryzen 5 3600, ze zdjętą osłoną termiczną. Procesor składa się z 12nm chipletu zawierającego kontroler pamięci i interfejsy wejścia-wyjścia (większy z rdzeni) oraz 7nm chipletu (mniejszy rdzeń) zawierającego dwa moduły CCX z architekturą ZEN2. Na fotografii widoczne są szczegóły wewnętrznej struktury tych rdzeni - przyjrzyjmy się im bliżej.
Chiplet I/O zawiera struktury krzemowe przypominające swoim wyglądem elementy, jakie znajdowały się w rdzeniu procesorów Ryzen 1 i 2. generacji wokół modułów CCX.
Mniejszy 7nm chiplet zawiera wyłącznie dwa moduły CCX oraz umieszczoną pomiędzy nimi część magistrali Infinity Fabric. Budowa modułów CCX jest podobna jak w architekturze ZEN / ZEN +, to znaczy rdzenie znajdują się na końcach modułów, a pomiędzy nimi umieszczono pamięci podręczne L2 i L3. Zauważyć można przebudowaną strukturę rdzeni ZEN2, ze znacznie większą niż w ZEN / ZEN + powierzchnią przeznaczoną na pamięci L0 / L1-I, oraz podwojoną jednostkę zmiennoprzecinkową wysunietą na krawędź rdzenia.
Obliczona powierzchnia dla jednego rdzenia ZEN2 (bez pamięci L2 i L3) wynosi tylko 2,9 mm2. Dla porównania 10nm rdzeń Sunny Cove (bez pamięci L2) ma powierzchnię 4,4 mm2.
Ciekawe (autor: PCCPU | data: 13/07/19 | godz.: 21:10) Blok FPU względem Zen/Zen+ został rozbudowany i duża część logiki została jakby zdublowana. Teraz FPU zajmuje dużo więcej tranzystorów niż wynikało by to z samego poszerzenia jednostek 2x128bit(Zen/Zen+) do 2x256bit.
Edit (autor: PCCPU | data: 13/07/19 | godz.: 22:33) Prawdopodobnie są to po prostu dwa bloki po 256 bit, tylko dziwne że tak od siebie odsunięte.
Widocznie podstawowy blok FPU z Zen/Zen+ w Zen 2 przeprzeprojektowali by zamiast 2x128 bit było 1x256bit i większość logiki wraz z rejestrami zdublowali do 2x256 bit.
To jest ZEN / ZEN+. FPU mamy tu w lewym dolnym rogu. I jest to FPU + Sheduler. W przypadku ZEN 2, wygląda to tak, że dodali drugi identyczny blok FPU nad Shedulerem, a całość została przeniesiona poza dotychczasowy rdzeń, czyli na lewo. Miejsce zajmowane w ZEN1 przez FPU+FPU Sheduler wykorzystano na inne ulepszenia zawarte w ZEN 2, jak reorganizacja L0+L1-I, lepsze BPU, dodatkowy potok AGU, itp, itd.
Zbyszek. J (autor: PCCPU | data: 14/07/19 | godz.: 00:55) Wiem o tym że miejsce bloku FPU z Zen/Zen+ w Zen2 wykorzystano na ulepszenia Front-end i bloku sta) oprzecinkowego. Mimo wszystko ciekawe że przebudowany FPU zdublowano. Spodziewałem się że ogulna budowa FPU w Zen2 będzie podobna do Zen tyle że rozbudowana więc dla tego moje zdziwienie.
Możliwe że inżynierowie AMD kierowali się rozkładem gorących punktów w rdzeniu więc chcieli rozłożyć na większą powierzchnię lub łatwiej było po prostu zmodyfikować FPU z Zen i zdublować w obrębie bloku FPU.
Ciekawe jakie konsekwencje niesie ze sobą taka budowa FPU w kontekście wydajności.
@4. (autor: pwil2 | data: 14/07/19 | godz.: 12:08) Wg mnie właśnie kwestia skalowalności i rozłożenia ciepła. Ciepło rozkłada się po całym krzemie i ALU oraz FPU wzajemnie się tak nie dogrzewają. Tym bardziej, że w 7nm wszystko jest na mniejszej powierzchni rozłożone, niż w bardziej przestarzałych 10/14nm. W przyszłości mogą jeszcze łatwo rozbudować FPU do 4x256 lub 2x512. Być może takie dwie osobne jednostki mogą jednocześnie niezależnie pracować w różnych miejscach kodu, wątkach działających na tym samym rdzeniu.
Widać ogromną przewagę nad Intelem we wzroście efektywności przy użyciu wielowątkowości. W obliczeniach stałoprzecinkowych Zen 1/1+ przeganiał Intela dopiero przy skorzystaniu z HT, a teraz bez HT są +- na równi, a AMD odchodzi mocno na prowadzenie z aktywnym HT.
Pod względem FPU wyrównana walka teraz. Dawniej AVX/AVX2 były słabszą stroną. Z tym, że u Intela po skorzystaniu z AVX/AVX2 zegar czasem dość wyraźnie spadał, a tu jest porównane przy tym samym taktowaniu.
c.d. (autor: pwil2 | data: 14/07/19 | godz.: 12:22) Dotychczas najbardziej udanym sposobem na walkę z Intelem, było stosowanie podobnej architektury do niego, by optymalizacje pod Intela jednocześnie miały zastosowanie dla AMD. Inne drogi może byłyby bardziej efektywne, ale mając do wyboru 20% lub 80% rynku, producenci oprogramowania wybierali optymalizację pod tą drugą grupę (4-wątkowe i5 vs 8-wątkowe Phenomy2, które zyskały dopiero po wprowadzeniu większej ilości rdzeni przez Intela).
c.d. (autor: pwil2 | data: 14/07/19 | godz.: 12:23) 2.9mm vs 4.4mm. Ktoś jeszcze będzie gadał bzdury, że 10nm Intela > 7nm TSMC/Samsunga? ;-)
@8. (autor: PCCPU | data: 14/07/19 | godz.: 12:47) Myślę że to nie tak do końca jest z tą optymalizacją. x86 Intela i AMD przetwarzają dokładnie te same instrukcje/roskazy tyle że za pomocą różnych rozwiązań mikroarchitektonicznych i algorytmów. Jeśli Intel czy AMD wykonali w danej części rdzenia najbardziej optymalną z punktu wydajności logikę to konkurent musiałby tą część logiki wykonać identyczną lub bardziej rozbudować. Każde z nich stosuje różne rozwiązania do przetwarzania tych samych rozkazów a więc siłą rzeczy któreś musi być mniej efektywne.
Były testy z optymalizacji specjalnie pod implementację x86 AMD i wcale nie było lepiej niż pod optymalizację Intelowską. Także nie wierzę w takie coś że gdyby soft był pisany pod AMD to nagle rdzeń AMD był by szybszy chociażby o te 10%.
Intel ma coś jak ALFPU czyli ALU rozbudowane o logikę FPU którego rejestry 256bit czy 512bit mogą być użyte również dla ALU. Może to jest najlepsze rozwiązanie jeśli chodzi o latencję i w konsekwencji wyższa wydajność ale na pewno minusem jest nagrzewanie się ALU od FPU. U Intela wszystkie jednostki wykonawcze są w jednym miejscu co powoduje że jest to chyba najgorętszy punkt rdzeni.
AMD w x86 masz osobno ALU i FPU dzięki czemu nie nagrzewają się wzajemnie tym bardziej że rejestry FPU 256bit są od siebie oddalone. Coś za coś.
Widać że rdzeń Sunny Cove pod względem ilości tranzystorów wciąż jest sporo większy od Zen2 i nie zdziwię się jeśli SunnyCove ma natywnie FPU 2x512 lub 2x256+512 ale w IceLake-U dodatkowa jednostka jest wyłączona.
@7. (autor: PCCPU | data: 14/07/19 | godz.: 13:24) Myślę że jednym z czynników powodujący wyższość Zen2 w SMT jest osobny blok FPU a osobny dla ALU, dzięki czemu rdzeń może w tym samym czasie liczyć zmienne przecinki jak i stałe przecinki.
Intel ma 3xALFPU i 1ALU co powoduje że Zmienne nie mogą być liczone w tym samym czasie co stałe na trzech pierwszych portach. Jednym ze sposobów zwiększenia wydajności SMT w rdzeniu Intela będzie zwiększenie portów ALFPU lub samego ALU.
@11. (autor: pwil2 | data: 14/07/19 | godz.: 14:17) Ale to by się ujawniało tylko w testach mieszanych, a tu wychodzi zysk na samym FPU+FPU lub ALU+ALU.
@12. (autor: PCCPU | data: 14/07/19 | godz.: 15:14) Napisałem że jest to jeden z czynników. Zen2 ma scheduler dzielony, czyli osobny dla każdej jednostki wykonawczej co może sprzyjać SMT. Do tego inny podsystem cache gdzie L2 nie zawiera kopi L1 a z kolei L3 nie zawiera kopi L2 więc to również może sprzyjać SMT.
Jak wiadomo Skylake i SunnyCove mają dla ALU i FPU zunifikowany cheduler a L2 zawiera kopię L1 i L3 zawiera kopię L3(Prócz Skylake-X).
Edit (autor: PCCPU | data: 14/07/19 | godz.: 15:17) Jak wiadomo Skylake i SunnyCove mają dla ALU i FPU zunifikowany cheduler. Cache L2 zawiera kopię L1 z kolei L3 zawiera kopię L2(Prócz Skylake-X).
Po testach mobilnych IceLake będziemy wiedzieć czego spodziewać się po SunnyCove.
Zbyszek (autor: PCCPU | data: 14/07/19 | godz.: 15:34) Jest błąd w opisie CCX Zen2. Każdy rdzeń ma 4MB L3 a nie 8MB. Na CCX przypada 16MB(4x4MB) a według opisu struktury rdzeni wychodzi że 32MB na CCX co dawało by 64MB na chiplet a jest 32MB na 8 rdzeni.
@10 (autor: power | data: 14/07/19 | godz.: 16:03) Gdyby soft byl optymalizowany z mysla o AMD to bylaby roznica w wynikach na korzysc AMD. Na przyklad CPU AMD mialy wiecej fizycznych rdzeni czy wiecej pamieci cache. Gdyby soft wykorzystywal te cechy to na CPU intela bylyby gorsze wyniki (fizyki i matematyki nie oszukasz).
@16. (autor: PCCPU | data: 14/07/19 | godz.: 16:12) Co do większej ilości rdzeni się zgodzę ale nie co do cache. Cache jest przeźroczysty dla programisty i tylko sprzętowe algorytmy rdzeni zarządza cachem.
Edit (autor: PCCPU | data: 14/07/19 | godz.: 16:50) Programista głównie widzi rejestry rdzeni procesora a w rdzeniach większość działa z automatu za sprawą mechanizmów sprzętowych i algorytmów.
A ja mam FX8300 (autor: rookie | data: 14/07/19 | godz.: 22:01) I na razie daje radę :) Wiem, że jest na poziomie Ryzena 3, lub nawet nieco poniżej,więc przy Ryzenie 4generacji pewnie zmienię wysłużone AM3+....
@13. (autor: pwil2 | data: 15/07/19 | godz.: 11:22) Zawiera L2 zawiera w sobie L1 w Ryzenach.
@16. (autor: pwil2 | data: 15/07/19 | godz.: 11:30) Cache jest przeźroczysty, ale dobry programista powinien być świadomy wielkości cache procesora, pod który optymalizuje oprogramowanie. Jeśli przetwarzasz dane paczkami mieszczącymi się w cache danego poziomu, zajmie to krócej, bo nie trzeba będzie czekać na wolniejszy poziom. Jeśli podzielisz dane na paczki poniżej 256kB, będzie optymalnie dla Intela, a na AMD drugie 256kB będzie się marnować (i tracić na większych opóźnieniach 512kB L2 względem 256kB L2). Zwiększając pod 512kB na AMD będzie wydajniej, ale Intel (Core ix) będzie ciągle doczytywać z wolnego L3.
@21. (autor: PCCPU | data: 15/07/19 | godz.: 14:09) A to nie jest tak że do L2 ładowane jest tyle danych ile się zmieści?
Edit (autor: PCCPU | data: 15/07/19 | godz.: 14:19) Skylake-X ma podsystem cache działający jak w Zen/Zen2, czyli dane z L2 nie są dublowane do L3. L2 1MB za to jest dużo wolniejszy od L2 256KB i zapewne wolniejszy niż L2 512KB w Zen/Zen2.
@22. (autor: pwil2 | data: 17/07/19 | godz.: 04:05) Jest trzymanych tyle, ile się zmieści, a (zwykle) to co najdawniej było używane wylatuje. I właśnie tykając 257-tego kilobajta danych wyrzucamy pierwszy kB z pamięci podręcznej w Core ix, a w Ryzenie dopiero przy 513 kilobajcie. To tak w uproszczeniu. W przypadku porozrzucanych losowo danych dochodzi element asocjacyjności cache (każda komórka pamięci ma często tylko kilka miejsc w pamięci podręcznej, gdzie może wylądować). Jeśli procesory mają różne stopnie asocjacyjności pamięci podręcznej, można sięgać do danych w taki sposób, który spowoduje częste/ciągłe wyrzucanie danych z pamięci podręcznej na procesorze z mniejszym stopniem asocjacyjności (lub mniejszą jej pojemnością). Dlatego odrobina złej woli/niewiedzy może powodować mniejszą wydajność jednego z procesorów, bez zysków na drugim z nich.
Przykład. Mam 64GB RAMu w swoim PC i chcę na (woolnym 2.5 5400rpm) HDD zapuścić weryfikację 3TB archiwów, a następnie wyliczenie sum kontrolnych CRC/MD5 za pomocą 2 odrębnych aplikacji. Jeśli pliki archiwum będą miały do ~60GB, wykonując te 3 operacje dla tego samego pliku, a następnie przechodząc do kolejnego sprawię, że pierwszy odczyt będzie z dysku (MB/s, 3TB odczytów łącznie), a następne z pamięci cache (GB/s, 6TB odczytów z cache). Jeśli zrobię to w trzech odrębnych przebiegach, potrwa to blisko 3x dłużej (9TB odczytów z HDD).
Jeśli wyjmę połowę pamięci RAM i pozostałą podkręcę, dla plików do ~28GB zmiana będzie na plus (1-5%) w tym pierwszym wariancie, ale dla większych plików będzie spadek wydajności o blisko 66%. Dla drugiego wariantu algorytmu będzie bez zmian (dysk będzie ograniczał; konieczność odczytania 9TB danych z HDD).
Zakładam, że OS+aplikacje zajmą 4GB RAMu dla siebie, co zmniejszy dostępny cache systemowy.
@23. (autor: pwil2 | data: 17/07/19 | godz.: 04:06) Było to koniecznością, gdy L3 jest mniejszy od L2, a L2 musiał być duży,
c.d. (autor: pwil2 | data: 17/07/19 | godz.: 04:08) z tego powodu, że przy 28 rdzeniach w procesorze wspólny L3 cache się przytykał (miał za małą przepustowość) przy tylu jednoczesnych dostępach. A zwiększenie L2 sprawiło, że rdzenie dużo rzadziej sięgają do L3.
Asocjacia (autor: PCCPU | data: 17/07/19 | godz.: 13:04) L1, L2 w Zen 2 jest identyczna jak Core i. Czyli nie ma takiej sytuacji że w Ryzen tylko 256KB jest ładowane do L2 a resztę przerzucane do L3. L2 jest zapełniane do póki nie braknie pojemności a następne dane lecą do L3. Dzieje się to automatycznie za sprawą sprzętowych mechanizmów i algorytmów w nich zawartych.
W Skylake-X jest tak samo. 1MB L2;jest ładowany aż do zapełnienia a nreszta danych leci do L3. Intelowi chciał tym rozwiązaniem nadrobić wydajność w pewnych opciążeniach, niestety kosztem innych. Przez to że L2 jest dużo wolniejsze IPC poleciało w niektórych zastosowaniach nawet kilkanaście % mimo iż efektywna pojemność jest większa niż w Skylake.
Edit (autor: PCCPU | data: 17/07/19 | godz.: 13:19) L1, L2 i L3 jest w pełni automatycznie sterowana logiką rdzeni procesora.
Edit2 (autor: PCCPU | data: 17/07/19 | godz.: 13:30) Intel nie bez powodu stosował do tej pory 256KB pamięć L2 i przechowywanie kopi L2 w L3.
Co do Asocjacji w Skylake 256KB jest 4-Way a i tak IPC jest wyższe niż w Haswell/Brosdwell którego L2 256KB jest 8-Way.
Natomiast SunnyCove ma L2 512KB 8-Way tak samo jak Zen/Zen2.
@29. (autor: pwil2 | data: 17/07/19 | godz.: 15:56) Kwestia optymalizacji. W pierwszych testach Ivy i Skylake nie były wydajniejsze jednoznacznie od swoich poprzedników, ale z optymalizacjami różnica wzrosła.
W Ryzenach L1 korzysta z czegoś w stylu AI i zmienia algorytm wyrzucania z L1 cache w zależności od rodzaju dostępów. Nie zawsze jest to LRU.
@29. (autor: PCCPU | data: 17/07/19 | godz.: 23:47) IvyBridge to delikatnie poprawiony SandyBridge i przeniesiony do 22nm. IPC Ivy jest wyższe zaledwie o kilka % więc raczej znikoma różnica. Jedynie co mogło dać kopa to generator liczb losowych.
Skylake miał wyższe IPC od Broadwella a tym bardziej Haswella.
Jedynie Brosdwell z L4 jest na podobnym poziomie.
Skylake-X to już inna historia. Przeprojektowano podsystem pamięci cache i przez to nadal traci IPC nawet kilkunaście % do Broadwell w części testów.
Edit (autor: PCCPU | data: 17/07/19 | godz.: 23:55) Skylake-X traci w IPC do Broadwell-E nawet kilkanaście % przez co musi nadrabiać taktowaniem.
Przewidywanie w Zen i Zen2 mimo iż opera się o AI to wciąż jest sprzętowy i jego skuteczność w dużym stopniu zależy od algorytmów które AMD zaimplementowało.
Nowa agesia 1.0.3ab (autor: MacLeod | data: 18/07/19 | godz.: 18:32) Nie aktualizowac, pierdoli wszystko po kolei. Przestaje dzialac cnq, turbo jeszcze mniejsze. Tragedia:)
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
