Hirdetés
- ThinkPad (NEM IdeaPad)
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Apple asztali gépek
- Milyen TV-t vegyek?
- Milyen RAM-ot vegyek?
- AMD Navi Radeon™ RX 7xxx sorozat
- Bambu Lab 3D nyomtatók
- VR topik (Oculus Rift, stb.)
- 3D nyomtatás
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#5000
vedini
őstag
dangerzone
#4999
vedini
őstag
válasz
dangerzone
#4999
üzenetére
ha nem hiszel nekem, tedd fel ide a kérdésed:
[link] -
#4999
dangerzone
addikt
#95904256
#4998
dangerzone
addikt
válasz
#95904256
#4998
üzenetére
.....ha már a nevét kikerested, akkor jobban megnézhetted volna azt is, hogy 2 hetente van egy új hozzászólás....és valószínűleg nem lett volna értelme odaírnom....na hát ez van. AKI MEG ESETLEG TUDNA VMI ÉRTELMESET IS HOZZÁSZÓLNI AZ ANYÁZÁS HELYETT, ANNAK MEGKÖSZÖNNÉM ! ;)
-
#4998
#95904256
törölt tag
dangerzone
#4997
#95904256
törölt tag
válasz
dangerzone
#4997
üzenetére
Az AMD Athlon XP klub a te helyed...
-
#4997
dangerzone
addikt
dangerzone
addikt
Mert mégis hova írjak a felvetésemmel szerinted, ahol választ is kaphatok? A barton topikba, ami már 3 éve kihalt? Vagy intel core 2-es topikba, esetleg az nvidia 9600gt topikba?
-
#4995
vedini
őstag
dangerzone
#4994
vedini
őstag
válasz
dangerzone
#4994
üzenetére
nem sokat
nekem ha jól emlékszem ugyan ilyen barcim volt, és 2*256mb rammal mentgondolom ezzel a géppel nem vista alatt fogsz crysis-sal játsazni
-
#4994
dangerzone
addikt
dangerzone
addikt
Sziasztok! Igazából nekem régebbi fajta AMD-m van, de azért feltenném a kérdésem.
EGY 2800++@2433 barton procihoz megérné két giga ramot venni? Mennyit gyorsulna a rendszer az 1 gb ramhoz képest? -
#4993
zsolt320i
senior tag
csatahajós
#4991
zsolt320i
senior tag
válasz
csatahajós
#4991
üzenetére
azé kíváncsi leszek mi lesz belőle..!
naon szurkolok az AMD-nek... de már megint phenom előtti feelingem van:csak ígéret, semmi eredmény ... -
Joshi
titán
Sziasztok. Bocs az offért, de itt úgy gondolom több a hozzáértő ember mint más topikokban.
Adott egy Gigabyte GA-MA69G-S3H alaplap és bele egy X2 4000+ G1-es Brisbane proci, alapon járatva Idle hőfokok hőcsöves hűtővel 30 C° de ha elkezdem terhelni a procit mondjuk Orthossal, elkezd felszaladni a hőfok addig(110 C°) amíg le nem áll a gép.
Tök mind1 hogy alapon van a proci vagy húzva, a legújabb bios sem segített. Gondoltam egyet és felcseréltem az én MSI K9N SLI alaplapomban lévő X2 5000+ BE procimat a 4000-el. Az eredmény az lett hogy a Giga lap a hunyó, ugyanis az MSI lapban jól működött a 4000-es, de az 5000-es hőfoka ugyanúgy kúszott felfele 100 C° felé. 
Szerintetek mi lehet a bibi? Ez hardveres dolog vagy lehet szoftveres(Win sp3, AMD driver stb)? -
#4991
csatahajós
senior tag
csatahajós
senior tag
-
#95904256
törölt tag
válasz
band1103
#4987
üzenetére
Miért van az hogy az AMD cpuinak sokszor a fele vagy a negyedakkora a gyorsítótárja mint az Intel cpuinak?
Felépítésbeli különbség miatt az AMD processzoroknál kevésbé számít a gyorsítótár méretének növelése. Pl. a beépített memóriavezérlő és az exclusive cache szervezés miatt ( egy adat csak egy helyen szerepelhet a gyorsítótárban ).
Nem gyorsítana a cpun ha több lenne?
De igen. Csak ez nem olyan egyszerű hogy megszorzom kettővel...
-
#4985
leviske
veterán
VaniliásRönk
#4984
leviske
veterán
válasz
VaniliásRönk
#4984
üzenetére
-
#4984
VaniliásRönk
nagyúr
leviske
#4983
VaniliásRönk
nagyúr
-
leviske
veterán
Mivel mostanság kicsit megkavarodtam, ezért megszeretném kérdezni a tisztelt AMD témában jártas kollégákat, hogy az AM3 mikorra várható?
Az AM3 is eltolódott 1-2 évvel, vagy már a Deneb arra fog érkezni? Esetleg a Hydrától vezetik be?Most gondolkodom azon, hogy AMD platformra váltok és remélem legalább egy Denebet beletuszkolhatok majd a gépbe alaplapváltás nélkül... Ha ez a Hydrával is sikerülhetne az csak egy külön öröm volna...
-
#4982
Thrawn
félisten
VaniliásRönk
#4981
Thrawn
félisten
válasz
VaniliásRönk
#4981
üzenetére
Tudom, ez náluk bevett szokás, hogy 6 hónaponként fejlesztenek a gyártástechnológián, de vajon a mostani mi lehet?
-
#4979
Thrawn
félisten
VaniliásRönk
#4977
Thrawn
félisten
válasz
VaniliásRönk
#4977
üzenetére
Vajon a napokban bejelentett CTI mit jelenthet?
-
-
#4974
#95904256
törölt tag
Balala2007
#4973
#95904256
törölt tag
válasz
Balala2007
#4973
üzenetére
Szép...
...és logikus.Most hazarobogok és kipróbálom újra.
Rettentő nagy baromságnak tűnik amit leírtam. -
Balala2007
tag
válasz
#95904256
#4951
üzenetére
Előbb kipróbáltam ezt a cache-miss dolgot egy Phenom-on és egy Wolfdale-en is. Mindkettő képes volt arra hogy amíg a cache-miss miatt bejön a RAM-ból a dolog addig több száz utasítást ( add, xor, inc, fld, fstp, ... ) végrehajtsanak, így a több száz utasítással és azok nélkül is ugyanannyi volt a futásidő.
En is kiprobaltam egy Phenomon, es nekem az jott ki, hogy a reordering az csak ROB-nyi uop kozott mukodik. Az ellenkezoje meglepett volna, hiszen a retirement is in-order minden esetben.
#define BUFFER_SIZE 16 * 1024 * 1024
#define STRIDE 1024
#define READS 10000000
__declspec(naked) void __fastcall Walk(DWORD *raddr, DWORD repeat) {
__asm {
startWalk:
mov ecx, [ecx]
dec edx
jnz startWalk
ret
}
}
__declspec(naked) void __fastcall Walk2(DWORD *raddr, DWORD repeat) {
__asm {
startWalk2:
mov ecx, [ecx]
nop
....
nop
dec edx
jnz startWalk2
ret
}
}
void _tmain(int argc, _TCHAR* argv[])
{
double start, end;
DWORD *buff = NULL;
buff = (DWORD *)VirtualAlloc(NULL, BUFFER_SIZE, MEM_COMMIT, PAGE_READWRITE);
int index = 0;
for (index = 0; index < (BUFFER_SIZE / sizeof(DWORD)) - (STRIDE / sizeof(DWORD)); index += STRIDE / sizeof(DWORD))
buff[index] = (DWORD)&buff[index + STRIDE / sizeof(DWORD)];
buff[index] = (DWORD)&buff[0];
Walk(buff, READS);
start = (double)__rdtsc();
Walk(buff, READS);
end = (double)__rdtsc();
printf("Clocks:%f\n", (end - start) / (double)(READS));
start = (double)__rdtsc();
Walk2(buff, READS);
end = (double)__rdtsc();
printf("Clocks:%f\n", (end - start) / (double)(READS));
return;
}Ez a szokasos lancolt listas memoriaolvasgatast csinalja 2 verzioban. A masodiknal a futasido megegyezik az elsovel (nalam 145 clock-ra jon ki 1024byte-os stride-dal), amig csak 66db nop-ot szurok be. Ez stimmel is, mert 66 nop + 3 uop + 1 fetch bubble az 72 uop. A 67. nop utan erdekes modon elkezd lassulni, pedig a 145 clock alatt meg boven lenne ideje nop-okat apritani, de hat nem tud az in-order retirement miatt.
-
#4972
Oliverda
félisten
csatahajós
#4971
Oliverda
félisten
válasz
csatahajós
#4971
üzenetére
Ha ezt meg tudják csinálni akkor talán még van sansz egy 2.7GHz-es Phenom FX -re is (65nm-en).
-
#4971
csatahajós
senior tag
Oliverda
#4970
-
Hakuoro
aktív tag
AMD plans to update 65nm Barcelona
Talán van remény még arra hogy kiadnak egy 3Ghz-s 65nm-es Barcelonát.
-
#4968
csatahajós
senior tag
shabbarulez
#4967
csatahajós
senior tag
válasz
shabbarulez
#4967
üzenetére
Azért bizony bizony Barcelonából is vollgtak 3.0Ghzes példányokkal ref. hűtéssel ha emlékszel rá és azt a bizonyos 3.2-es Nehalem-et sokan megkérdőjelezik, hogy nem valós órajel volt az, nem véletlen hogy kisebbre is tippelik a gyártásba kerülő első procik órajelét.
Az hogy mim ennyire sikeres üzletileg szerintem kívülről láthatatlan, úgy értem gőzünk sincs, nem is lehet, hogy pontosan minek mennyi a kifejlesztési költsége, előűééítási fix költsége blahblah. Az egy dolog hogy mit ír a fudzilla meg a többi oldal (beleértve a hihetőbbeket is) és megint egy másik hogy mi a valóság. Nem mondom hogy K10 annyira nyereséges volt persze, de nem tudhatjuk biztosan, sőt szerintem a szerver vonalon csak most a B3asok kiadásával lesz igazn felfutása és majd azután érdemes ítélni (és ha jól emlékszem itt bizony az AMD megint eladta a procijait mielőtt legördültek volna a gyártósorról, úgy mint anno a K8as szépidőkben.
Sajnos az AMD marketingje és kommunikációja erősen hagyott kívánnivalókat az elmúlt időben, de nyílván nem segített ezen az hogy a sajtó a TLB patchet iszonyatosan felfújta, illetve a tegnap is linkelt Intel "mutatvány" finoman szólva is gusztustalan húzás, ami megintcsak nyílván nem segített...Ezen felül nem azt mondtam, hogy a Nehalemmel annyi is olyan problémák lesznek mint a K10zel, csak azt hogy nem lesz valószínűleg olyan "cakewalk" nekik sem mint Core volt (amire azért a 10X akkora Intelnek is 3 év kellett, hogy lenyomja a K8ast).
Paul Otellini: sajnos már nem emlékszem a forrásra és csak fejből "idézem" de nekem úgy rémlik hogy konkrétan a K10től féltek, mert tudták, sejtették hogy egy elég komoly technológiai dobás és hogy ők nem merték volna meglépni 65nm-en, erre szó szerint emlékszem (nyílván pont azért, mert ismerték a velejáró lehetséges buktatókat).
-
#4967
shabbarulez
őstag
csatahajós
#4965
shabbarulez
őstag
válasz
csatahajós
#4965
üzenetére
A Barcelona tape outja 2006 decemberben volt és 2007 szeptemberében, alig 10 hónappal később már késztermékként árulták. Vagyis árultál volna ha nem lett volna paper lauchos az indulás. A Nehalem tapeoutja 2007 szeptemberben volt, az indulása nagy valószínűséggel hasonlóan novemberben lesz ahogy tavaly is akkor startolja a penrynek. Ez 14 hónap, vagyis az Intel több időt hagyott magának a rákészülésre, nyoma sincs olyan kapkodásnak ami AMD-nél volt tavaly megfigyelhető.
Ráadásul tavaly már elég korai időszakban előjött az Barcelona órajel problémája, úgy emléxem tavaly májusban amikor először bemutattak működő példányokat a nagyközönségnek, azok valami 1.5 Ghz-en futottak. Ez a tape out után 5 hónappal volt. Ezzel szemben az Intel rögtön a tape out hónapjában, a tavaly őszi IDF-en bemutatott működő Nehalem példányt, amit idén tavasszal 7 hónappal később ismét megismételtek és itt már az órajel is publikus volt, 3.2Ghz-en futottak a kétutas Nehalem konfigok. Szóval Nehalemnél egyáltalán nem látszanak olyan órajel skálázási problémák, mint amik Barcelonánál már a kezdetek óta megvoltak és a mai napig hátrányt jelentenek.
Otellini nem azt mondta hogy nem merték a natív 4 magot 65nm-en, hanem üzletileg és gyártási volumen szempontjából nem tartották gazdaságosan megoldhatónak. Ezért van hogy az Intel csak 45nm-en látta racionálisnak a natív 4 magot és ott meg is fogják csinálni. Az AMD megcsinálta 65nm-en és bele is szaladtak azokba a buktatókba amiről Otellini beszélt. Üzletileg azért olyan nagy sikernek nem nevezhető a K10. Technológialig lehet róla szuper latinuszokban beszélni, ahogy a K8-ról is lehet, de nem szabad elfelejtetni ez üzlet, amit profitra játszanak, nem pedig "technológiai szépségverseny".
-
#4966
Thrawn
félisten
csatahajós
#4965
Thrawn
félisten
válasz
csatahajós
#4965
üzenetére
Kicsit "túl kevés túl későn" érzésem van, de majd meglátjuk hogy alakulnak a dolgok.
-
#4965
csatahajós
senior tag
shabbarulez
#4964
csatahajós
senior tag
válasz
shabbarulez
#4964
üzenetére
Azért én nem venném készpénznek a Nehalem olyan gyors elterjedését. Mivel a Nehalem elég hasonmló a K10-hez architektúrálisan (mármint amennyit felgounk belőle úgy nagyobb vonalakban - tisztelet a kivételnek) ezért szerintem az Intel is meg fog szenvedni vele valaemnnyire, csak maximum könnyebb dolguk lesz a nagyobb tőkéjüknél fogva. Anno talán pont Paul Otellini nyilítkozta, hogy az Intel nem merte volna megpróbálni a K10-et 65nm-en...az AMD nek sikerült, igaz nagyon nyögvenyelősen és egyelőre kompromisszumokkal...de szerintem így visszagondolva okosan döntöttek, hosszú távra ez volt a jobb befektetés mégha rövid távon szívnak is vele mint a torkosborz. Mivel pont a szerver piac az AMD elgerősebb pontja és mivel a nehalem pont itt jelenti majd a legnagyobb veszélyt ezért teljesen logikus hogy ide koncentráltak, beáldozva némileg a desktop és mobil vonalat.
Én is csak abban bízom, hogy a Griffin proci elég erős lesz ill. a Puma platfrom sikeres és akkor a desktop fronton csak kibírják valahogy a nyomott árakkal...
Thrawn, egyetértek, szerintem is majd a Rev D.-k lesznek az igazán nyerők, addig meg egy Blackbox 9850-es Phenom egy 790FX/SB750es deszkába sem lesz rossz
-
#4964
shabbarulez
őstag
Oliverda
#4960
shabbarulez
őstag
válasz
Oliverda
#4960
üzenetére
Ezek már sokkal hihetőbb, racionálisabb dátumok. A múltkori Istanbulos cikkeken csak mosolyogni lehetett annyira komolytalanok voltak, főleg azok a részek ahol már idén elinduló sorozatgyártást fantáziáltak, meg a dunninton ellenfeleként próbálták beállítani a terméket. Én legoptimistább esetben is 2009 nyarára datáltam az Istanbult megjelenését az előző hírek esetében, de ez a 2009H2 már egész reális dátum.
Én úgy gondolom az MCM 12 magosnak maximum egy nevedévnyi többlet kell a megjelenéshez, szóval ha a 12 magost már 2010-re prognoszitzálják akkor az inkább Q1, a 6 magos meg inkább 2009Q4. Nem hiszem hogy bármi indokolna fél évnyi difit e két termék között.
Ha bejön a tegnapi hír, az hogy 2009 végére az AMD-nek sikerül átállnia egy második generációs, javított 45nm-es gyártástechnológiára, ami már pariban lesz az Intel féle megoldással akkor jobb esélyei lehetnek ezeknek a termékeknek. Ha a 12 magos valóban 2010Q1-re kijön, az Intel 8 magos Xeon MP-je meg 2009Q4-re akkor elég közel lesznek egymáshoz, közel azonos gyártástechnológán alapulva. Az Intel oldalon lesz a több szál és a jobb IPC, meg kicsivel magasabb órajel a kevesebb mag miatt, AMD oldalon meg 1.5x több mag. Ez szerintem egy egálra elég lesz, többutas fronton erős és kiegyensúlyozott verseny lesz.
Viszont a 6 magos Istanbulnál mer közel sem lesz ilyen rózsás a helyzet, hisz addigra Intel szintén elindul a saját 6 magos Nehalemjeivel, ráadásul 32nm-en. A 6 magos Istanbulnak a 4 magos Nehalem jó ellenfél lett volna, ha már az SMT-t nem pártolja az AMD, ez a 1.5 több mag elképzelés egy jó irány lenne. Csak ezzel már valóban 2008Q4-re, a Nehalem érkezésére kellett volna elkészülni, nem pedig egy évvel későbbre, akkor versenyképesebb termékük lehetett volna.
A javított 45nm-es gyártástechnológia inkább csak arra lesz elég, hogy csökkenessen a különbséget a 32nm-es 6 magos Nehalem és az Istanbul között, de ezt a két terméket már nem érzem egálban.
2010-ben gondolom ezek mintájára jönnek majd a 6 magos desktop és mobil termékek mindkét gyártó részéről, az eltérés ismét a gyártástechológiában lesz. A tegnapi gyártástechnológiás hír is erősen azt erősíti 2010H2 előtt aligha valószínű 32nm megjelenése AMD fronton. Hisz ha 2009 végére csak egy második generációs javított 45nm-et jelentenek be, akkor a 32nm onnan még jóval később várható. Anno volt az a hír amiben az IBM arról regélt hogy felgyorsított az 32nm bevezetését és már akár 2009 végére megjelenhet. Anno akkor is azt mondtam, nem sok realítása van ennek AMD-nél, inkább egy évvel később 2010 végére valószínű. Most ez a második generációs 45nm várható dátum is erősen ugyanarra enged következtetni.
-
Oliverda
félisten
AMD 12-core server part planned for 1H 2010
AMD 6 core Istanbul to arrive in 2H 2009
AMD 45nm Shanghai to have improved IPC
AMD Quad core Suzuka supports DDR3
Hogy ki mit hisz el ezekből azt mindenki döntse el maga.
-
#4956
g4dg3t
senior tag
csatahajós
#4954
g4dg3t
senior tag
válasz
csatahajós
#4954
üzenetére
8mag + 8x1MB L2 + 6MB L3 egy sziliciumon
tenyleg jol hangzik, de a 45nm-es shrink + high K bevezetese tenyleg lehetove tenne ezt?
ezt egyelore vmi pszihedelikus latomas szintjen erzem -
#4955
slett27
addikt
csatahajós
#4954
slett27
addikt
válasz
csatahajós
#4954
üzenetére
10MB cache bizony hogy jól hangzik.
-
#4954
csatahajós
senior tag
csatahajós
senior tag
Tudom, hogy fudzilla, de jól hangzik
-
#95904256
törölt tag
Ez szép, de gyakorlatban hány utasításnyi hosszra szoktak elhúzódni az alapblokkok? 3-5? 10? Meg hány utasítás forog egyszerre feldolgozás alatt? Tipikusan néhány tucat? A SUN-féle megoldás azért új, mert ennél jóval nagyobb távokról is szó lehet, a dolog nincs a VÁ hosszához kötve.
Bevallom ezt nem egészen értettem. Mit értesz alapblokk alatt? Egy mag (AMD/Intel) egyszerre egy-öt utasítást képest feldolgozni, de az ICU/ROB-ban egyszerre 20-30 x86-os utasítás fér el. Ha az egyik várakozik, attól még az ICU/ROB képes új utasításokat fogadni. Mi itt a kritikus dolog?
A SUN-féle megoldás becsapós. Mivel in-order így egyszerre csak egy utasítást hajt végre, ha az várakozásra kényszerül akkor a kisegítő szál képes foglalkozni egy második utasítással. Ha az is megakad, akkor nincs tovább, akkor bizony várni kell. Az AMD/Intel megoldás esetén pl. ha az ALU és a FADD foglalt, akkor még mindig lehet memóriaműveletet végezni vagy éppen a FMUL-t bizgetni.
Egyszerűen nem látom hogy hol jön össze előny az AMD/Intel megoldáshoz képest. Illetve az látszik hogy kevesebbet fogyaszt, de a scout-thread-es dolog csak félig-meddig pótolja az out-of-order vezérlőt.
-
Rive
veterán
válasz
#95904256
#4951
üzenetére
Előbb kipróbáltam ezt a cache-miss dolgot egy Phenom-on és egy Wolfdale-en is. Mindkettő képes volt arra hogy amíg a cache-miss miatt bejön a RAM-ból a dolog addig több száz utasítást ( add, xor, inc, fld, fstp, ... ) végrehajtsanak, így a több száz utasítással és azok nélkül is ugyanannyi volt a futásidő.
Jól értem, tulajdonképpen egy stall-nyi szünetet töltöttél fel független utasításokkal? Ez szép, de gyakorlatban hány utasításnyi hosszra szoktak elhúzódni az alapblokkok? 3-5? 10? Meg hány utasítás forog egyszerre feldolgozás alatt? Tipikusan néhány tucat? A SUN-féle megoldás azért új, mert ennél jóval nagyobb távokról is szó lehet, a dolog nincs a VÁ hosszához kötve.Majd kerestem egy UltraSparc T1 leírást, amiből kiderült hogy ez a processzor in-order végrehajtással rendelkezik, de képes arra hogy pl. egy cache-miss-nél egy másik szálon (scout-thread) tovább futtassa a további utasításokat. Kvázi out-of-order végrehajtást csinál úgy hogy befog egy másik egységet a feladatra.
Ha jól értem, a T1 (vagy csak a T2? Ebben nem vagyok biztos, nem igazán másztam bele a csalkádfába) igazából nem másik egységet, hanem inkább csak másik (in szitu tükrözött) kontextust fog be a dologra... -
#95904256
törölt tag
Előbb kipróbáltam ezt a cache-miss dolgot egy Phenom-on és egy Wolfdale-en is. Mindkettő képes volt arra hogy amíg a cache-miss miatt bejön a RAM-ból a dolog addig több száz utasítást ( add, xor, inc, fld, fstp, ... ) végrehajtsanak, így a több száz utasítással és azok nélkül is ugyanannyi volt a futásidő.
Majd kerestem egy UltraSparc T1 leírást, amiből kiderült hogy ez a processzor in-order végrehajtással rendelkezik, de képes arra hogy pl. egy cache-miss-nél egy másik szálon (scout-thread) tovább futtassa a további utasításokat. Kvázi out-of-order végrehajtást csinál úgy hogy befog egy másik egységet a feladatra.
Ez akár egy működő példa is lehet fLeSs által is felvázolt több mag közti utasítás szétosztásra.
-
#95904256
törölt tag
Hm... A vastagon kiemelt részeket dokumentáció vagy analízis alapján mondod?
Próbáltam utána keresni a Niagara benchmark értékeinek, de csak ilyesmit találtam. Ezek szerint a Niagara nem tűnik csodának, bár a fogyasztása kétségtelenül a legjobb. Ebből viszont arra következtetnék hogy amennyira csak lehet kerüli a plusz munkát. Már pedig a "néhány ezernyi utasítás" becslésen alapuló előfeldolgozása ugyancsak tranzisztor melengető dolognak tűnik...
-
P.H.
senior tag
Van egy dolog, ami mellett nem tudok szó nélkül elmenni (megint
): az Itanium. A sok éves tervezés alatt gyakorlatilag »mindent« megoldottak program/fordító/utasítás szinten, amit az x86 vonalon rengeteg tranzisztorral spekulálnak.
Ha ránézek a Penryn-re, gyakorlatilag mindent megoldottak szilíciumon, amit az Itanium már a fordítóprogramok szintjén megkövetel az utasításkészlete és in-order felépítése miatt; SZVSZ innen nincs tovább.
- utasítás-átrendezés és függőségkezelés vs templates & (változó méretű) instuction groups
- memóriaművelet-átrendezés vs data és control speculation utasítások
- stack engine vs stacked register files + register stack engine
- Loop Stream Detection vs register rotation
- szinte minden utasítás valamely condition register-en alapuló feltételes végrehajtása vs conditional move(?)Illetve van tovább: a x86 fordítóknak fel kell nőniük ilyen szintre; és akkor rendesen működni fog az in-order Atom és a Larabee is. Az Itaniumnak ehhez nem kellett több, mint 32 általános integer (+ kommunikációs terület), 32 FPU és 32 condition (~flags) közvetlenül elérhető register (plusz az application register-ek).
-
Rive
veterán
válasz
#95904256
#4946
üzenetére
Az Intel/AMD-féle spekulatív végrehajtás néhány tucat utasítás mélységű, és az ugrás-előrejelzésel együtt ugye arra szolgál, hogy a feltételes utasítások dekódolásától a tényleges kiértékelhetőségig tartó, tipikusan néhány tucatnyi utasítás végrehajtása megkezdődhessen és jó eséllyel megfelelő véget érjen.
A Niagara cucca viszont a memóriahasználatot próbálja előrejelezni: a max. néhány ezer utasításnyi távolban szükségessé váló memóriaterületeket tölti előre.
A két megközelítés annyira eltérő, hogy én a Niagara megoldásának hatékonyságára még tippelni se merek, annyira idegen nekem.
-
#95904256
törölt tag
-
Rive
veterán
Ez a sok lassú mag = egy gyors mag sztem nem is olyan bonyolult, elviekben.
Csak asszem kell hozzá egy közös fetch, amit mind a 4 (x) mag használ, és akkor meg lehet úgy is csinálni, mint a fine-grained HT, hogy órajelenként egyet ugrik az IP, ekkor egyet ugrik a "CPU-mutató", és azt az utasítást a következő proci fogja feldolgozni. Következő utasítás, következő CPU, és így tovább.
Háááát.... Szóval ilyen esetben hogyan kezelnéd a kontextusokat? OK, hogy az utasításfolyamot szétszórod több magba, de ezeket a magokat neked folyamatosan konzisztens állapotban kell tartanod. Ez a logika az, ami a szuperskalás OoO magokat oylan bonyolulttá teszi, és el sem akarom képzelni, hogy több magra - még ha esetleg nem OoO szuperskalár magokról lenne is szó - kiterjeszteni egy effélét mennyi áldozatba kerülne.A SUN dobott most egy nagyot ezen a területen a Niagara árnyék-szálaival. Ha jól emlékszem, ott az volt, hogy a használaton kívüli logikai magok előreszaladnak a végrehajtással - korlátozott érvényű végrehajtással - , és etetik egyrészt az Icache-t, másrészt a Dprefetchet. Állítólag nagyon hatásos...
-
P.H.
senior tag
Szépen hangzik, csak a megvalósítása nehéz (jelen pillanatban még), főképp az hiányzik belőle, hogy egyetlen szál mennyit profitálna ebből. Amit Hans felvázolt abban, amit #4924-ben linkeltem, pont ezt csinálná: a klasszikus decode- és környezetduplázás helyett az execution unit-okat többszörözi; viszont ezek között igen komoly kommunkációs megoldások kellenének, hogy felvegyék a versenyt a jelenlegi VE-k közti bypass network-ökkel, storeforward-dal, memóriaművelet-átrendezésekkel, stb.
Ez akkor lenne igazán ütős (és megvalósítható), ha pl. nem lehetne látni a Nehalem-ben azt a sok statically partitioned egységet.
-
#95904256
törölt tag
En csak annyit akartam mondani, hogy az Inteles HT megoldas nem futtat gyorsabban egyszalas progit attol, hogy ugy tunik, mintha ket proci lenne. Ami ugye raadasul nem is ketto, csak 1,x...)
Értelek. Egy trabantba se tudsz gyorsabban beszállni attól hogy két ajtaja van...
-
zlutor
aktív tag
válasz
#95904256
#4935
üzenetére
Te vagy a processzor lelekbuvar, biztosan nem tevedsz...
De majd fLeSs megmondja...En csak annyit akartam mondani, hogy az Inteles HT megoldas nem futtat gyorsabban egyszalas progit attol, hogy ugy tunik, mintha ket proci lenne. Ami ugye raadasul nem is ketto, csak 1,x...)
Na, mindegy...
-
-
fLeSs
nagyúr
Az SMT nem azért nem gyorsult nálad, mert a rekurzív programodban csak vmelyik adott VE-(ke)t dolgoztattad? De, egészen biztos. Akkor még szép, hogy nem gyorsul.
Ez a sok lassú mag = egy gyors mag sztem nem is olyan bonyolult, elviekben.
Csak asszem kell hozzá egy közös fetch, amit mind a 4 (x) mag használ, és akkor meg lehet úgy is csinálni, mint a fine-grained HT, hogy órajelenként egyet ugrik az IP, ekkor egyet ugrik a "CPU-mutató", és azt az utasítást a következő proci fogja feldolgozni. Következő utasítás, következő CPU, és így tovább.
Vagy nem?
Ez egy elég primkó, de talán működőképes koncepció lehetne. -
-
#95904256
törölt tag
Attól hogy azt mondom "Intel féle hyperthreading" az nem azt jelenti hogy fele annyi erőforrás, mint a nem Intel féle megoldás.
Mivel az X2-esed kétszer annyi erőforrással rendelkezik mint az Intel processzorod, így nem csoda ha egy erősen párhuzamos feldolgozást végző algoritmus kétszer gyorsabb fut rajta. Vagy tévedek?
-
P.H.
senior tag
válasz
#95904256
#4931
üzenetére
- SZVSZ a találati arány általában messze 80-90% felett van jó ideje, a prefetch-megoldások a döntőbbek inkább, adat-megközelítésben ezek sokkal kisebb találati aránnyal rendelkezhetnek.
- Nem értem pontosan, mire gondolsz itt, a függőségek esetén. (ok, INC nincs, ECX >= 8
). A VIA és az AMD esetén jól lehet látni, milyen módon oldják meg a portok közti elosztást (~FIFO, alap -> szabályok); az Intel-nek sincs sokkal több órajelbeli (= több lépcsőjű) ideje ezt a leosztást megoldani a közös ROB/RS-sel, tehát nagyon bonyolult nem lehet (csak nem utasítássorrendbeli egyszerű "balról jobbra"?)- VIA: "Pl. duplapontos szorzással 3 órajel alatt végez, viszont csak 2 órajelenként indítható. Az osztás viszont az első órajeltől kezdve átlapolt! Ilyet sem az AMD sem az Intel nem tud..." Pedig pont neki nem kellene tudnia ilyeneket, ismerve azt, hogy hova szánja...
Ígéretesen hangzik, de ezzel én megvárnám pl. a részletes latency/throughtput értékeket tartalmazó dokumentációt. -
zlutor
aktív tag
válasz
#95904256
#4923
üzenetére
Haat, ebben azert nem vagyok biztos...
A HT valami olyasmi - amennyire en tudom - hogy bizonyos dolgok meg vannak duplazva a prociban, igy ha tobb(!) szalat kell futtatni, akkor esetleg(!) gyorsabb. Ha meg olyat hasznal jellemzoen, amibol nincs ketto, akkor nem gyorsabb...
De magam is irtam olyan ellenpeldat: sok szalon futo, de szalankent erosen rekurziv progit, ami semmit - de tenyleg semmit - nem profitalt a HT-bol. Egy szalon futott X ideig (50% load a task managerben), ket szalon is X ideig futott, de a task manager szerint 100% volt a load... Az X2-esemen nem volt gond, ott ket szalon ~ feleannyi ido alatt vegzett...
Az mar cska hab volt a tortan, hogy a Core2-k sem igazan szerettek...
Szoval, ha az AMD megcsinalja, hogy virtualisan egy magnak latszon a sok valodi mag, akkor megerdemelnek egy HATALMAS
-t... Meg ugy is, ha ez csak valamifele fordito progi oldali tamogatassal, mert az brutalis teljesitmenyt adhatna... Persze, az lenne az igazi, ha vegre jol skalazodo alkalmazasok keszulnenek... -
#95904256
törölt tag
- branch-prediction eljárások (és amekkora megbízhatósággal rendelkeznek) nem hiszem, hogy manapság fontosabbak lennének a megfelelő prefetch-algoritmusoknál.
Itt nem csak a találati arányra gondoltam. Pl. ha az AMD processzor (K7-K8-K10) belefut egy ugró utasításba az minimum +1 órajel végrehajtási időt jelent, ha ténylegesen ugrani is kell akkor még több is lehet. A Core2-nél ez legtöbbször 0(!) órajel ( Jcc near ).
- OoO hatékonysága: ezen a téren SZVSZ az AMD teljesen jó úton jár, lásd pl. a VIA Isaiah-t, ahol ugyancsak egy-egy port-hoz külön ütemező (RS) járul. (Te írtad anno, hogy az Intel érzékenyebb az utasítássorrendre, mint az AMD.) De az AMD-féle egyszerű pack-stages átrendezésnek sincs tovább jövője, látszik, hogy a többiek kifinomultabb algorimusokat alkalmaznak.
Itt sem csak pusztán sorba/átrendezésre gondoltam, hanem pl. a ICU bővítésére. Abban meg nem vagyok biztos hogy a külön-külön ütemező "gyorsabb" feldolgozást jelent. Szerintem Inkább csak tranzisztor spórolás. Pl. a címzésből adódó függőségek ( ADD ESI,ECX + FADD Q[ESI] ) így is lekezelendőek. A kétszer nagyobb, de közös puffer a több tranzisztorért cserébe integer illetve float-point intenzív kódnál hatékonyabb lehet. Már pedig az a ritkább eset hogy egyszerre mindkét reorder unit töltve van...
- lebegőpontos végrehajtás: persze, minél gyorsabb, annál jobb. Jó kérdés, hogy min múlnak a tervezési szempontok: a VIA össze tudott hozni 2 clock-os összeadást, az Intel 3 clock-ost, az AMD 4-est. Abszolút nem tükrözik a számok az erőviszonyokat, a szükségleteket és az anyagi hátteret.
Az csúcsteljesítményű processzoroknál természetesen a sebesség a lényeg. Egyébként a VIA Isaiah leírását olvasgatva van egy-két érdekes dolog a lebegőpontos részben. Pl. duplapontos szorzással 3 órajel alatt végez, viszont csak 2 órajelenként indítható. Az osztás viszont az első órajeltől kezdve átlapolt! Ilyet sem az AMD sem az Intel nem tud...
szerk.: A VIA Isaiah-ra már nagyon kíváncsi vagyok. Érdekelne hogy mennyi részt kell majd a doksiból másképp értelmezni.
-
P.H.
senior tag
válasz
#95904256
#4927
üzenetére
Feltételezve, hogy a "szerk:" részt nekem szántad:
Nem könnyű radikálisan új felépítést alkotni ("az aktuális K7-K8-K10 nagyon is jó"? volt erre egy hsz-em tavaly: "Az, hogy az AMD miért nem tudja járatni ezt az alapvető felépítést az annak „megfelelő” órajelen (szerintem egy olyan 4 GHz-ig kellene dual-core K10-nek skálázódni, hogy megoldódjanak rövidtávon az AMD problémái), ezt pontosan nem tudjuk, de lehetséges, hogy ennek okát nem a szűk értelemben vett magokon belül kell keresni." De jelen pillanatban én nem tudom, hol kellene keresni az okot.)
- branch-prediction eljárások (és amekkora megbízhatósággal rendelkeznek) nem hiszem, hogy manapság fontosabbak lennének a megfelelő prefetch-algoritmusoknál.
- OoO hatékonysága: ezen a téren SZVSZ az AMD teljesen jó úton jár, lásd pl. a VIA Isaiah-t, ahol ugyancsak egy-egy port-hoz külön ütemező (RS) járul. (Te írtad anno, hogy az Intel érzékenyebb az utasítássorrendre, mint az AMD.) De az AMD-féle egyszerű pack-stages átrendezésnek sincs tovább jövője, látszik, hogy a többiek kifinomultabb algorimusokat alkalmaznak.
- lebegőpontos végrehajtás: persze, minél gyorsabb, annál jobb. Jó kérdés, hogy min múlnak a tervezési szempontok: a VIA össze tudott hozni 2 clock-os összeadást, az Intel 3 clock-ost, az AMD 4-est. Abszolút nem tükrözik a számok az erőviszonyokat, a szükségleteket és az anyagi hátteret.
-
#4929
#95904256
törölt tag
VaniliásRönk
#4928
#95904256
törölt tag
válasz
VaniliásRönk
#4928
üzenetére
Arra, hogy két virtuális magon (valójában egy valóson) egy szálat futtatni teljesen más, mint két valós magon.
Mi a különbség azonkívül hogy azt mondod virtuális illetve valós mag, ha az erőforrások ugyanazok? ( ugyanannyi ALU, FPU, cache, stb... )
-
#4927
#95904256
törölt tag
VaniliásRönk
#4926
#95904256
törölt tag
válasz
VaniliásRönk
#4926
üzenetére
Nem egészen értem a kérdést. Melyik két dologra gondoltál?
szerk.:
A "találgatásokkal" kapcsolatosan megjegyezném hogy szerintem az aktuális K7-K8-K10 arhitektúra nagyon is jó, csak van pár részlet, amelyen az AMD-nek illene már csiszolni egy kicsikét. Gondolok itt az ugrás előrejelzésre ( csapnivaló a Core2-höz képest ), az OoO hatékonyságára ( szerintem ebben is elmarad ), valamint a lebegőpontos utasítások végrehajtási idejére ( pl. az összeadásban a Core2 33%-kal gyorsabb ).
-
P.H.
senior tag
válasz
#95904256
#4923
üzenetére
Ezek csak találgatásoknak tűnnek megalapozott információk helyett, én azon gondolkodok inkább, hogy a találgatások között miért volt fontos kiemelni azt, hogy "- Not VLIW, still OoO superscalar architecture"
De ha meg akarnám magyarázni a dolgot, erre és erre indulnék el (amit eddig Hans de Vries legnagyobb tévedésének tartottam, máig nem tudom hova tenni).
-
Oliverda
félisten
-
Hakuoro
aktív tag
AMD: Next CPU architecture will be completely different
Érdekes Azért az már látszik, hogy a K10-el nem sok piacot szerezhetnek.
Csak az a baj, hogy mire az új architektúra kijön az intel már talán a nehalem utáni architektúrát is kiadja.
-
#4915
csatahajós
senior tag
csatahajós
senior tag
Nem hangzik rosszul:
-
#4914
Thrawn
félisten
csatahajós
#4912
Thrawn
félisten
válasz
csatahajós
#4912
üzenetére
Úgy tudom, hogy az AM2(+) lábkompatibilis az AM3-al, szóval a Deneb belemegy majd a mostani lapokba is.
-
#4913
csatahajós
senior tag
csatahajós
#4912
csatahajós
senior tag
válasz
csatahajós
#4912
üzenetére
Itt is megerősítik:
-
#4912
csatahajós
senior tag
csatahajós
senior tag
Oliverda kérésére akkor maradjunk a K10 topikban:
A 95W-os 9750 és 9850 már nem is hangzanak rosszul, vlaószínűleg az overclocking is javulni fog tőle akkor
Nem értem, akkor ezek szerint a Deneb már egyből AM3-ra jön ki...?
-
Balala2007
tag
válasz
Balala2007
#4880
üzenetére
Ebben a pdf-ben szemleletesebb leiras talalhato az AVX-rol. Az is kiderul belole, hogy a VEX prefix nem csak a REX-et es SSE-t csereli le, hanem az escape-et is (0Fh), igy igazabol nem novekszik az atlagos utasitashossz, 2 byte-os VEX-nel meg me'g nehany esetben rovidulhet is. Meg egy elony az SSE5-tel szemben...
-
Oliverda
félisten
-
fLeSs
nagyúr
válasz
slett27
#4904
üzenetére
megmondom neked, ha elárulod, hogy egy shanghainak mik a méretei.
szerk:
találtam egy olyan infót, hogy 263 mm2. [link]
ha 16x16 mm-t veszünk alapul, akkor 246 darab fér egy waferre.
az itteni infó alapján a lefullosabb nehalem alig lesz nagyobb és ugye azt csak a highendbe és szerverbe fogják gyártani, a desktop nehalem elvileg kisebb lesz.
az AMD-nek még ott a propus (L3 nélküli shanghai), ami állítólag csak 170 mm2. -
#95904256
törölt tag
A K9 nem hivatalos megnevezés. Az AMD-n belül a kétmagos AMD64 ( Athlon 64 X2 ) processzorokra vonatkozott. Ezekből van socket 939-es és socket AM2 foglalatos processzor. Ez utóbbiakkal ( AM2 ) kompatiblisek a K10-es asztali processzorok ( Phenom ).
Vagyis az AM2 foglalatos lapokban, megfelelő BIOS mellett, mennek a Phenom processzorok.
Tök mind1 hogy alapon van a proci vagy húzva, a legújabb bios sem segített. Gondoltam egyet és felcseréltem az én MSI K9N SLI alaplapomban lévő X2 5000+ BE procimat a 4000-el. Az eredmény az lett hogy a Giga lap a hunyó, ugyanis az MSI lapban jól működött a 4000-es, de az 5000-es hőfoka ugyanúgy kúszott felfele 100 C° felé. 
így már értem!
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Építő/felújító topik
- ThinkPad (NEM IdeaPad)
- Civilization VII
- A fociról könnyedén, egy baráti társaságban
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- OpenWRT topic
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kerékpárosok, bringások ide!
- Apple asztali gépek
- További aktív témák...
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
- HPE Apollo 4200 Gen9 132TB+400GB rack szerver - E5-2620v4, 128GB RAM, 2x25G NET, 4GB RAID/ZFS, ÁFÁS
- LG 45GR65DC-B - 45" Ívelt 1500R / 5120x1440 / 200Hz 1ms / Adaptive Sync / AMD FreeSync / HDR 600
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest