Hirdeté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
-
dezz
nagyúr
Semmiből sem állt volna licencelni, nekik az zsebpénz. A probléma a presztizsveszteség lett volna... Ja, meg persze gondolom erősítette volna a viszont-függőséget, az AMD64 után.
(#5872) cizoe: A K10/K10.5 jóval több, mint 4xK8.
(#5879) daa-raa: A konfigurációs regiszterek definícióira gondolsz (a BIOS-hoz)? Hát igen, az is kell, de ahhoz valószínű olcsóbban hozzá lehetett volna jutni.
(#5881) P.H.: Azért talán az is számít, hogy melyik milyen komoly hiba...
Azaz, de szerintem egy Ph.D., aki elvileg a saját nevén blogol, nem fog a levegőbe beszélni. -
P.H.
senior tag
Ugyan a következő számokból nem lehet közvetlenül érdemleges következtetést levonni, de egy tendencia kirajzolódhat: négy CPU-család hibalistájából ez derül ki:
- a Merom dokumentációja már lezárt, a hibák vagy Fixed vagy No Fix állapotban vannak, a 128 hibából 84-re nincs javítás, ez 65%
- a Penryn-ek 74 ismert hibájából 62-re nem terveznek javítást, ez 83%
- a Barcelona 3 stepping-jének eddigi 42 nyilvános hibájából 10-re egyáltalán nem volt javítás ütemezve, további 23 hiba érinti mindhárom verziót, azaz a hibák 78%-a nincs javítva. (Shanghai Revision Guide még nincs.)A Nehalem-ek 77 közzétett első revíziós hibáinak csak 57%-át nem tervezik javítani, 33 hiba mellett szerepel Plan Fix. Ennek egyik oka lehet, hogy kiemelkedően sok, összesen 12 hibának van köze az újradefiniált C6 power state-hez.
dezz #5868: az említett dologról csak ezt találtam: [link] "Even Intel's weird 6 core chip is no match to Shanghai. As for Intel's copycat chip Nahelem, it won't be available until later 2009, as Intel is still struggling with some cache coherence issues in 2P configurations."
-
Oliverda
félisten
Ahh..na ezt nem tudtam.
cizoe: Hát azért én azt hiszem hgy egy Birsbane magtól nem kicsivel lesz gyorsabb. Értsd 30-40% szerintem. Mondjuk mivel itt nem lesz L3 ezért könnyen lehet hogy ezeknél sokkal többet fog jelenteni majd a DDR3 mint mondjuk a Deneb-nél.
Zeratul: Azért a chipset gyártás sem úgy megy hogy az AMD vagy az nV kitalálja és akkor holnaptól már mehet is. Liszensz kell hozzá az Intel-től amit vagy megadnak vagy nem.
-
Oliverda
félisten
Ettől függetlenül még akad jónéhány komolyabbank látszó hiba a C0 steppingben.
Core i7 Errata sheets (10-12 oldalak)
A Processor Core May Not Wake Up from S1 State
Incorrect TLB Translation May Occur After Exit From C6
Processor May Hang When Two Logical Processors Are in Specific Low Power
StatesSzvsz már rendesen menne a hype ha a 2. hiba a Shanghai-ban vagy a Deneb-ben lenne benne.
-
#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.
-
#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).
-
#95904256
törölt tag
-
Rive
veterán
No. Nem Banias, hanem már a Dothan volt a bűnös. Lényegében architektúra-optimalizálatlan programokkal, szingli memóriavezérlővel odavert néhány tesztben a desktop-szegmensnek már a laptop-kaliberű szereplése elején, valamikor 2004 első félévében. Ezek után kicsit átfaragták, desktoposították az architektúrát, és lőn Core2.
Rég volt, úgyhogy kisebb pontatlanságok előfordulhatnak. A lényeg az, hogy mire Core2 lett belőle, addigra volt két generációnyi laptopprocc az adott termékvonalból.
-
bnss
veterán
Nagyjából erre szerettem volna rávilágítani (csak az arányokkal nem voltam tisztában). Remélem még ez a "kis" mérnökgárdának is sikerül a 8xxx szériával "mutatni valamit talajon". Ördögi kör, mert vagy a K10-en dolgozik teljes kapacitással, ami még növeli a lemaradást, vagy a K10-et és K11-et arányaiban anagyjából megegyező létszámú csapattal fejleszti, akkor a K10 "marad le", viszont a K11 valamivel haamrabb debütálhat.
Intelnek ha csak 5 "brigádja" van, már mekkora előny, 5-ször több mérnök, 5-ször több szem, és mint tudjuk, több szem többet lát.
Kíváncsian várom a CeBIT-et.
-
-
dezz
nagyúr
Vehetjük a K8 90nm F2->F3-at is. F2-nek 2.6 GHz-nél volt a hivatalos vége, F3 azonos feszültségintervallumban +200 MHz, +0.05V-tal ehhez képest +600 MHz. [link]
(#3816) akosf: Az AM2+ foglalat max. TDP-je 150-160W körül van. Persze egy jobb AM2-es lap is tudja ezt. (Tovább tuningolni nem biztos, hogy nagyon lehet majd ott.)
(#3825) dzsi2006: Huh, szép!
Ki gondolta volna... (Az "FSB"-t miért kell emelni, ha BE?)(#3827) fLeSs: Hát izé, asszem én adtam neki az ötletet. Addig csak szídták az AMD-t, de úgy tűnik, valahol elindult a fantáziájuk.
-
#95904256
törölt tag
nem igen láthattunk <> nem láttunk
Másfelől ahogy utánaolvastam Thoroughbred A és B verziók megjelenése közt ugyan csak alig több mint két hónap telt el, mégsem egy átlagos stepping váltás történt. Ugyanis nem egyszerűen csak áttervezték a rajzolatot, hanem gyártástechnológiai váltás is történt. Alumínium helyett rezet használtak a kivezetésekhez, hétről kilenc rétegűre növelték a rétegek számát, valamint egy (hővezető?) fémréteget is beterveztek, amiről sajna nem sikerült kiderítenem hogy mi célt szolgálhatott.
Ezekkel a módosításokkal érték el hogy a Thoroughbred 1800MHz-es maximális órajelét 2250MHz-re sikerült feltornázni. Reméljük most is kitalálnak valami hasonlót az AMD-nél, mint öt évvel ezelőtt...
-
fLeSs
nagyúr
nem..
1ébként eléggé úgy tűnik, hogy tévedtem, szinte 0 különbség van, persze én desktop alkalmazásokat tesztelek, a szerverek egy másik téma.
mellesleg 1,8 ghz-en az L3 sávszélje annyi, mint a memóriáé 1066-os beállításban, csak a késleltetése jóval alacsonyabb (<10 ns), az everest szerint. -
dezz
nagyúr
''Mármint azt gondolod, hogy ezt gondoljuk.''
Hát, legalábbis úgy viselkedtek, mintha pontosan és szó szerint.
Azaz teljesen egyetértetek a túlzásokkal is. És én ezzel vitatkozom.
''Közben meg olyanokat írkálsz, amilyeneket, és mint kiderült, nem is velünk, hanem valaki más cikkével vitatkozol. Kellőképpen hitelesnek is tűnik, mit mondjak.''
Tudod mit, olvasd el az új cikket... De vágd ám be azt is szó szerint, mert kikérdezlek!
''Marhára bekajáltad a marketinget. Ez van.''
Tudom, ez ütős érvnek számít egyes helyeken, de te azért próbálj meg értelmesen válaszolni.
''Akkor döntsd már el szépen, hogy kivel vitatkozol, lárifári.''
Tegnap v. tegnapelőtt még te is 1-szálas dolgokat emlegettél, nemde?
''Van néhány. A menyasszonynak azt a tulajdonságát kell dícsérni, amit lehet. Hát, elég kevés ilyen került, az se túl életszagú, de ha neked ez elég, akkor legyen.''
Van ott más is, nem csak artifical tesztek.
Mellesleg van SPECint is, ami állítólag sokkal jobban fekszik a Xeonnak (ja, inteles fordítóval, itt meg a változatosság kedvéért GCC van...). [A ''sokkal'' még intelessel sem indokolt.]
''Ne idegesítsél már ilyenekkel. Nem is tudtam, hogy a VMark -tól az LSdyna-ig mindenki SPEC.''
Nyilván nem azokra utaltam.
''Néhány hét, és kijönnek a komolyan vehető tesztek, nem saját istállóból. Az majd jelent valamit.''
Itt is van néhány nem saját istállóból való.
[Szerkesztve] -
dezz
nagyúr
''Te mostság épp elég sokmindent utánanézés és átgondolás nélkül visszautasítasz itt.''
Szerintem meg nem ezt teszem. Ellentétben azokkal, akik a felületesnél egy szinttel mélyebb elemzésről azt gondolják, teljes keresztmetszet.
''Majd keress olyan vásárlót, aki ez alapján vesz szuperszámítógépet.''
Pl. egyetemeknek, kisebb kutatóintézeteknek ez nagyon is fontos szempont, akiknek pl. az állam támogatja a bevásárlást, de a fenntartást már nem.
Plusz legtöbbször egyszerűen hatékonyabb közepes fogyasztású procikból építkezni, mert a nagy fogyasztású nem annyival gyorsabb. Így növelhető a proci-sűrűség is, miáltal értelmesebb keretek között növelhető a procik száma, ami sokkal meghatározóbb összteljesítmény szempontból.
Meg szerinted az IBM csak marketingszöveget nyomat szuperszámítógépeknél? Asszem itt a vásárlók nem annyira megvezethetők.
''Tudod azokról szó se esett most itt.''
Ma itt nem, de pl. abban a bizonyos cikkben igen.
''Az efféle megjegyzéseken, illetve az ezek mentén továbbvezetett gondolati szálakon érhető tetten leginkább a jelenleg dúló fan-mentalitásod.''
Lárifári.
''Jáááááj. És még én nem vagyok képben
Olyan tesztekre nem szokás hivatkozni, aminél csak és kizárólag saját termékes relatív összehasonlítások vannak.''
Hát tényleg nem vagy, még meg sem nézted: Xeonos összehasonlítások is vannak itt!
''Pláne, ha saját műhelyből valók. Azok a 'teszteredmények' a marketingosztályon még elmennek egy prezentációban. De itt azért tartsuk már magunkat annyira, hogy komolyan nem hivatkozunk rájuk.''
Bla-bla-bla. Ezek itt SPEC Org. által hitelesített, ill. hitelesítésre váró teszteredmények.
[Szerkesztve]
[Szerkesztve] -
dezz
nagyúr
''Az a fanduma meg pláne nem, amire most úgy rácuppantál. Nekem is szívügyem az AMD sikere, de ez azért nem kényszerít arra, hogy olzan átgondolatlan hőbörgésekbe kergessem magam a védelmükben, amit most az utóbbi két napban produkálsz.''
Ezt kategórikusan visszautasítom.
''Szuperszámítógépes kategóriában meg sose játszott a fogyasztás - és soha nem is lesz elsődleges tényező.''
Most vagy hazudsz, vagy nagyon nem vagy képben.
Blue Gene/L
Major features
The Blue Gene/L supercomputer is unique in the following aspects:
- Trading the speed of processors for lower power consumption.
- [...]
Blue Gene/P
A BlueGene/P node cardOn June 26, 2007, IBM unveiled Blue Gene/P, the second generation of the Blue Gene supercomputer. Designed to run continuously at one petaflops, it can be configured to reach speeds in excess of three petaflops. Furthermore, it is at least seven times more energy efficient than any other supercomputer, accomplished by using many small, low-power chips connected through five specialized networks.
Blue Gene/Q
The last known supercomputer in the Blue Gene series, Blue Gene/Q is aimed to reach 10 petaflops in the 2010-2012 time frame. It will continue to expand and enhance the Blue Gene/L and /P architectures with higher frequency at similar performance/watt. Blue Gene/Q will have a similar number of nodes but many more cores per node. [7]
[link]
''És ezzel a procival a Barcelona partiban van, vagy csak szeretne? Hm?''
Több területen partiban van vele, alacsonyabb fogyasztás mellett...
Szakadjunk már el az 1-szálas desktop applikációktól... (És még én vagyok a fan.)
''Amúgy pedig, bármilyen hihetetlen, a Barcelona szerverpiaci bevezetése még messze nem teljes. Majd ha kidobják az adott szegmensre vonatkozó teszteket is. Azokban még lehet reménykedni. De SZVSZ marhára nem érdemes.''
Tessék, itt van: [link]
Előzőből: ''Kíváncsi vagyok, melyik nagy szakportált fogjátok először részrehajlással vádolni.''
Basszus, Bizó Dánielről (Special) még a régi motoros hwsw-sek is megmondják, hogy erősen az Intel felé húz. Bár ez a cikkek szintjén eddig nem jelent meg ilyen mértékben. (Problémák túlhangsúlyozása, pozitívumok elhallgatása.) (Meg még írhatnék itt 1-2 dolgot más témában is, ami a hwsw-t illeti, de inkább nem teszem.)
[Szerkesztve] -
#95904256
törölt tag
-
dezz
nagyúr
''Szóval tényleg kevered.''
Nem keverem, csak most már nem tudom, mit is akartál ezzel mondani?
Ha a szerverfarmnál nem számít a fogyasztás, akkor az volt a helyes, amit én írtam, először, tehát hogy a sokprocis gépeknél számít. Nézd csak meg a BlueGene-eket!
''Szerverfarm kaliberben messze nincs akkora watt-különbség a releváns termékvonalak között, hogy komolyan számítana. A NetBurst végén még volt. De az már elmúlt.''
Hírek szerint egy 3 GHz-es 4-magos Xeon is igencsak megeszi a részét (150W).
''Igen, ez itt nem a HWSW. A HWSW ArsTech sokkal közelebb áll az IT-piac dolgaihoz, itt meg totál szabadon mehet a bulvár és a fankodás.''
De egymás lefanozása itt, és egyátalán ez a hangnem, legalábbis pl. ebben a topikban nem volt divat. -
-
dezz
nagyúr
''Ez a metódus garantál cirka ugyanannyi eladott proccot, ahány AM2 v. mi fogyott. Meg még valamennyit.''
Esetleg AM2 + Socket F együttvéve. Plusz azok nagyobb része, akik (desktopon) AM2+-os lapokat vesznek, valószínű előbb-utóbb procit is cserélnek...
''Csak aztán nem túl soká lesz megint egy socketváltás, és annyi. Azokat is el kellene majd adni valamivel.''
Szerver vonalon a köv. foglalatváltás 2009-ben lesz (itt a DDR3 kimarad), és az már a köv. mikroarchitektúra generáció lesz (ami remélhetőleg jó lesz).
Desktop vonalon 2008 2. felében jön az AM3, a DDR2/DDR3 támogatás miatt. Egyébként újabb hírek szerint visszafelé ez is kompatibilis lesz, azaz az AM3-as procik működnek majd a AM2+-os, esetleg AM2-es lapokban is. Ugyan ez lesz Socket F/F+ esetén (2-utas Phenom FX-hez).
Rive: LOL, tudod, sokféleképp lehet tudósítani.
[Szerkesztve] -
Thrawn
félisten
A foglalatváltás előbb utóbb elkerülhetetlen lesz, de az legyen a marketingesek baja. Nem tartom lehetetlennek, hogy az első 45 nm-es példányok belepasszolnak majd. Nagyobb megrendeléseik máris vannak (Lucasarts, IBM, HP, Sun, egy texasi egyetem is berendelt már 15000 db-ot stb)
Kihagytam még egy fontos dolgot (hajnalban volt na) a továbbfejlesztett virtualizációt. A VMWare-től volt egy hölgy, neki is nagyon tetszett az új proci -
dezz
nagyúr
Szerintem meg nem éppen stimmelős. Inkább elhallgatós és több helyen téves.
Raymond: Veled sem értek egyet, egy itt leírt dologban sem. (Tanúja voltam, amikor ennek a Bizónak úgy kellett megmagyarázni egy külföldi fórumban, hogy a 10h miért 16...)
Na majd beolvasok nekik.
[Szerkesztve] -
#95904256
törölt tag
Én az AMD processzorok Intel-lel szembeni legnagyobb előnyéről beszéltem.
Ebből meg csak egy lehet. Melyik legyen, IMC vagy HT busz?
Az AMD IMC-je az Intel külső memóriavezérlőjével szemben akár 30%-kal nagyobb teljesítményre képes. Főképp a kisebb késleltetési idő miatt.
A HT busz megfelelője Inteles vonalon szintén a külső memóriavezérlő, hiszen ezen keresztül zajlik a processzorok ( nem a 2(4) mag ) közti kommunikáció. Itt az AMD megoldás előnye még nagyobb a fenti 30%-nál. Nem?
szerk.: Igaz, hogy IMC nélkül nehéz lenne elképzelni a HT buszt.
[Szerkesztve] -
dezz
nagyúr
Persze, de ezt miért írtad nekem?
(#1566) akosf: Úgy tűnik, csak emiatt nem érdemes másik gépet venned: tesztekből nem az jön le, amit robyeger írt...
M3kk: Elkezdtem olvasni, de most nem tudom az egészet elolvasni. Mindenesetre, hasonlóan 2 túlhajtott 2900XT-vel egy 5.1GHz-re húzott C2Q 27039 pontot hozott. Akkor ha valamit sokkal jobban csinál a 4 magos K10, miért ne tehetne rá még 3000-et? -
#95904256
törölt tag
A szinkron az adott szakterületen nem csak (nagyjából) azonos frekvenciát, hanem kifejezetten azonos frekvenciát és fix fázist (!) jelent.
Nem. A szinkron önmagában sem frekvenciát, sem fázist nem jelent.
A szinkronizálás egy művelet, a szinkron pedig ennek a folytonosságát jelenti. -
#65675776
törölt tag
-
#95904256
törölt tag
A Transmeta mostanában abból él hogy a Longrun2 technológiáját és egyébb ''energy-efficient'' megoldásokat próbál eladni. Ha jól tudom akkor az Efficeon processzort megvették tőle és még gyártják valahol Tajvan környékén, különféle beágyazott rendszerekhez. A Linux guru Linus Torvalds-tól meg békében elváltak, miután éveken keresztül 100 millió dolláros veszteségeket produkált a cég. Azóta talán nyereségesek, de valami minimális árbevétellel.
szerk: A honlapjukon olyasmi szerepel hogy a cég vagyona kb. 26 millió dollár és folytatják az adóság törlesztését...
[Szerkesztve] -
-
P.H.
senior tag
Én programozói szempontból tudok csak kiindulni, csak azokat tudom, hogy mik segítenék a munkámat.
Ennél a kódnál [link] (SSE IDCT, 2x4 oszlopot konvertál egymás után, majd 8x1 sort SSE2 integer megvalósítással gyorsabb lenne, de mindenképpen a lehető legpontosabb eredmény kellett itt) ha lenne egy megfelelő, shared L1 Data Cache-en alapuló Hyper-Threading, akkor párhuzamosan mehetne a 4 oszlopok dekódolása, nem kellene egymás után írni őket, a függőségek miatt úgyis ''lassú'' a végrehajtás, és kevés egység dolgozik egyszerre, akármennyire is szét vannak dobálva a függő utasítások. Shared L1, mert a cache-vonalak átvitele két cache között nem túl gyors művelet.
Ennél a kódnál [link] pedig annyira véletlenszerű a forrásadat, hogy biztos vagyok benne, hogy nagyon sok a misprediction, ezen segíthetne, ha mindig mindkét ág elindulna. (Ugyancsak a függőségek miatt mindig van szabad ALU).
Mindkét kód saját készítés, kéretik bárkinek felhasználás előtt kikérni az engedélyem
26 megapixeles képen a fenti két kód lefutása 2400 MHz-es K7-en (gettickcount-tal mérve):
- IDCT: több, mint félmillió teljes lefutás kb. 200 millisec alatt
- Huffman-decode: több, mint 17 millió teljes lefutás: 650 millisec alatt
Nagyon kíváncsi leszek, mennyivel gyorsul majd K8-on.
[Szerkesztve] -
-
P.H.
senior tag
macro-op cache: nem gondoltam a disszipációra, csak arra, hogy a ciklus-utasítások megspórolnának pár stage-t (gyorsulás). Az x86 beállt olyan 60-120W fogyasztásra, beleférnek növelő lépések, más, csökkentő lépések mellett.
elágazás-kezelés: úgy gondoltam, hogy csak azon elágazásoknak futna le mindkét ága, amelyek rendelkeznek az előző pontban említett prefix-szel, tehát a fordító jelezné, hogy IF-ELSE-ről van szó, és a displacement 8 bit-es (ezt elírtam), szóval a L1 instruction cache-re sem nehezedne számottevően nagyobb nyomás. Cikluselágazásokra teljesen megfelelő az eddigi becslési módszer. Ilyen vegyes megoldást még nem láttam sehol, és az random adatokon alapuló IF-ELSE-t minden mai x86 architechure is megsínyli. A prefix ötletét meg az Intel branch hint prefix-éből vettem.
Hyper-Threading: nem hiszem, hogy (prioritással kiegészítve) szélesíteni kellene a jelenlegi architectúrát. A fő cél az execution unit-ok lehető legteljesebb kihasználása, úgy, hogy ne egymás elől vegyék el a sávszélességet, bármilyen áron. Felsoroltam az elgondolásaimat, nem biztos, hogy mindegyik megfér egymás mellett.
El tudom képzelni, hogy egy high-class szál mondjuk az ő CPU-idejében főszálként fusson, máskor pedig mint másodszál, ami kihasználja a szabad execution portokat és macro-op helyeket. Persze, ez akkor hoz nagy teljesítménynövekedést hogy igaz, amit sejtek, hogy decode után (azaz utasítássorrendben) AMD-nél macroop-hármasoknál nincs vízszintes mozgás, tehát egy IMUL eax,ebx; IMUL ecx,edx; ADD esi,edi két hármasra fordul, ugyanúgy, mint egy ADDSS xmm0,xmm1; ADDSS xmm2,xmm3; MULPS xmm4,xmm5 (The instruction control unit takes the three macro-ops per cycle from the early decoders and places them in a centralized, fixed-issue reorder buffer). Ezesetben a tripletek teli vannak üres helyekkel (bubbles), amit ki lehetne tölteni.
Az Intel a cache mellett azzal is elszúrta, hogy a HyperThreading-et a PPro óta megjelent ''legkeskenyebb'' micro-architektúráján alkalmazta (4 port, shared INT/FPU).
[Szerkesztve] -
#95904256
törölt tag
Hali Rive!
Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997
Ezt hogyan? Per-core? Csodálkoznék...
Mit használsz? Utasításszám, vagy a performance-counterek?
Egyszerűen végrehajtottam rögzített mennyiségű utasítást (n) és a timestamp countert felhasználva megmértem hogy mennyi órajelre volt szüksége (t). Ebből számoltam ki az IPC értékét ( x = n/t ). Természetesen egy magon futott le az egész.
A mérés után megnéztem a K8 arhitektúra sematikus rajzát, ami alátámasztotta a fenti értéket. 3 párhuzamos utasításdekóder van benne.
Természetesen egyszerű utasításokat használtam ( FADD,FMUL,MOV,DEC,JNZ ).
[Szerkesztve] -
Raymond
titán
''A P4 azzal szúrta el, hogy az eleve lassú főmemória mellé egy nevetséges L1Dcache került. Itt a főmemória pöpec, de az L1 csak elégséges. Két szálnak kevés lenne. ''
Sebessegre vagy kapacitasra gondolsz? Ha nagyobb lenne vagy meg lasabb lenne vagy komoly valtoztatasokat igenyelne a front-end hogy a mostani 3 ciklust megtartsak.
Szerk: Az irasodbol ugy ertelmeztem hogy itt=K8 vagy K10.
[Szerkesztve]
Ki gondolta volna... (Az "FSB"-t miért kell emelni, ha BE?)
Sztem csak azért mondta, hogy jobban fogyjon most, ami van. 
Ú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.
- Apple iPhone 14 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- DELL, HP gyári töltők, sok db. 7,4x5mm - 4,5x3mm + USB-C/Type-C 65W
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- LG 27GP850P-B - 27" NANO IPS - 2560x1440 - 180Hz 1ms - NVIDIA G-Sync - AMD FreeSync - HDR 400
- Dell USB-C, Thunderbolt 3, TB3, TB4 dokkolók (K20A) WD19TB/ WD19TBS/ WD22TB4, (K16A) TB16/ TB18DC
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest