Skocz do zawartości
Zamknięcie Forum PC LAB

Szanowny Użytkowniku,

Informujemy, że za 30 dni tj. 30 listopada 2024 r. serwis internetowy Forum PC LAB zostanie zamknięty.

Administrator Serwisu Forum PC LAB - Ringier Axel Springer Polska sp. z o.o. z siedzibą w Warszawie: wypowiada całość usług Serwisu Forum PC LAB z zachowaniem miesięcznego okresu wypowiedzenia.

Administrator Serwisu Forum PC LAB informuje, że:

  1. Z dniem 29 listopada 2024 r. zakończy się świadczenie wszystkich usług Serwisu Forum PC LAB. Ważną przyczyną uzasadniającą wypowiedzenie jest zamknięcie Serwisu Forum PC LAB
  2. Dotychczas zamowione przez Użytkownika usługi Serwisu Forum PC LAB będą świadczone w okresie wypowiedzenia tj. do dnia 29 listopada 2024 r.
  3. Po ogłoszeniu zamknięcia Serwisu Forum od dnia 30 października 2024 r. zakładanie nowych kont w serwisie Forum PC LAB nie będzie możliwe
  4. Wraz z zamknięciem Serwisu Forum PC LAB, tj. dnia 29 listopada 2024 r. nie będzie już dostępny katalog treści Forum PC LAB. Do tego czasu Użytkownicy Forum PC LAB mają dostęp do swoich treści w zakładce "Profil", gdzie mają możliwość ich skopiowania lub archiwizowania w formie screenshotów.
  5. Administrator danych osobowych Użytkowników - Ringier Axel Springer Polska sp. z o.o. z siedzibą w Warszawie zapewnia realizację praw podmiotów danych osobowych przez cały okres świadczenia usług Serwisu Forum PC LAB. Szczegółowe informacje znajdziesz w Polityce Prywatności

Administrator informuje, iż wraz z zamknięciem Serwisu Forum PC LAB, dane osobowe Użytkowników Serwisu Forum PC LAB zostaną trwale usunięte ze względu na brak podstawy ich dalszego przetwarzania. Proces trwałego usuwania danych z kopii zapasowych może przekroczyć termin zamknięcia Forum PC LAB o kilka miesięcy. Wyjątek może stanowić przetwarzanie danych użytkownika do czasu zakończenia toczących się postepowań.

AMDK11

Forumowicze
 Pokaż profil  Zobacz aktywność

  • Liczba zawartości

    1184

  • Rejestracja

  • Ostatnia wizyta

Odpowiedzi dodane przez AMDK11

  2. Napisano · Edytowane przez AMDK11

    Jeśli zbliżą się w wydajności rdzeń w rdzeń do SB to będzie spory sukces. Wtedy moduł spokojnie pokona rdzeń+HT w wykonaniu niebieskich. Ale priorytetem winien być nacisk na poprawienie wydajności jednego rdzenia. Nie ma co liczyć na to, że systemy dadzą fory AMD w zarządzaniu procesami i przydzielaniu "rdzeniom" procesów i wątków. Więc jedyną szansą jest albo pójście w energooszczędność (co jest bardzo trudne przy tym stopniu skomplikowania architektury K15 oraz zastosowanego procesu technologicznego) albo gwałtowne zbliżenie się do konkurenta.

    Nie liczył bym na to że Moduł steamroller w ST będzie wydajniejszy lub nawet dorówna Rdzeniu SB/IB bo jeśli nawet będzie wyraźnie wydajniejszy od K10 to już będzie duży sukces. Natomiast Moduł SR w MT(CMT) ma szanse być wydajniejszy od 1 Rdzenia SB/IB/HSW z HT.

    Co do FPU to kwestia w jakim stopniu poprawią tą część Modułu i ile da dodanie dekoderów x86.

     

    Wystarczy że Moduł SR będzie znacznie wydajniejszy od Rdzenia SB/IB/HSW to siłą rzeczy w pojedynczym wątku powinien być znacznie wydajniejszy od Rdzenia K10.

     

    A jak to wyjdzie w praktyce czas pokaże.

  3. Napisano

    Nikt nie chce nikogo pokarać, więc nie pokarze Cię za to, że AMD pokaże ;)

    Projekt projektem, teoria teorią ale dochodzi wykonanie i wykorzystanie togo so cię na papierze skreśliło. A na razie tylko w K10rev2 czyli Deneb/Thuban AMD dawało realną konkurencję dla Intela (Quady serii 6xxx i 9xxx). Steamroller może znacząco podniesie wydajność, może nie. Problem w tym, że Intel nie śpi i jego Haswell znów odskoczy zielonym.

     

    No jak AMD przy Steamroller nie schrzani sprawy to jest szansa że coś z tego wyjdzie :)

    Myślałem że w Rdzeniu Haswell jak będzie 4ALU i 3AGU to znacząco wzrośnie wydajność ale jednak te jednostki wykonawcze zostały dodane głównie po to by odciążyć jednostki FPU więc jak IPC wzrośnie o te 10% to i tak będzie dobrze ale z drugiej strony nie jest to aż tak dużo tyle że Intel już ma bardzo wydajne Rdzenie i AMD musi się nieźle napocić by dogonić Intela.

  4. Napisano · Edytowane przez AMDK11

    Moduł Bulldozer/Piledriver jest rzeczywiście bardzo niedopracowany.

    W "AMD Family 15h Optimization Guide" pisze wyraźnie że każdy z dwóch klastrów Integer w Module dysponuje schedulerem który potrafi przyjąć 4 uops tyle że jednostki wykonawcze mogą przeliczyć maksymalnie 2 uops (K10 3 uops) a jednostek wykonawczych jest 4(2ALU i 2AGLU). Teoretycznie każdy klaster Int powinien przeliczać 4 uops.

    Pytanie czy jest to wina dekoderów czy konstrukcji Int.

    Klastry Int Bulldozer/Piledriver mają niby 4 potoki wykonawcze 2ALU i 2AGLU (K10 3 potoki wykonawcze(3ALU/AGU)) co w sumie daje 8 potoków dla dwóch klastrów Integer w Module CMT(4ALU 4AGLU).

    Być może jest tak że 4 dekodery x86 już są podzielone na stałe po 2 Dekodery x86 na pojedynczy klaster Integer co w konsekwencji ogranicza Integer do 2 uops zamiast 4.

    Wychodzi na to iż obecnie Moduł BD/PD w pojedynczym wątku osiąga maksymalnie do 2 IPC a w zastosowaniach wielowątkowych ponad 3 IPC(K10 2,5 IPC).

    W pojedynczym wątku obciążane są tylko 1ALU i 1AGLU w pojedynczym cyklu zegarowym z dostępnych 2ALU i 2AGLU.

    Jeżeli chodzi o wielowątkowość(CMT) Moduł obciąża maksymalnie 2ALU i 2AGLU z dostępnych 4ALU i 4AGLU więc nie ma się co dziwić że Rdzeń SB/IB dysponujący 3ALU i 2 AGU jest wydajniejszy na takt zegarowy i osiąga jakieś 4,1 IPC.

     

    W Module Steamroller będzie 8 dekoderów x86 a więc 4 dekodery na klaster Int więc realnie każdy z dwóch klastrów Int będzie mógł przeliczyć 4 uops(są szanse) co z kolei umożliwi Modułowi w zastosowaniach wielowątkowych przetwarzanie 8 uops.

     

    Oczywiste jest że nie od razu się tak stanie że Moduł SR będzie ponad 50% wydajniejszy ponieważ głównie tylko część wąskich gardeł(głównych) zostanie usunięta a na kolejne wzrosty wydajności trzeba będzie poczekać do np min Excavator i kolejnych generacji.

     

    Ciekawe będą skany Modułów SR z APU Kaveri bo to pokaże jak wielkie będą zmiany w mikro architekturze :)

  5. Napisano · Edytowane przez AMDK11

    Ach, to teraz będziem mieszać w parametrach by uzyskać jakieś różnice? :rotfl:

    Panowie, proponuję skończyć zabawę w tym "benchmarkiem"

    No wiesz ja zaproponowałem to z czystej ciekawości bo nie mam obecnie warunków do tego by sprawdzić na innym procku. No ale jeśli to tylko symulacja nie mająca nic wspólnego z realnym testem(na co wychodzi) to trudno się mówi i przepraszam za offtop.

     

    Ciekawostka dotycząca Modułu Steamroller:

    "Nieco więcej

    światła na sprawę rzuca

    artykuł portalu VR-Zone,

    którego redaktorom udało

    się dotrzeć do Marka

    Papermastera (CTO w

    AMD) i uzyskać informację,

    że wzrost wydajności

    wyniesie nawet 30% w

    stosunku do Bulldozera/

    Piledrivera. Ponadto

    otrzymal oni i opublikowali

    w swoim artykule

    wiadomość od jednego z

    inżynierów AMD, według

    którego wzrost wydajności

    może być większy i wynieść

    do 45%. Biorąc pod uwagę

    podwojenie dekoderów, a

    tym samym wzrost

    potencjalnych możliwości

    wykonawczych o 100%, oraz

    poważne zmiany w

    pozostałych częściach

    architektury, nie wydaje się

    to zupełnie nierealne."

  10. Napisano · Edytowane przez AMDK11

    Tylko jeśli dobrze to interpretuję to niewiele róźni się w taim razie IPC FX'a i phenoma.

    A mooon podał na poprzedniej stronie inne wyniki

    Te parametry można modyfikować:

    NumRS: 4 (max 4)

    NumALU: 3 (max 3)

    Najważniejsze są dwa ostanie wyniki(IPC)

    Moon na poprzedniej stronie podał wyniki z parametrem NumALU:2 ale na NumALU:3 wyniki wzrosły z 2 IPC do 2,6 IPC tyle że nie wiem przy jakim zegarze.

    Testowałem Phenoma II na 3,5GHz i wynik był na poziomie 2.5 IPC a przy 1GHz 2,3 IPC.

  16. Napisano · Edytowane przez AMDK11

    To ciekawe dlaczego AMD zamiast zrobić wspólne 3/4ALU + 3AGU na moduł, podobnie jak jest z FPU to rozdzieliło to na osobne bloki INT. Jednostek powinno wystarczyć dla 8 dekodowanych rozkazów przez dekodery, a i troche miejsca by zaoszczedzili. Osobone dla wątków byłyby tylko potoki po 4 na wątek tak ja to obecnie jest. Było by to zliżone do rozwiązania intela, z tym że nie zajmowało by się wolnych miejsc w potokach jak to ma miejsce u intela.

    link

     

    Ponieważ nie jest to takie proste no i musieli by zastosować HT by optymalnie wykorzystać wszystkie te jednostki wykonawcze. AMD dawno temu już deklarowało że nigdy nie zastosują HT w taki sposób jak to zrobił Intel i że mają swoje własne rozwiązanie(CMT).

    2ALU i 2AGU dla pojedynczego wątku jest to takie optymalne minimum. Wiadomo że mniej wydajne w pewnych zastosowaniach niż 3 ALU(zależnie od kodu) ale przewaga nad K10 powinna być ponieważ K10 ma tylko trzy potoki dla INT a jednostek jest 6 co jest bardzo nieoptymalne i taka konstrukcja zachowuje się jak gdyby było 3 ALU/AGU.

    Pojedynczy klaster INT w BD ma cztery potoki także kod programu ma do dyspozycji stale 4 jednoski wykonawcze i nie musi "walczyć" o zasoby.

    Intel w Haswellu zwiększył przepustowość frontendu z 6 do 8ops i dodał czwartego ALU i trzeciego AGU ale mimo tego jak wydajność w pojedynczym wątku wzrośnie o te 10% to będzie dobrze. Intel dodał te jednostki po to by odciążyć te potoki z jednostkami FPU tym samym zwiększając wydajność zmiennoprzecinkową no i może będzie to miało wpływ na wydajność HT.

     

    Ntomiast drugi klaster INT w module łatwo zwiększa ogólną wydajność takiego Rdzenia CMT i tak jak HT(SMT) pozwala lepiej wykorzystać dostępne zasoby w wielowątkowości.

     

    Teraz kwestią jest dopracowanie szczegułów architektury.

     

    Po rewizji liczba tranzystorow spadla do 1.2 miliarda, to pol miliarda wiecej niz Deneb i 300 milionow wiecej niz Thuban jest 8 watkow nazywane strategicznie rdzeniami przez AMD, bo tak chca. Powierzchnia dosyc duza, ale nikt im nie zarzuci, ze w stosunku do pierwszych Phenom II nie dolozyli czegokolwiek oprocz wyzszego taktowania. Plan ich przerosl taktowanie jest za niskie, bo pobor pradu jest za wysoki, a w rewizji C0(PD) wg czeskiego komika jeszcze wyzszy niz w B2, moze i tak byc Barcelona bedzie sie wstydzic.

     

    Ilość tranzystorów liczono po gęstości ich upakowania i całej powierzchni jądra Zambezi ale że jest bardzo nieoptymalne rozmieszczenie Modułów+L2 względem siebie i względem L3 to konsekwencją jest dużo niewykorzystanego miejsca czyli duża powierzchnia przy znacznie niższej ilości tranzystorów.

    Co do Modułu + L2 2MB to wciąż jest to 213 mln tranzystorów i w tej kwestii nic się nie zmieniło.

     

    Edycja:

    Fajnie by było jakby ktoś zapuścił na FX-e

    "CPU Scheduler Simulation" który jest plikiem w formacie Excel i podał wyniki tak z ciekawości.

     

    Spadla gestosc upakowania wzrosla powierzchnia, bo BD jest pomyslany na wyzsze czestotliwosci i w tym celu zmodyfikowano cache i instrukcje z wyzszymi latencjami. Zabraklo taktowania za duza jest emisja ciepla musza odchudzic modul jesli nie chca dalej grzebac w potoku wykonawczym i jednostkach lub isc w odwrotna strone.

    Nie wiem co sobie myśleli że uzyskają 4.5-5GHz na 32nm z GF?

    Tak się tłumaczą ale prawda jest taka że pujście w wydłużanie potoku wykonawczego i wysokie zegary to pójście niejako na łatwizne bo zawsze uzyskuje się to kosztem niższego IPC. To miało by sens gdyby GF miał przewagę w procesie technologicznym lub był przynajmniej na równi z Intelem ale tak nie jest. AMD nie miało wyjścia i poszło w wysokie zegary. Ciekawe jest czy to się zmieni czy już przy tym pozostaną.

     

    Na odchudzanie Modułu bym nie liczył bo zaczyna się dopakowywanie w Steamroller np. min 128KB L1I, 8 Dekoderów x86...

    W Excavator ma być min znacznie poprawiony FPU.

  17. Napisano · Edytowane przez AMDK11

    To czy wykorzysta w duzej czesci zalezy od rodzaju kodu, AMD twierdzilo, ze z 2 parami ALU+AGU scalonymi do 2 rdzeni dadza rade dojsc do 80% mozliwosci CMP tego nie ma, moze w skrajnych wypadkach. Na dzisiaj procenty pojawily sie dla BD3 to 5-10% mozna spisac dla single-core i 30% bardziej operatywny modul dla watkow. To dobre wyniki pod warunkiem, ze HSW nie podniesie wydajnosci na watek o 10% i HT nie dzwignie sie te kolejne 10% i o tyle mozna byc sceptycznym, na ile AMD ma wiedze oparta na probkach nowego procesu, bo u Intela juz prace sa na finiszu i za 15 miesiecy ruszaja z BRW.

     

    Masz rację że obciążenie jednostek wykonawczych zależy od kodu i właśnie napisałem że ciężko jest przez większość czasu obciążyć wpełni trzeci ALUs pojedynczym wątkiem a nie że zawsze.

    8 dekoderów x86 w Steamroller ma polepszyć skalowanie dwóch klastrów int ale i lepsze wykorzystanie dostępnych zasobów w każdym z nich.

     

    Już widzę te 4 instrukcje (przynajmniej w obecnej formie BD) :E.

     

    No i tak to jest jak człowiek robi coś w pośpiechu. Miało być oczywiście 4 mikro-operacje w klastrze integer modułu BD a że Moduł jest niedopracowany to myślę że obecnie jednostki Integer nie są w pełni wykorzystane.

    Temu właśnie Steamroller ma dostać 4 dekodery na pojedynczy klaster Integer(8 dekoderów na Moduł) by zagwarantować 4 mikro-operacje 4 jednostkom wykonawczym(2ALU 2AGU).

     

    Nie mówię że w SR zostaną usunięte wszystkie wąskie gardła ale powinno być już znacznie lepiej niż jest obecnie w BD.

     

    Tak tylko koncepcja BD to mniej tranzystorow, mniej energii zuzywanej, wiecej efektywnosci, taktowania i miejsce dla kolejnych CU(moduly dla serwerow, shadery dla konsumeckiego). W programach z wysokim ipc ~2 nie maja co szukac, a w okolicach ~1 sa optymalna architektura gdyby nie slabsze ipc po wlaczeniu CMT czyli to jest pierwsze do poprawienia minimalizacja kosztow CMT.

    W BD3 ma byc czesc rozbudowana(faza dekodowania) dzieki oszczednosciom w innym miejscu. AMD jest przywiazane do GF, jesli tam cos trzyma za gardlo ta architekture, a moze kluczowe to ciezko przeskoczyc.

    Teraz pomysle nad Phenom II zamiast BD, powiedzmy proste policzenie 2xDeneb to juz jest wiecej niz BD, a kto wie ile zajeloby nowe FlexFPU.

     

    Mniej tranzystorów? Moduł składa się z grubsza z tylu tranzystorów(60+ mln) co dwa Rdzenie K10(30+ mln t) a przy tym i tak zegar w zegar jest wolniejszy(2T) nie mówiąc już o Rdzeniu SB/IB który składa się z ~55 mln tranzystorów a dodać do tego 2MB L2/Moduł+L3 8MB to gdzie tu oszczędność tranzystorów? Względem 8 rdzeniowca Intela przy wydajności zegar w zegar niższej niż 4 Rdzenie SB/IB? Czy może wymaginowanego 8 rdzeniowego K10? Marketingowy bełkot i tyle.

     

     

    Inżynierowie którzy opracowali patenty na architekture BD sami określali obecny Moduł/2T Rdzeniem a że marketingowcy sobie wymyśleli że nazwą Moduł dwoma rdzeniami to już inna bajka.

    Wystarczy przejżeć patenty na BD jak i dokumenty dla programistów zwłaszcza w którym w jednym mijejscu piszą że CU(Moduł)=dualcore a w innym że w CU są dwa klastry integer 0 i 1. Widać że marketingowe naleciałości sięgają już nawet do dokumentacji BD dla programistów.

     

     

     

    Intel by wykorzystać w jak największym stopniu zasoby Rdzeni stosuje HT(SMT) natomiast AMD CMT(Cluster(Integer) Multithreading) bo w pojedynczym wątku wiele zasobów się marnuje ale najważniejsze jest wykonanie(szczegóły architektury) a z tym u AMD puki co jest kiepsko.

     

    Edycja:

    Gdzie informacja że w Steamroller zwiększą ilość dekoderów kosztem innych elementów?

    Wiadomo że nie rozbudują wszystkiego na raz ale w Excavator przyjdzie czas min na FPU tyle że potem to już wielka nie wiadoma czy dalej będzie rozwijanie koncepcji CMT czy odejście od tego na rzecz klasycznego modelu Rdzeni.

  18. Napisano · Edytowane przez AMDK11

    Przeciez modul mial oferowac to co 2 rdzenie tylko w ekonomicznym opakowaniu i z szansa na przyszly rozwoj. Wyprobowali w 1 generacji, wiedza co szwankuje teraz beda poprawiac, zeby bylo jasne ta architektura ma przyszlosc i splaci sie, moze oplaci. ;)

    Marketingowo i owszem tyle że w rzeczywistości Moduł jest Rdzeniem x86 CMT nastawionym na wielowątkowość. AMD było na ręke z tego względu że wydajność w pojedynczym wątku to cholernie skomplikowana sprawa a opracować rdzeń przetwarzający równolegle dwa wątki przez dodanie im dedykowanych jednostek wykonawczych a tym samym podniesienie dzieki temu rozwiązaniu wydajności jako całości(Moduł) jest nieproporcjonalnie łatwiejsze np Rdzeń K10 ma teoretyczne max 3 IPC a Moduł/2T BD do 4 IPC.

    Podnoszenie wydajności w pojedynczym wątku zostało rozłożone w czasie przez to że AMD nie ma takich środków jakimi dysponuje Intel. Nawet Intel przez cały okres Netbrust(Pentium 4) rozwijał architekturę P6(Pentium III) aż opracował Conroe(Core 2).

    Czasami się zastanawiam czy P4 to nie była tylko prowizorka by mieć czas na dopracowywanie bardzo wydajnego rdzenia Conroe ;-)

     

    Odejscie od K8/10 zostalo wytlumaczone juz dawno i to nie o instrukcje(w Jaguar bedzie lepszy zestaw rozszerzen niz PII, rdzen slabszy) chodzilo tylko o nieefetywne 3 pary symetrycznych jednostek wykonawczych, ktore 2 z rownie dobrym skutkiem moga zastapic. Wydajnosc staloprzecinkowa nie jest taka zla, ale z FPU kuleja od 10 lat i nie wiem co da ta redukcja wielkosci na przyszlosc do wydajnosci, chyba idzie w kierunku oszczednosci energii lub wcisniecia wiekszej liczby modulow. BD w 1 generacji wyglada slabo, jako projekt idzie za mocno do przodu software nie jest przygotowany na kwantowe skoki w architekturze(nowe rozszerzenia wlasne), powinni wiedziec co spotkalo Netburst, ktory tez wprowadzal mase rozszerzen i potem przepadly razem z architektura.

     

    INT w K10(3ALU/AGU) może wykonać maksymalnie 3 mikro-operacje mimo że teoretycznie jest 6 tych jednostek stałoprzecinkowych tyle że AGU/ALU podczepione jest pod jeden pipeline co w praktyce skutkuje tym że w pojedynczym takcie zegarowym tylko jedna jednostka z tej pary jest aktywna, natomiast klaster INT(2ALU 2AGU a każda z tych czterech jednostek wykonawczych w odróżnieniu od K10 ma własny pipeline) w Module BD może 4 mikro-operacje oczywiście teoretycznie ale wąskie gardła architektury niestety skutecznie to utrudniają.

  19. Napisano · Edytowane przez Alejajca

    Tak tylko rdzen Intela jest zaprojektowany tak, zeby byl w duzej czesci zadan niedociazony i przez to watek nie potrafi skonsumowac caly dostepny potencjal jednostek do tego sluzy HT. AMD odcina sie od takiego pomyslu na architekture, bo wierza w wysoka utylizacje, taka mikstura mniej tranzystorow na rdzen wiecej MHz. ;)

     

    Prawda jest taka że w pojedynczym wątku wykorzystać cały potencjał zasobów rdzenia jest bardzo ciężko np przez większość czasu obciążonych jest max 2ALU a trzeci stosunkowo rzadko mędzy innymi dzięki temu HT daje bosta bo trzeci ALUs jest dociążany drugim wątkiem. Jeśli chodzi o AGU to w pojedynczym wątku więcej jak 2 nie ma sensu.

    Intel dodając do Haswella czwartego ALU i trzciego AGU zrobił to z myślą o HT i o odciążeniu tych potoków pod które podpięte są FPU który z kolei dzieli ten potok z ALU.

     

    Taaa, tyle lat kombinowania, dopracowywania i... mamy zabawę, że Piaskowy Mostek zasypał Buldożera :E

    By to AMD zaproponowało miało przyzwoitą wydajność moduł musiałby mieć naprawdę potężny front end, szeroki i szybki cache L1 i L2. Ale wtedy traci to sens.

     

    Frontend w Module Steamroller ma już być dość potężny w końcu ma mieć min 8(4 na klaster int) dekoderów x86 i prawdopodobnie pamięć L1I 128KB.

     

    dokładnie... wtedy zamiast CMT lansowanego przez AMD z modułu zrobiłby się prawdziwy dualcore.

     

    Dualcore to zrobi się wtedy gdy frontend będzie odzielny tyle że wtedy problem byłby z wykorzystaniem zasobów w rdzeniu bez HT i dodawanie kolejnych jednostek wykonawczych było by marnotrawstwem tranzystorów.

    Moduł BD z załorzenia miał być konkurentem Intelowskiego rdzenia z HT bo jak mi wiadomo AMD nie chce HT w postaci Intelowskiej implementacji więc rozwija propagowane przez siebie konkurencyjne CMT.

  22. Napisano · Edytowane przez AMDK11

     

    Frontend w Nehalem/SB/IB osiaga maksymalnie 6ops, bo o tym mowa. Steamroller podniesie o 30% ops na modul, HSW podniesie z 6 na 8ops, czyli przepustowosc frontendu wzrosnie po obu stronach.

     

    Pisałem o ~5 IPC dla SB/IB natomiast na Benchmarku w artykułach podają że jest 4.1 więc może mają rację?

    Dla Modułu BD/PD AMD podaje w dokumentacji dla architektóry h15 Bulldozer teoretyczne max to 4 IPC.

     

    BD/PD dysponują czterema dekoderami x86 na Moduł a każdy o możliwości 4 makro-ops ale w praktyce wychodzi max do 4 mikro-ops.

    Frontend

    Modułu Steamroller zostanie uzbrojony w dwa klastry dekoderów a każdy z nich dysponuje czterema dekoderami x86 więc 2x więcej niż BD/PD.

    Daje to teoretycznie 8 mikro-ops. Dla pojedynczego wątku wychodziło by gdzieś do 4 mikro-ops zamiast obecnie 2 w Module BD/PD.

     

    Czyli na pojedynczy wątek(klaster Int) przypadną 4 dekodery zamiast obecnych 4 na dwa klastry int(Moduł) więc będzie pole do popisu także dla następców SR.

     

    Rdzeń Haswell ma dostać 4ALU 3AGU(SB/IB 3ALU 2AGU) więc podejżewam że dostanie 5-6 dekoderów x86.

     

    Wiadomo że w Rdzeniu SB/IB są 4 dekodery o możliwości 7 mikro-ops(4+1+1+1) więc pewnie 5 lub 6 dekoderów w Haswellu będzie mogło puścić w praktyce więcej niż 1 mikro-ops co da w sumie 8 mikro-ops tak podejżewam.

     

    Rdzeń K10

    3 dekodery x86

    INT 3ALU/AGU

    FPU 1x128b SSE

     

    Rdzeń SB/IB

    4 dekodery x86

    INT 3ALU 2AGU

    FPU 1x128b/1x256b SSE/AVX

     

    Moduł BD/PD

    4 dekodery x86

    2x INT 2ALU 2AGU(CMT 4ALU 4AGU)

    FPU 2x128b/1x256b SSE/AVX

     

    Rdzeń Haswell

    5-6? dekoderów x86

    INT 4ALU 3AGU

    FPU 1x128b/1x256b SSE/AVX/AVX2

     

    Moduł Steamroller

    2x 4 dekodery x86(8 dekoderów x86)

    2x INT 2ALU 2AGU(CMT 4ALU 4AGU)

    FPU 2x128b/1x256b SSE/AVX/AVX2

  24. Napisano · Edytowane przez AMDK11

    Puki co tylko test Trinity może realnie pokazać jakiekolwiek różnice wydajności zegar w zegar Modułu BD vs PD w ST jak i MT bo przecież w Trinity są Moduły te same które znajdziemy w Vishera.

     

    Są może bardziej obszerne testy Trinity vs Zambezi niż te na Tomas Hardware?

    Pamiętam że na Tomasie była 16% przewaga zegar w zegar Modułu PD nad Modułem BD.

  25. Napisano · Edytowane przez AMDK11

    Żadną tajemnicą nie jest że Moduł BD(choć niedopracowany co samo AMD przyznało, miał być od samego początku taki jak Steamroller) miał być następcą wysłużonego Rdzenia K10 i tak w istocie jest choć Moduł nakierowany jest głównie na wielowątkowość.

     

    Rdzeń K10 ~2.5 IPC

     

    Moduł BD do 4 IPC

     

    więc progres jest a że Bulldozer jest architekturą serwerową to i wydajność pojedynczego wątku zeszła na drugi plan ale widać że Steamroller ma szanse poprawić sytuację pod tym względem.

     

    Edit:

    Jedną z wielu zmian w Module Steamroller będzie Cache L1I której ma być 128KB(4-Way?).

    Obecnie w Modułach BD i PD jest 64KB 2-Way więc tyle samo co w Rdzeniu K10.

×
×
  • Dodaj nową pozycję...