Konstruujemy mega wydajny procesor.

[pavel54 0]

Tamci kolesie z chip-architect to dopiero wymiatają. Zaglądają w głąb rdzenia i mówią co ma i jakie są zmiany w stosunku do starszego rdzenia.

[voytass84 0]

.

[sideband 9448]

ani intel i amd za dużo nie zmieniają , będą się pojawiać procesory z coraz większą ilością rdzeni i tyle , najłatwiejszy sposób aby zwiększyć wydajność

[voytass84 0]

.

[sideband 9448]

po cześci to integrowanie (kontrolera pamięci , pci-express ) jest ok , obniża opóżnienia czyli zatem wzrost wydajności , obniży koszt płyt głównych , ale z oc może być gorzej

[Satyavan 0]

LOOOO takiej wiedzy o komputerze to chyba nigdy nie posiąde, ani za mojego życia ani za innego

[Storm 0]

zaczalem sie martwic czy sie na studia dostane

[krecik177 0]

Obecnie w procesorach x86 dotępnych na rynku stosowane są trzy, różniące się od siebie architektury

(...)

PEŁNE UZNANIE !!! JESTEM POD WRAŻENIEM TWOICH WIADOMOŚCI !!!

 

I nie krzycz tak.

[Shark19 0]

Dlatego trochę trudno uwieżyć, że po dodaniu tylu elementów z architektury Intela, który bądź co bądź nie grzeszy wydajnością w przeliczeniu na taktowanie (Net Burst), stworzy się procesor o niemonstrualnym skomplikowaniu i zapotrzebowaniu na energię, który połączy najlepsze cechy tych dwóch konkurentów. Niektóre ścieżki AMD wykluczają rozwiązania Intela i vice versa. Ale oby inżynierowie nie próżnowali (dla naszego dobra).

Tak, całkowicie się z tym zgadzam dlatego wcześniej pisałem

 

Jest to wiec Kupa rozwiązań, w 3 różnych architekturach. Gdyby tak połączyć je logicznie i z sensem dodając jeszcze jakieś unowocześnienia, wyszedł by niezły procesor.

Oczywiście nie można przesadzic, bo wyszedłby procesor, którego jeden rdzeń składa się z 300 mln tranzystorów i jest jeszcze gorętszy od Prescotta.

 

 

Swoje twierdzenia opieram na fakcie zmain jakie dodano przechodząc z Tualatina do Baniasa.

Wtedy zmieniono wiele a ilość tranzystorów składających się na sam rdzeń bez cache L2 wzrosła z niecałych 11mln do prawie 16 mln, czyli o jakieś 45 %.

 

Przypomne że dodano Trace Cache, łączenie mikroinstrukji w paczki po 2-3 tzw. makroinstrukjce ( podobnie jak w VLIV w procesorach AMD ) oraz dowolne przekolejkowanie i przenoszenie instrukcji pomiędzy jednostkami wykonawczymi ( całość składa się na technologię MicroOp Fusion ), menedżer stosu, usprawniono układy predykcji rozgałęzień tak że były one jeszcze dokładniejsze niż w Northwoodzie ( ale nie aż tak jak w Prescottcie ), oraz poprawiono prefetching stosując rozwiązania znane jako układy pobrań wyprzedzających w Pentium 4.

 

Zmiany te dały około 25-30% wzrost wydajności względem Tualatina.

 

Następnie w Dothanie, względem Baniasa przybyło ( nie licząc cache L2 ) jeszcze około 1,4 mln tranzystorów - które sporzytkowano na zwiększenie przewidywania i dokładności predykcji rozgałęzień, umożliwienie dokonywania predykcji z wyprzedzeniem, oraz usprawnienie pobrań wyprzedzających ( układy predykcji Dothana są praktycznie identyczne jak w Prescottcie ), zwłaszcza instrukcji o zmiennej długości.

 

Te zmiany dały 5-10 % więcej wydajności w stosunku do Baniasa.

 

______________________________

 

Rdzeń Athlona 64 bez cache L2 to około 42 mln tranzystorów. Dajmy na to że po wprowadzeniu podobnych zmian jak w Baniasie i Dothanie ich liczba zwiększyła by się do 65 mln, a wydzielane ciepło całego układu wzrosło by o 50 %

 

Czyli przy 2.4 Ghz Venice po takich zmiananch zamiast 50 W pobierał by około 75 W, ( co zresztą całkowicie zniwelowała by techmologia 65 nm ).

Pewnie zadasz pytanie, dlaczego nie tyle co Prescoot, skoro rdzeń Prescotta bez cache L2 składający się z około 73 mln tranzystorów ( czyli niewiele więcej niż Athlon po omawianej przeróbce ), przy taktowaniu 2.4 GHz pobiera około 100 W energi. A dlatego że AMD stosuje technologię SOI która zmiejsza wydzielanie ciepła o 30 %.

 

------------------------------------------

 

Implementacja Trace Cache w takiej formie jak w Pentium M ( bez skomplikowanych systemów kolejkujących instrukcje jak w Pentium 4 ) nie wymaga praktycznie zwiększenia ilości tranzystorów, bowiem jest to tylko przeniesienie cache instrukcji w potoku logicznym z przed dekodera za dekoder.

 

Zysk z Trace Cache łatwo jest oszacować. Trace cache przyśpiesza wykonywanie kodu po wykonaniu instrukcji skoku lub warunkowej i podczas wykonywania instrukcji powtarzających się, gdyż nie trzeba ponownie dekodować instrukcji przeznaczonych do wykonania bo znajdują się już one przedekodowane w Trace Cache - więc pomijane są fazy potoku do dekodowania włącznie, których w architekturze K8 jest siedem.

 

Instrukcje skoku i warunkowe stanowią przeciętnie około 15 % wszystkich instrukcji w programie, do tego dochodzą instrukcje powtarzające się po sobie.

Załóżmy więc że w przypadku 20 % wszystkich instrukcji, procesor będzie zyskiwać na Trace Cache.

Całkowity potok K8 ma 12-17 faz, zależnie od typu instrukcji ( 12 faz dla stało-przecinkowych, i od 14 do 17 faz dla zmienno-przecinkowych ).

Zakładm, że średno daje to długość 14 faz.

W średno co piątej instrukcji potok efektywnie skracany będzie o połowę, co daje średnio 10% zysku wydajności, a zakładając ze w kodzie nie będzie powtarzających się instrukcji - 7,5 %.

 

No i nie prawda że rozwiązanie proste, niewymaga praktycznie zwiększania ilości tranzystorów, a daje niezłego kopa ?

 

Pozatym w PentiumM nie jest skracane aż pół potoku wykonawczego, więc zysk z Trace Cache w Athlonie byłby większy względem zysku jaki to rozwiązanie daje w Pentium-M ( tam jest to min 6 %, w Athlonie jak widać było by to 7.5 % ).

 

PS. Nie rozumiem Intela, który w Prescottcie zamiast powiększyć Trace cache z 16 do 32k uOps, zastosował komplikujące i ogromnie rozbudowujące procesor systemy przewidywania po to, by w mniejszym Trace Cache zmieścić tylko to co potrzeba procesorowi.

 

 

Idziemy dalej, menedżer stosu według Intela zwiększa wydajnośc ogólną Pentium M o 2-5 % zależnie od aplikacji, a nie wymaga milionów tranzystorów, ani nawet setek tysięcy.

Dwa proste rozwiązania dające 10-15 % więcej wydajności, zwiększające ilość tranzystorów minimalnie.

 

 

Teraz pora na zastosowanie Micro-op Fusion. Jako że łączenie mikroinstrukcji w makroinstrukcje jest juz w procesorach AMD realizowane ( poprzez technike VLIW ), pozostaje tylko dać możliwość dowolnego przekolejkowania i przenoszenia instrukcji pomiedzy jednostkami wykonawczymi Athlona.

Jako że Athlon ma 6 równoległych potoków, i 6 jednostek wykonawczych, sądze że zysk wydajności z tego rozwiązania będzie w Athlonie większy niż w Pentium-M, adekwatnie do stosunku ilości potoków i jednostek wykonawczych Athlona i Pentium-M, czyli o mniej więcej 50 %.

 

Ale według mnie będzie on jeszcze większy niż wskazuje na to stosunek ilości potoków Athlona i Pentium-M :

Jak zapewnie wiesz z dekodera instrukcje wychodzą jedna po drugiej, czyli szeregowo. Nastepne poddawane są one analizie po której zmieniana jest ich kojelność wykonywania tak, aby dawały wykonywać sie równolegle w kilku potokach procesora.

Jednak po takiej optymalizacji nie zawsze są one wykonywane po 6 naraz w każdym potoku Athlona, gdyż trudno szeregowy ciąg instrukcji rozłozyć na 6 równoległych ciągów przeznaczonych z osobna dla każdego potoku. Zwykle w jednym takcie zegara wykonane są 2, 3 lub 4 instrukcje, a przypadek w którym jednocześnie wykonywane jest 6 instrukcji we wszystkich 6 potokach jest stosunkowo rzadki. Z tego powodu procesor 6 potokowy nie jest wydajniejszy od 4 potokowego o 50 % ( jak to jest w kartach graficznych ), a o około kilakanście %

 

Dowlne przekolejkowanie i przenoszenie instrukcji w potokach zwiększy jeszcze bardziej wykorzystanie, nazwijmy to - 5 i 6 potoku Athlona ( których w Pentium-M nie ma ), czyli cały zysk z zastosowania tego rozwiązania w Athlonie powinien być większy prawie dwukrotnie ( jak nie więcej ) niż zysk jaki dało to rozwiązanie w 4 potokowym Penium-M.

 

Implementacja systemów predykcji rozgałęzień i przewidywania podobnych jak w Prescottcie, w Athlonie również da większy zysk wydajności niż w Pentium-M, nie tylko z powodu większej ilości potoków Athlona, ale też z powodu słabej skuteczności tych systemów w obecnym Athlonie - nawet słabszej niz w Pentium III Tualatin.

Do tego dochodzą jeszcze pobrania wyprzedzające, które Athlon będzie również wykorzystywał częściej, i zysk z ich również będzie większy niż w Pentium-M

 

Więc rozwiązania które zaimplementowane w Pentium-M ( Dothan va Tualatin )zwiększyły wydajność o około 35%, w Athlonie dałbyby wzrost wydajności rzędu 50 % jeżeli nie więcej.

 

Dotego dochodzi jeszcze umożliwienie jednostkom ALU wykonywania operacji mnożenia liczb stałoprzecinkowych, i znowu, conajmniej kilka % więcej wydajności.

 

PS. Ciesze się że jest ktoś z kim moge rzeczowo pogadać na ten temat.

[Akira 0]

Tak jak mówił Shark19 potrzeba właśnie czegoś długofalowego. Chyba, że wszyscy nagle by się przenieśli na Linuksa co nie byłoby złym rozwiązaniem

Ja sie przeniosłem na Linuksa jakieś 2 lata temu na dobre. Teraz by się przydało by "inni" sie poprzenosili, co by dało nowego kopa rozwojowi tego systemu. System jest czasem przyjemny, czasem wkurzający, doskwiera wyraznie brak normalnych gier komercyjnych (moze xbox360 lub ps3 jakos tą niedogodność raz na zawsze u mnie zniosą ) - wiecej osób kozystających z linuksa to w kazdym razie wieksze zainteresowanie tym systemem producentów oprogramowania i tym samym "lepszy linux" w ogólności. W każdym razie rozwazane przez was łaczenie rdzeni w żaden sposób nie poprawi tu sytuacji, a samo przejscie na risc byle tylko przejsc i dalej jechac na windowsach to w sumie chyba nie jest warte wysilku.

[rob62 0]

Shark19, wielkie gratulacje za cierpliwosc w zbieraniu tych informacji i szkolenia sie w dziedzinie procesorow. tez jest pelen podziwu dla ciebie. Ale tak logicznie myslac , ci inzynierowie co pracuja w AMD i Intel, niektory od parunastu latach zajmuja sie procami i maja cala ich ewolucje i te problemy co poruszyles w jednym palcu ( dlatego boira za ta gruba forse ) wiec napewno znaja ich niedoskonalosci i jakby mogli to by juz dawno to poprawili. Twoja wiedza jest w calosci teoretyczna, ale moze istnieja inne problemy ktore uniemozliwyly zastosowanie np. trace cache w AMD. Wielu ludzi sie nad tym glowilo i napewno dluzej od Ciebie. No ale zawsze istnieja szanse ze nie pomysleli o paru rzeczach ktrore ty poruszyles, no ale malo jest na to szans. Moze za pare lat sie przekonamy czy miales racje

[Mavedyx 0]

Tak nagle z dnia na dzień nie przepiszą wszystkich aplikacji i na inny kod.

To jak by z tym było w końcu, musieliby pisać programy od początku czy wystarczy skompilować na nowo kod źródłowy?

[Darth Stasheck 0]

Shark1, szakunec - rzadko się zdarza, że mogę z kimś na polskiej sieci pogadać na takie tematy

 

A poza tym witam wszystkich

 

Ale do rzeczy - pozwolę sobie kilka elementów skorygować.

 

Co do podwójnie taktowanego ALU w Netburst

- według mojej wiedzy, właśnie dopiero w Prescotcie zrobiono "dopalane" ALU - co więcej, to ALU wykonuje tylko jeden rodzaj operacji, mianowicie dodawania - okazuje się bowiem, że właśnie ta operacja jest najczęstszą operacją AL w kodzie x86. W swoim "procesorze marzeń" kombinujesz dobrze, tylko w trochę innym kierunku

 

Architektura K8 może jest rewolucyjna, ale tylko w światku x86 - K8 można nazwać popłuczynami po procesorze DEC Alpha 21464.

 

x86 nigdy, od samego początku nie było architekturą nowoczesną. Forma kodu - w któym rozkaz może mieć 1 bajt, a może mieć ich grubo ponad 10 - została podyktowana oszczędnością pamięcie w stosunku do kodu RISC. Średnia długość rozkazu w x86 to, jeśli dobrze pamiętam (a jeśli źle to mnie poprawcie) trochę ponad 2 bajty - w jednym z lepszych procesorów RISC-owych, Power, długość rozkazu jest stała i wynosi 4 bajty (32 bity). Format jest taki, że dekoder rozkazów jest w stanie zmielić rozkaz w 1 cyklu, podczas gdy dekoder PIV wymaga 3 albo 4 cykli (też do poprawienia, jeśli się mylę - nie mam czasu w tej chwili tego szukać).

 

 

I nie wiem czy zauważyliście, ale wg mnie główny problem architektury x86 (czy może polityki w stosunku do tej architektury) polega na tym, że optymalizację kodu stara się przeprowadzić hardware'owo po tym, jak ten kod już został nieefektywnie skompilowany. Przecież większość tych rzeczy - a układanie instrukcji w optymalnej kolejności - da się zrobić podczas kompilacji programu. Komuś nie chce się pisać dobrych kompilatorów?

 

Gdzieś znalazłem takie zdanie, że przemysł sprzętowy rozwijał przez ostatnie 15 lat coraz bardziej zaawansowane konstrukcje, podczas gdy przemysł software'owy... No, w kolejnym Windowsie dostaniemy ładniejsze okienka.

Tak naprawdę w przemyśle softowym jest masa nowych, dobrych pomysłów - tylko po co je stosować, skoro sprzętowcy zrobią mocniejszy sprzęt, który "zje" problemy mocą obliczeniową?

 

Myślę, że wydajność kompów możnaby potężnie zwiększyć samym softem, bez potrzeby wymyślania coraz bardziej finezyjnych rozwiązań sprzętowych.

[Bono[UG] 1920]

Windows NT chyba 4, był na x86 oraz na procesory Alfa (Alpha?).

Moim zdaniem wystarczy przekompilować kod odpowiednim kompilatorem. Co prawda istnieje problem przepisania bibliotek na nowy procesor zachowując zgodność interfejsu, ale kod programu/systemu w zasadzie nie trzeba zmieniać.

[Shark19 0]

Co do podwójnie taktowanego ALU w Netburst

- według mojej wiedzy, właśnie dopiero w Prescotcie zrobiono "dopalane" ALU -

Masz chyba błędne informacje.

 

Nie będe powtarzał że jest tak jak ja twierdzę, bo mi powiesz ze to ja mam błędne informacje, a tylko udowodnię że jest tak jak mówie:

 

Powierzchnia krzemowa procesora nigdy nie nagrzewa się równomiernie, są obszary chłodniejsze ( np. cache ) i gorące ( np ALU ).

Mimo że czujniki pokazują np. że procesor ma 60 stopni, jakiś fragment jego rdzenia może wówczas nie mieć nawet 50 stopni, a równoczesnie inny fragment rdzenia będzie miał ponad 90 stopni.

Krzem ulega trwałemu fizycznemu uszkodzeniu przy około 140 stopniach celsjusza.

 

Słyszałeś o syndromie nagłej śmierci mocno podkręcanych Northwoodów ?? Działały, ale po którymś tam wyłączeniu kompa proc juz się nie budził.

 

A to dlatego że w Northwoodzie ALU taktowane było z dwukrotnym zegarem częstotliwości CPU, i ostro podkręcane Northwoody, padały z przegrzania się podwójnie taktowanych ALU.

 

Gdyby Prescooty, które grzeją się bardziej od Northwooda, i nieraz pracują w temperaturach dochodzących do 90 stopni ( w nawet ostro podkręcanych Northwoodach było góra 70stopni ), miały ALU taktowane podwójną częstotliwością CPU, padały by jak muchy.

 

Prescoot właśnie dlatego jest tak odporny na wysokie temperatury bo nie ma podwójnie taktowanych ALU, i dodatkowo wszytskie najbardziej grzejące elementy w miare równomiernie rozłożono w rdzeniu.

 

 

 

co więcej, to ALU wykonuje tylko jeden rodzaj operacji, mianowicie dodawania - okazuje się bowiem, że właśnie ta operacja jest najczęstszą operacją AL w kodzie x86.

No tak było we wszystkich procesorach do czasu Prescoota, bo tylko dodawanie mogły wykonywać ALU wcześniejszych konstrukcyjnie procesorów.

 

Jednak ALU dostawały tez do wykonania inne instrukcje, np. mnożenia liczb stało-przecinkowych, które nie były z braku takiej możliwości wykonywane przez ALU, a odsyłane do FPU do wykonania.

To było sporym ograniczeniem i wiązało się ze stratą wydajności, bo oznaczało wstrzymanie potoku stałoprzecinkowego w którym wystąpiła taka instrukcja, do czasu nadejścia wyniku z FPU.

 

Najnowszym trendem w mikroprocesorach jest umożliwianie ALU wykonywania operacji mnożenia liczb stałoprzecinkowych

 

 

 

W swoim "procesorze marzeń" kombinujesz dobrze, tylko w trochę innym kierunku

To co opisywałem to nie jest mój procesor marzeń.

 

Opisałem tylko jak "na szybko", przy zastosowaniu obecnych rozwiązań technologicznych można by skonstruować wydajny procesor który jednocześnie nie byłby takim 300 watowym Tejasem ( Tejas - nastepca Prescoota, z ktorego zrezygnowano ze względu na ogromne skomplikowanie i rozbudowanie układu i dwukrotnie większe zapotrzebowanie na energię niż w przypadku Prescoota )

 

Jak pewnie czytałes opierało się to na modernizacji Athlona 64, z którego można wyciągnąć sporo więcej wydajności niż te procesory mają obecnie.

 

 

Nie sądze że to jest właściwy kierunek w dłuższej mierze, to jest tylko rozwiązanie na chwile obecną pozwalające stworzyć najwydajniejszy procesor, i jednocześnie wprowadzając go trzeba by już myśleć na innym który pojawił by się za 3-4 lata i podążył już w innym kierunku niż rozbudowa wszystkich systemów optymalizacji kodu po nieefektywnym skompilowaniu ( bo to droga prowadząca do 300w Tejasa )

 

 

Co do właściwego kierunku w jakim powinny pójść procesory przeczytasz o tym poniżej ( o nowym dekoderze instrukcji ). Bo właśnie nowy dekoder uważam za właściwy kierunek.

 

 

 

wg mnie główny problem architektury x86 (czy może polityki w stosunku do tej architektury) polega na tym, że optymalizację kodu stara się przeprowadzić hardware'owo po tym, jak ten kod już został nieefektywnie skompilowany. Przecież większość tych rzeczy - a układanie instrukcji w optymalnej kolejności - da się zrobić podczas kompilacji programu. Komuś nie chce się pisać dobrych kompilatorów?

 

No dokładnie, mam takie samo zdanie w tej kwestii, jednak sądze że można by go rozwiązać inaczej

 

Największą niedoskonałością obecnych procesorów jest dekoder instrukcji, który przerabia kod x-86 na ciąg instrukcji niesamowicie trudny do równoległego wykonywania w kilku równoległych potokach procesora.

 

I właśnie tutaj jest najwięcej do poprawienia - potrzebny jest dekoder który przekodowywywał by instrukcje x-86 równoczesnie przekolejkowując je na kilka równoległych ciągów niekolidujących ze sobą.

Pozwoliło by to pozbyć się wielu uciązliwych i komplikującyuch procesory elementów jak systemy przewidywania i predykcji rozgałęzień programu - oba odgałęzienia były by wykonywane równolegle w dwóch potokach do czasu sprawdzenia warunku, a niepotrzebne i błędne odgałęzienie było by poprostu pomijane.

Taki dekoder, pozwolił by zmienić architekture procesorów na bardziej RISCową bez zbędnych komplikacji tak jak to jest w obecnych CPU ( predykcja rozgałęzień )

 

Do tego dekoder ten mógłby obsługiwać też pełnego RISCa i migracja od x-86 była by bezproblemowa, tak jak migracja do 64 bitów w prockach x-64-64 ( AMD64 i Intel Yamhill czyli EMT64 ).

 

Więcej o tym w poście nr. 8 w tym temacie.

 

 

I właśnie właściwym kierunkiem rozwoju procesorów w dłuższej mierze czasowej uważam takie rozwiązanie dekodera instrukcji.

 

 

PS. Ciesze się że znlazła się kolejna osoba z któą moge rzeczowo porozmawiać.

 

Pozdrawiam

[tomek_el 0]

Shark - milo ze na pclabie zostalo jeszcze kilka osob, ktore sie na prawde znaja an sprzecie . Wiesz moze cos o nastepcach pentium? Intel zapowiedzial, ze beda oparte na architekturze pentium m, dostana tez wiecej cashu i wyzsze taktowania. Ciekawe tylko dlaczego Intel nie probuje zintegorwac kontrolera pamieci jak AMD? Przeciez to rozwiazanie wplynelo by znacznie na wydajnosc. Ciekawe kto wygra w nowej oslonie - core duo desktop czy Athlony pod socket m? Bo w sumie te nowe desktopowe proce intela oprocz kontrolera pamieci beda mialy wiekszosc najwydajniejszych rozwiazan jakie sa obecnie na rynku.

P.

[wtpdude 0]

http://www.xbitlabs.com/news/cpu/display/20060212234350.html

pozdr

[tomek_el 0]

http://www.xbitlabs.com/news/cpu/display/20060212234350.html

pozdr

Jesli ten EE bedzie mial faktycznie 3.3 ghz to powinien zmiesc AMD, chyba ze AMD tez granice 3ghz przekroczy. Przepustowosc pamieci bedzie pewnie zblizona, skoro A64 z kontrolerem przy taktowaniu ramu 400mhz ma taka wydajnosc jak P4 przy 1066 mhz magistrali - wiec zmiana magistrali na 600mhz w M2 i na 1333mhz w nowych procach intela zachowa proporcje.

P.

[MajaP83 0]

Nowe ploteczki z inquirera. (ostatnio to im sie wszystko zgadza).

 

http://theinquirer.net/?article=29716

 

Athlony na M2 z obsluga 800MHz pamieci DDR2. Heh to sie niezle zapowiada

[victor89 0]

zwaliło mnie z nóg

 

genialny materiał o procesorach i architekturach

 

Osobiście nie miałbym nic przeciwko, gdyby procesor grzał się troszke mocniej, jednak musiałby posiadać niesamowitą wydajność.

[Shark19 0]

Shark - milo ze na pclabie zostalo jeszcze kilka osob, ktore sie na prawde znaja an sprzecie . Wiesz moze cos o nastepcach pentium? Intel zapowiedzial, ze beda oparte na architekturze pentium m, dostana tez wiecej cashu i wyzsze taktowania. Ciekawe tylko dlaczego Intel nie probuje zintegorwac kontrolera pamieci jak AMD? Przeciez to rozwiazanie wplynelo by znacznie na wydajnosc. Ciekawe kto wygra w nowej oslonie - core duo desktop czy Athlony pod socket m? Bo w sumie te nowe desktopowe proce intela oprocz kontrolera pamieci beda mialy wiekszosc najwydajniejszych rozwiazan jakie sa obecnie na rynku.

P.

Conroe opiera się na mobilnym Yonachu. Jest jednak innym procesorem, o nieco zmienionej architekturze.

 

Po pierwsze - będzie 64 bitowy. Po drugie, będzie mial dłuższy potok wykonawczy 14 zamiast 12 faz potoku.

 

Co do zmian w samej architeturze wpływających na wzrost wydajności, Conroe ma mieć głębsze buforowanie ( dłuższy globalny licznik odwołań, większe bufory TLB dla cache, itp ), oraz jeszcze lepsze niż w Prescottcie systemy pobierania danych z wyprzedzeniem.

 

Jeżeli zmiany będą takie jak narazie wiadomo, to sadze że wydajnośc będzie kilka % większa niż w obecnym Pentium-M 0,065 mikrona, i do tego Conroe będzie mogło osiągać kilknaście % większe taktowanie ( ze względu na dłuższy potok wykonawczy ).

Chyba że Intel coś trzyma w tajemnicy.

 

 

 

Co do Athlona na Socket AM2, jest wilece prawdopodobne że będą to zupełnie nowe układy oparte o nową architekturę AMD K-9.

 

----> W maju 2005 w sieci pojawiły się newsy że nowej architektury AMD- K9 możemy spodziewać się za około 12-18 miesięcy.

 

----> Firma MSI niedawno pokazała płyte pod Socket AM2.

Płyta nazywa się K9N platinum - co wskazuje na kolejną generację procesorów - AMD K9

 

----> Prace na nową generacją ( K-9 ) zostały zapoczątkowane w sierpniu 2002 roku, a więc 3,5 roku temu.

 

----> Prace nad K-8 trwały 2,5 roku ( początek 1999 - 3 kwartał 2001 ),

 

Czyli AMD miało sporo czasu, więcej niż przedtem podczas opracowwyania K8, na opracowanie nowej architektury

Zwłaszcza, że w Athlonie 64 nie wykorzystano wielu rozwiązań opracowanych już podczas porojektowania K-8, i czekały one gotowe na zastosowanie w następnej generacji procesorów.

 

Więc architektura K-9 mogła już dawno powstać i czeka gotowa na podbój świata.

 

----> Nowe procki Orleans ( single core ) i Windstor ( dual core ) mają zaimplementowaną sprzętową technologię wirtualizacji ( pacifica wirtualization ), a ta z koleii, jako podstawe swojego działania wykorzystuje wspołbierzną wielowątkowość ( hyper-threading ).

Wniosek : musi być HT

 

----> Niedawno ( news był kilka dni temu ) SIS zaprezentował chipsety pod Socket AM2. Wśród obsługiwanych technologi, oprócz Hyper-Transport Technology, widniała technologia Hyper-Streaming Technology. Coż za zbierzność nazywy z Hyper Transportem.

Hyper Streaming musi być więc jakąś nową technologią AMD K9

 

----> Przechodząc z K7 na K8, dokonano tylko ulepszeń w architekturze nie powodujących znacznej ingerencji w układ.

Zrewolucjonizowano natomiast całe otoczenie układu, implementujac kontroler pamięci, magistralę HTT, cross-barr switch i system request interface.

 

Naturalnym rozwinięcem k8, będzie wiec pozostawienie całęgo otoczenia procesora jak w K8, a za to znacznie zmiany w architekturze wewnętrznej ( potokach wykonawczych )

Na brak większych zmian w otoczeniu procesora wskazuje prawie identyczna podstawka, natomiast na zmiany w częsci wykonawczej procesora wskazuje zastosowanie Virtualizacji, a co za tym idzie HT

 

----> AMD żałuje że zapowiedziało procesory dwurdzeniowe na długo przed ich wprowadzeniem, dając jednocześnie czas Intelowi na zbudowanie konkurencyjnych układów.

Gdyby nie to, na utrzymywane do końca w tajemnicy, i wprowadzone bez jakich kolwiek zapowiedzi Athlony X2, Intel nie miałby żadnej odpowiedzi przez conajmniej 8 - 9 miesięcy.

 

AMD pobrało kolejną lekcję z histori więc rev F może być zmyłką dla konkurencji, a zamiast K-8 rev F, na Socket AM2 zobaczymy nowe dziecko AMD, procesory K-9

 

 

Dodatkowym faktrem przemawiającym za tą wersją, jest fakt, że AMD miało problemy z produkcją nowych układów, i ostatecznie układy te mają wyjść 5 miesięcy później niż pierwotnie zakładano.

Gdyby zmienili w obecnych Athlonach tylko kontroler na DDR-2 zapewne nie mieli by problemów z produkcja już produkowanych na skalę masową układów.

[Shark19 0]

Athlony na M2 z obsluga 800MHz pamieci DDR2. Heh to sie niezle zapowiada

Wszystko wskazuje na to, że Athlony na M2, to będzie już zupełnie nowy K-9 ( patrz posty wyżej )

[eric 0]

Niesamowity topic !!,dowiedziałem się więcej po przeczytanu tej lektury niż na niejednym wortalu.Gratuluje wiedzy!!

[aWaKeN 0]

Wszystko wskazuje na to, że Athlony na M2, to będzie już zupełnie nowy K-9 ( patrz posty wyżej )

 

Wszystko, czyli co dokladnie?

Wyzej zaprezentowales kilka plotek, wypromowales nowinke od SISa i napisales nam nowy model plyty od MSI. Moze ja zbyt krytycznie na to patrze, ale tak naprawde to nie widze nic, co by moglo sugerowac nowa architekture...

AMD obecnie raczej koncentruje sie na probie gonienia Intela w technologia wytwarzania polprzewodnikow - Intel juz zalewa rynek prockami wykonanymi w 65 nm, a AMD nawet probek nie udostepnilo. AMD nie musi teraz wprowadzac nowego rdzenia - najbardziej zalezy im zwiekszeniu produkcji, bo paradoksalnie moznaby powiedziec, ze sprzedaja wiecej prockow niz sa w stanie wyprodukowac...

[Chłopiec 0]

...

 

zaginasz mnie wiedzą..

itak połowy z tego nierozumiem