Po pierwsze nie sposób stwierdzić czy przypadki gdzie trzy jednostki phenoma działają jako alu występują i jak są częste. By to stwierdzić trzeba by wiedzieć jak działa scheduler instrukcji w phenomie.
AMD twierdzi że w phenomie możliwości AGU do trzeciej jednostki przetwarzajacej dodano tylko dla zachowania symetryczności i ze w sumie te możliwosci nie były niezbędne. Na tej podstawie można stwierdzić że nie były potrzebne 3 jednostki
AGU, ale nie można stwierdzić niczego o wykorzystaniu ALU.
Wspominałeś o core który ma 3 ALU. Skoro są w nim trzy to można przypuszczać ze jest ich tyle w jakimś celu, czyli że w core scheduler potrafi wykorzystać 3 ALU.
Póki co to nie pisałem że w pojedynczym wątku buldozer będzie wolniejszy od phenoma. Pisałem że w opisie architektury są przesłanki za tym ze będzie on szybszy jak i za tym że będzie on wolniejszy.
Isntotne jest natomiast to ze AMD ma w module dwa rdzenie podłączone do 4 droznego dekodera - bo świadczy to o tym ze pojedynczy rdzeń nie jest w stanie zawsze wykorzystać 4 instrukcji dostarczanych przez dekoder. Przyczyną tego niewykorzystanie może być 'kiepski' scheduler, lub brak jednej jednostki ALU obecnej w phenomie.
Gdyby pojedynczy rdzeń był w stanie skonsumować wszystkie instrukcje dostarczane przez dekoder to dokładanie drugiego rdzenia kosztującego 12% powierzchni było by bez sensu, bo jeden wątek konsumował by wszystkie instrukcje dostarczane przez dekoder a do drugiego wątku instrukcje trafiały by sporadycznie.
AMD twierdzi ze ich podejście daje 80% wydajności systemu dwuprocesorowego przy 12% zwiększeniu modułu. Znaczy się że do tego drugiego wątku musi trafiać całkiem sporo instrukcji skoro spodziewają się takiego wzrostu. A skoro te instrukcje są wykonywane przez drugi rdzeń, dekoder dostarcza 4 instrukcje, to wniosek jest taki ze pojedynczy rdzeń jest słaby.
Jak pojedynczy watek buldozera będzie silny to nie ma szans na tak znaczny wzrost wydajności przy dwóch rdzeniach, tyle że wtedy trochę bez sensu jest mieć dwa rdzenie. Albo pojedynczy watek buldozera jest słaby wtedy można spodziewać sie znacznego wzrostu i podwójne rdzenie maja sens.

pawełpclab
http://upload.wikimedia.org/wikipedia/comm...ldozer_6751.jpg
Są 2 (osobne i niezależne) schedulery int do obu rdzeni w module. Jeden dzielony sheduler do FP. Mam nadzieję, że rozwija to wszelkie wątpliwości.

No tak sa dwa oddzielne schedulery int każdy z nich jest czterodrożny. I te dwa czterodrożne schedulery są 'zasilane' przez jeden cterodrozny dekoder instrukcji.

@pawełpclab - no to się zdecyduj czy piszesz o schedulerze czy dekoderze. Dobrze... teraz porównaj wykonywanie 2 wątków na 1 rdzeniu intela i na jednym module bulldozer.

Pisze i o schedulerze i o dekoderze.
Fetch > decode > execute > store - ogólny potok wykonawczy.
Jak widać decoder produkuje instrukcje których wykonaniem zarządza scheduler.

Moim zdaniem znacznie bardziej wartościowe jest porównać wykonanie pojedynczego wątku na module buldozera z wykonaniem na tym samym module dwóch wątków. I uzasadnić co daje dodatkowy rdzeń

Promilus część wątpliwości już wyjaśnił.

A co do wykorzystania alu/agu w phenomie, to moja wypowiedź opierała sie o wypowiedz człowieka z AMD na forum amd zone.

Jesli uważasz ze promilus cokolwiek wyjaśnił to również powinieneś rozważyć przypadek wykonania na module buldozera dwóch wątków i porównać to z wykonywaniem na tym samym module jednego wątku. A potem wskazać jakie korzyści/straty to przynosi.

To rzeczywiście dziwna sytuacja. Przedstawiciele AMD twierdzą że w phenomie II nie był im potrzebny trzeci ALU. Twierdzą również ze trzecie AGU tez im potrzebne nie było. Dziwne. Bardzo dziwne.

pawełpclab - intel w Nehalemie nie ma super rozbudowanego dekodera, nie ma powielonych potoków wykonawczych, a mimo to przy owych 2 wątkach od kilkunastu do nawet 30% wydajność idzie w górę. Dekoder się wyrabia? Wyrabia. To nie wiem czemu nie potrafisz przyjąć do wiadomości, że ten u AMD też się wyrobi.

Nie bardzo dziwne, tylko jak są potrzebne 2 AGU, to sa 2 AGU (zostaje wtedy jedno ALU), gdy sytuacja jest odwrotna, to mamy 2 ALU i zostaje jedno AGU. Taka koncepcja powstała już w K7 i od tamtego czasu jej się trzymali. Teraz masz 2 dedykowane ALU i 2 dedykowane AGU i 4ro drożny dekoder. Owszem, mogą być sytuacje, gdzie bulldozer nie będzie wiele szybszy od phenoma, ale będą też takie w których wyprzedzi go o kilkanaście, a zapewne jeszcze więcej kiedy potrzebna będzie duża wydajność FPU. Samo AMD przyznało, że bulldozer będzie szybszy od K10 w przypadku użycia jednego wątku i nie widzę przeciwwskazań do tego, aby im nie wierzyć.

Te 30% jest w górę dlatego że dekoder się wyrabia mógłby dostarczać cały czas stałą liczbę instrukcji w takcie - 4, jednak w przypadku jednego wątku scheduler nie jest w stanie tak przyporządkować tych instrukcji by w 100% wykorzystać dostępne jednostki przetwarzające. Dodanie drugiego wątku daje schedulerowi większe pole manewru i dzięki temu może bardziej wykorzystać dostępne jednostki przetwarzające.
Podobnie scheduler buldozera nie będzie w stanie wykorzystać wszystkich jednostek przetwarzających.
Gdyby było inaczej - czyli że scheduler rdzenia buldozera wykorzystuje zawsze 4 dostępne jednostki to okazuje się że mając dwa wątki do wykonania dajmy na to każdy po 2mln instrukcji. Wykonanie ich na jednym rdzeniu w sposób sekwencyjny, czy z podziałem czasu zajmie 1mln taktów zegara.
Wykonanie tych dwóch wątków na dwóch rdzeniach modułu również zajmie 1mln taktów zegara - bo dekoder na dostarczenie w sumie 4 milionów instrukcji obu wątków potrzebuje właśnie 1mln taktów.
Czyli moduł dwurdzeniowy byłby tak samo szybki jak jednordzeniowy. Byłby większy o 12%. Zużywał więcej energii. Przyrost wydajności w stosunku do maszyny dwuprocesorowej wynosiłby 0%.
W buldozerze są dwa rdzenie dlatego ze schedulery nie są w stanie przydzielić do wykonania 4 instrukcji w takcie.
A skoro rdzenie buldozera nie są wykorzystywane w 100% to pojedynczy watek nie jest zbyt mocny.

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

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.

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ą?

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.

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

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ń.

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

BD/K10.5

widać co przez co dzielimy?

I dlaczego dzielimy 2 przez 3

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

Dua;l


dual threaded a nie dual core