mi to wygląda na podpuche

Dziwne są te krzyki oburzenia, choć ... właściwie nie, niektórzy chcieliby, żeby im za darmo wszystko dać. Sami natomiast gdyby tylko, zamienili się miejscami z właścicielami np. Intela, to w nie mniejszym stopniu chcieliby osiągnąć jak najwyższe zyski.

Możliwość software'owego upgrade'u jest zdecydowanie lepszym rozwiązaniem dla ilości wolnego czasu Kowalskiego niż zakup nowego proca.

Wcale nie zakładam ze schedulery k10.5 działają sprawniej od bd. Mam nadzieję że w buldozerze będą one efektywniejsze. Czyli liczę na lepszą implementacje o której kilkakrotnie wspominałem. Jednak jestem również świadom że ta skutecznosć schedulerów buldozera nie moze być za bardzo zbliżona do 100% bo wtedy drugi rdzeń nie miałby sensu. Skoro ten drugi rdzeń kosztuje 12% powierzchni to opłaca się go dodawać gdy średnia skuteczność schedulera będzie mniejsza niz 100-12=88%. Czyli skuteczność schedulera mieści się w przedziale <50%;88%)
Teoretyczna wydajność bd to 1.33 wydajnosci k10.5.
1.33*0.88 = 1.17 tyle wynosi ograniczenie górne mocy pojedynczego wątku bd jeśli pomysł z dwoma rdzeniami ma mieć sens.
Zakres mocy pojedynczego watku buldozera będzie w przedziale <66%;117%) mocy pojedynczego watku k10.5

Tylko że bierzesz pod uwagę takie założenie, że dekoder i wszystkie jednostki w K10.5 są wykorzystywane w 100% - a nie są. Z tego też powodu Twoje założenie na starcie ma duży defekt. 'luzy' są zawsze, tyle, że bulldozer czy core je wykorzystają, a phenom już nie. Kolejna sprawa, że dekoder bulldozera, nawet jak jest wykorzystywany powiedźmy (czysto hipotetycznie) w 75% dla tego jednego wątku, to i tak przetworzy więcej instrukcji niż dekoder w K10 na podobnym poziomie wykorzystania.

@up
W #124 napisałem

'Pytanie jak często kod x86 będzie w pełni wykorzystywał możliwości rdzenia buldozera, jak częste będą sytuacje gdy część jednostek buldozera będzie niewykorzystana? Bo że takie sytuacje będą miały miejsce to nie ma wątpliwości. Pomysł by wykorzystać aktualnie niewykorzystane jednostki jest ideą intelowskiego HT. A na podstawie tego jaki przyrost mocy daje HT można przypuszczać że całkiem sporo tych jednostek jest niewykorzystywanych. '

I od tamtego czasu konsekwentnie i z wielkim zaangażowaniem przekonuje Was do tego że dwa rdzenie są w buldozerze dlatego że sytuacje gdy uda sie wykorzystać wszystkie jednostki są rzadkie.
Fakt to co cytowałem nie było skierowane do Ciebie. Było to w odpowiedzi na post
Amitoza. Ale co miałem zrobić wydać manifest czy jak?

@up - jeszcze raz przeczytaj co napisałeś w 150, a co ja w 151 i napisz jak to ma się do tego co piszesz tutaj. Przypomnę:
'dlatego ze schedulery nie są w stanie przydzielić do wykonania 4 instrukcji w takcie.'
Są, to że tego nie są w stanie zrobić ZAWSZE to całkiem inna sprawa!

to nie AMD podaje, tylko analiza informacji przez użytkownika forum AMD zone. te 2 operacje przy 2 wątach są wzięte po prostu z tego założenia, że dekoder przetwarza 4 instrukcje, a ma do nakarmienia 2 wątki - podobnie jest w core i7.

Jeśli założymy 50% przyrost wydajności to maxymalna moc pojedynczego watku BD powinnna wynosić 4/1.5 = 2.66
Dla k10.5 teoretyczna jest 3.
Różnica nie jets wielka i to może załatwić skuteczniejsza implementacja. Jednak nadal będzie odowiazywać albo szybki watek albo duży przyrost wydajności

Właśnie jest to porównanie wydajnosci bd/k10.5 gdy dwa watki sa wykonywane na module bd a każdy z pojedynczych watków jest wykonywany na jednym, rdzeniu k10.5
Spójrzmy jeszcze raz na to
Retirement execution -> BD/K10.5 -> 4/3=133% single thread 2/3=66% with dual thread (per cycle)

Dla dwóch wątków AMD podaje 2/3 a dla jednego 4/3. Co przeczy twojej tezie z #151 W której twierdziłeś że dla dwóch wątków również będzie 4 dla buldozera.
Przy dwóch watkach buldozer ma 2!

@pawełpclab - tylko zważ, że pojedynczy rdzeń K10 NIE potrafii przetwarzać DWÓCH wątków naraz i jest to porównanie 1 wątek na K10.5 kontra 2 na BD - więc niby co za porównanie? No właśnie, żadne. Na AMDZone było teoretycznie 2 wątki - 2 jajka PhII kontra 1 moduł BD i źle nie wypadło. Jednowątkowe aplikacje? BD jest szybszy. Wielowątkowe aplikacje? BD jest nadal szybszy (biorąc pod uwagę że obecnie moduł zastępuje rdzeń czyli 1 moduł BD> 1 rdzen PhII). Zgoda czy nie?

Dua;l


dual threaded a nie dual core

Tak, moduł w BD kontra dwa rdzenie w K10.5. Dual threaded...jasne? No mam nadzieję... nie zaklinaj rzeczywistości bo ci nie wychodzi.

BD/K10.5

widać co przez co dzielimy?

I dlaczego dzielimy 2 przez 3

To dual threaded w K10.5 jest brane na 2 rdzenie. Teraz jasne?

Z tych danych chyba każdy z nas zdawał sobie sprawę. Mnie tam to żadnych wątpliwości nie rozwiało. Nadal je mam. Nadal uważam że wiele będzie zależeć od implementacji - czyli tego jak bardzo uda się zbliżyć do teoretycznej szczytowej wydajności.
A swoją drogą w tych materiałach co przytoczyłeś widać że markentingowcy AMD posługiwali sie kreatywnym liczeniem.

'Retirement execution -> BD/K10.5 -> 4/3=+33% single thread 2/3=-33% with dual thread (per cycle)'


Powinno być
Retirement execution -> BD/K10.5 -> 4/3=133% single thread 2/3=66% with dual thread (per cycle)

2*2/3 = 4/3 wiec co dają te dwa watki? jakby wykonać to sekwencyjnie czy przez podział czasu to też by było tak samo szybko. Tak jak opisałem wyżej.
No ale to jest wydajność peek. I pytanie brzmi jak bardzo typowa wydajność do peek się zbliży. Tu podali argument za tym że w single będzie szybciej. Tylko z tego co podali wynika że jak bąda dwa watki to efekt będzie taki sam jakby wykonać to w sekwencji na jednym rdzeniu wiec po co ten drugi rdzeń.

Wychodzisz z błędnego założenia, że tłumaczy 1:1...

Ja jestem bliższy alternatywie pierwszej, jednak i tak przyrost wydajności będzie zapewne większy niż przy zastosowaniu HT. Zauważ, że intel się chwali nawet 50% wzrostem wydajności po zastosowaniu HT - jednak takie sytuacje zdarzają się niezwykle rzadko i zazwyczaj jest to 20-30%. AMD pisało o 80%, więc pewnie realnie wzrost będzie wynosił 40-50%, a wydajnośc 2 wątków będzie niższa niż wydajność 2 rdzeni K10. Co by potwierdzały wstępne informacje o 8 modułowym 16 wątkowym bulldozerze, który ma być 50% szybszy od 12 rdzeniowego K10.5.

Nie są. To architektura van noymana wiec trzeba zawsze tłumaczyć. Tak do niczego nie dojdziemy.
Ja widze dwie alternatywy albo pokedynczy wątek będzie mocny wtedy przyrost wydajności w stosunku do maszyny dwuprocesorowej będzie kiepski.
Albo pojedynczy watek jest słaby wtedy przyrost wydajności będzie znaczny.
Trzeba poczekać na testy. Ciekawe kiedy się pojawią?

Paweł wracając jeszcze do bulldozera:



*Istanbul*

Pack Buffer(dispatching) -> deliver 3 Macro-ops cycle
* my take is that is a small buffer *

ROB -> 72 entry -> Retire 3 Macro-ops cycle

Integer Future File(RF) -> 44 entry
Integer Schedulers -> 3x8 entry -> 24 Entry

Integer Peak execution per core 3 MOPS (per cycle)

FP Register File -> 120 Entry
FP Schedulers -> 3x14 entry -> 42 Entry

FP Peak execution per core 3 MOPS (per cycle)

*Bulldozer*

Dispatch Group Buffers(2) -> deliver 4 Macro-ops per cycle and per core/thread

Retirement Queue(Reorder) -> 128 entry -> 64 entry/core
deliver -> 4 Macro-ops cycle

Integer Physical Register file (RF) -> 96 Entry
Integer scheduler -> 40 Entry

Integer Peak execution per core 4 MOPS (incl. speculative) (per cycle)

FP Physical Register file -> 160 Entry -> 80 entry/thread
FP Schedulers -> 60 Entry -> 30 entry/thread

FP Peak execution per core 4 MOPS (per cycle)


A teraz relacja BD do istambul.

Dispatching -> BD/K10.5 -> ??? (size)

Dispatch execution -> BD/K10.5 -> 4/3=+33% (per cycle) per buffer so its the same either in single thread or dual core/thread case.
sharing seems ok because there are much less bubbles because decode is o-o-o

Retirement Queue(Reorder) -> BD/K10.5 -> 128/72=+77% single thread 64/72=-11% with dual thread (size) (counting as a shared unit)

Retirement execution -> BD/K10.5 -> 4/3=+33% single thread 2/3=-33% with dual thread (per cycle)

--- core ---
Integer Register File -> BD/K10.5 -> 96/44=+118% per thread but if 1/2 is a 'speculative Register file' (dual RF)... but 90% of execution is correct then is 91.2/44=+107% EFFECTIVE per core (size)

Integer scheduler -> BD/K10.5 -> 40/24=+66% per thread and meaning if 1/2 is for 'speculative execution' but 90% of execution is correct then 38/24=+58.3% EFFECTIVE per core (size)

Integer Peak execution per core -> BD/K10.5 -> 4/3=+33% per thread but if 1/2 is 'speculative execution' but 90% is correct then 3.8/3=+26% EFFECTIVE (per cycle)
--- core ---

FP Physical Register file BD/K10.5 -> SINGLE THREAD 160/120=+33% but if 1/2 is a 'speculative Register file' (dual RF)... but 90% execution is correct then 152/120=+26% EFFECTIVE (size)...
DUAL THREAD SHARING 80/120=-33% but if 1/2 is a 'speculative Register file' (dual RF)... but 90% execution is correct then 76/120=-36% EFFECTIVE (size)...

FP scheduler -> BD/K10.5 -> SINGLE THREAD 40/24=+66% but if 1/2 is for 'speculative execution' but 90% of execution is correct then 38/24=+58% EFFECTIVE (size)...
DUAL THREAD SHARING 20/24=-16% but if 1/2 is for 'speculative execution' but 90% of execution is correct then 19/24=-20% EFFECTIVE (size)

FP Peak execution -> BD/K10.5 -> SINGLE THREAD 4/3=+33% but if 1/2 is 'speculative execution' but 90% is correct then 3.8/3=+26% EFFECTIVE (per cycle)...
DUAL THREAD SHARING 2/3=-33% but if 1/2 is 'speculative execution' but 90% is correct then 1.9/3=-36% EFFECTIVE (per cycle)


Podsumowując jeden wątek Bulldozera (wszystko dla 4Mops)

Dispatching buffer -> ?? (size)
Dispatch execution -> +33% (per cycle)
Retirement Queue(Reorder) -> +77% single core (size)
Retirement execution -> +33% single thread (per cycle)


Integer Register File -> +118% -> +107% EFFECTIVE(sp) (size)
Integer scheduler -> +66% -> +58.3% EFFECTIVE(sp) (size)
Integer Peak execution -> +33% -> '+26%' EFFECTIVE(sp) (per cycle)


FP Register file -> +33% -> +26% EFFECTIVE(sp) (size)
FP scheduler -> +66% -> +58% EFFECTIVE(sp) (size)
FP Peak execution -> +33% -> +26% EFFECTIVE(sp) (per cycle)


mam nadzieję, ze co nieco wątpliwości rozwiało.

Są w stanie, po to jest tablica z instrukcjami, reordering buffer itp. itd. Dekoder tylko tłumaczy, dalej jest już tylko trudniej.