-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#95904256
törölt tag
Na, kicseréltem az összes helyen a célregisztert xmm0-ra. Várható hogy ez esetben az SSE egység pipe-jai majdnem hogy üresek lesznek, hisz mindegyik utasítás kénytelen megvárni az előzőt. Elvileg ha a 64 bites rendszerek képesek arra hogy az 1 órajellel előbb rendelkezésre alló 64 bites adattal rögtön műveletet indítsanak, akkor 0% (1 órajel) különbséget kellene tudni kimérni.
Megjegyezném hogy a Core2Duo az SSE összeadást 3 órajel alatt hajtva végre, így felreaktam egy MULPS és egy MULPD verziót is, ugyanis ez eleve 25% előnyt adna a Core2-nek.
ADDPS (C2D 3 órajel):[link] E4300: 3.000.808.746
MULPS (C2D 4 órajel):[link] E4300: 4.001.011.497
MULPD (C2D 5 órajel):[link] E4300: 5.004.196.407
[Szerkesztve] -
dezz
nagyúr
Hihi, akosf megtalálta a legjobb számokat.
C2D@~3GHz (FSB 1700) vs. P-D@3GHz (FSB 800): 1,79...1.92 - C2D@1866MHz (FSB 1066) vs. P-D@3,9GHz (FSB 1040): 1,8...1,95.
Amúgy, hát igen, a Core Duo-hoz kellene hasonlítani.
(#1109) akosf: ''A linkelt tesztben az L2 a Pentium-D-ben és Core2-ben is 2-2 MB magonként.''
De az utóbbiban közösített, ami egy kétszálas kódolásnál számíthat.
''Ezt a P-D 2x-es gyorsulás P4-hez dolog, ezt hogy kell értenem? Ezt senki nem állította. Arról volt szó hogy a 128 bites SSE hozott-e kétszeres gyorsulást vagy sem.''
Azért hoztam fel, mert ugye magonként kellene hasonlítani, azonban a P-D nem 2x gyorsabb, mint a megegyező órajelű P4, így talán a C2D-nek nem nehéz jóval gyorsabbnak lennie, pl. a közösített L2 és FSB által, kétszálas alkalmazásban...
[Szerkesztve] -
-
#1075
VaniliásRönk
nagyúr
P.H.
#1073
VaniliásRönk
nagyúr
Szerintem ugyanarról beszélünk, nyilván valamihez képest volt magas a Prescott fogyasztása, ha a K7/K8-nak is ilyen magas lett volna akkor senkinek sem tűnik fel.
Nade mennyi időbe tellt.
Egyébként absz. igazad van.
Raymond: Én itt egyedül arra reagáltam agresszívan, amikor azt próbáltad igazolni, azt se tudom mit beszélek, szerintem te is zokonvennéd ha valaki eljátszana veled valami hasonlót.
A teszt topikjában pedig szintén akkor támadtam, amikor személyeskedésbe csapott a vita, pl. rudi mindig képes normálisan betűbe önteni a mondanivalóját, nézd meg azokat a hsz-eket amiket neki címeztem.
fLeSs meg nálam a ''buzi-e vagy'' megjegyzésével ásta el magát már nagyon rég, ilyet még én se postoltam (és ha durva/bunkó is voltam, akkor is csak ''viszontválaszban''), pedig nem vagyok mod se, nemhogy házigazda. -
#1072
VaniliásRönk
nagyúr
P.H.
#1071
VaniliásRönk
nagyúr
A Prescottot azért említettem, mert azt a magas fogyasztása céltáblává tette, azóta törekszik erőteljesen mindkét gyártó kordában tartani a fogyasztást, nyilván az Intel azért tűzte ki azt a célt annó, mert akkor a fogyasztás még nem volt ilyen meghatározó szempont.
Nehezen tudom elképzelni hogy annyira rossz lenne a Conroe szervezése, olyan látványosan pazarolna, hogy ilyen áttervezésnek jelentős tere van, nagy fogyasztáscsökkenés lenne elérhető.
Szerk.: Mielőtt megint hülyeség leírásával vádolnak: #1070 végén természetesen 4 magnek kéne lennie (bár nekem úgy tűnik inkább 2x2 mint 4)
[Szerkesztve] -
dezz
nagyúr
Nézd csak ezt:
As of writing this Core 2 supports ld+ex and st(a)+st(d)
uOP fusion, and one load plus one store per cycle.
This suggests that at most two fOPs can show up for re-
tirement per cycle, plus another two uOPs.
I got a piece of code that can sustain the retirement of
two fOPs plus ~1.75 uOPs per cycle -- so I'm reasonably
certain of these limits.
[link]
(fOPs = fused uOPs) -
#95904256
törölt tag
Hali P.H.!
A hozzászólásomban ugye azt említettem hogy az inteles mikro-opok jóval egyszerűbb szerkezetűek lehetnek mint az AMD-s makro-opok, így egyszerűbb felügyelő/vezérlő logikát igényelnek. Azonban már kezdek ebben kételkedni. Az intel a ''mikro-op fusion'' kiaknázását tanácsolja az Optimization Manualban, illetve szép számmal akadnak single mikro-op utasítások is. Ezek szerint mégis egy rakás függőségi információt kell tartalmaznak a mikro-opok, tehát mégsem egyszerűek.
Az utóbbi pár napban a Core2 ROB-jával játszadozom az Intel vTune segítségével. Az már látszik hogy a ROB-ot nagyon nehéz teletömni ( ROB.FULL esemény ) egy valamire való, többé-kevésbé optimalizált kóddal. Egyelőre kérdés hogy azért mert a sok renaming miatt nehézen tudja csak tölteni a dekóderekból vagy azért mert az execution unitok elég gyorsak.
Megjegyzés: Egy SSE/SS2 FP számolásokkal teli, K8-ra optimalizált kód a Core2-re adaptálva ( csak az utasítás sorrend módosításával! ) közel 30%-ot gyorsult az eredeti változathoz képest. Az adaptált kód K8-on viszont csak alig lassult pár százalékot. Ez azt jelzi hogy az K8 ICU-ja meglehetősen jó munkát végez. Kár hogy futási sebességben a Core2-es optimált kód mintegy 87%-kal gyorsabban futott le mint K8-on az arra optimalizált, azonos órajelen. ( Az eredeti kód is gyorsabb volt Core2-őn (128 bit SSE engine ). ) -
ftc
nagyúr
Én ugy gondoltam,hogy van egy C forditot .Természetesen C-ben irod meg a progit.Leforditod a progit egy UInteles gépen és minden optimalizácio nélkül ráereszted egy AMD-re.Mit fog produkálni és forditva.Ez csak érdekesség képpen kérdem mivel legtöbbször ugye Inteles gépeken történik a forditás,hogy van e kihatással valamit is a teljesitményre.
-
#95904256
törölt tag
Valószínű hogy az Intel is look-up ol, csak spórolósabban. A 14 bites mantisszához elég egy 16kB-os ROM, illetve a kitevőhöz kell még egy 128 bájtos. Az SSE esetén elég 4kB/128. Egy iterátor áramkörnek legalább 1-2 szorzásra lenne szüksége, ami még ha egy ciklusos is ( 12 bites szorzó ) nem lenne gyorsabb a ROM-os megoldásnál, valamint helyet sem spórolna.
Az AMD illetve Intel eredmények közti különbség is a look-up tábla méretéből adódhat. Az RCPxS-nél a mantissza 24 bitjéből az alsó 12-ő törlődik, viszont az AMD-nek megvan a lehetősége hogy az utolsó megmaradó bitet kerekítse. -
#95904256
törölt tag
Reciprok letesztelve, tessék megkapaszkodni !!!
Teszthez használt CPU-k:
AMD X2 3600+ Windsor (1800@2400MHz)
Intel E4300 Allendale (1800@3200MHz)
Mérés:
31 bites prímszámok reciprokképzése
AMD 3DNow!, PFRCP 32 bit <-> FIDIV 80 bit
AMD SSE, RCPSS 32 bit <-> FIDIV 80 bit
Intel SSE, RCPSS 32 bit <-> FIDIV 80 bit
Mérés beállítások:
FPU, SSE: Kerekítés a legközelebbi egészhez, egyenlőség esetén pároshoz.
FPU: extended ( 80 bites ) pontosság
Eredmény:
Az esetek túlnyomó többségében mindhárom eredmény eltér egymástól.
Példa:
IEEE734 formátumú reciprok eredmények n=3 -ra.
AMD 3DNow!: 3EAAAA00 ( = 0,33332825 )
AMD SSE: 3EAAA800 ( = 0,3331299 )
Intel SSE: 3EAAA000 ( = 0,33325195 )
Hogy mindhárom eredmény eltért, nos ez erősen meglepett. Ezért a keresést kiterjesztettem az összes 31 bites pozitív egész számra. Ekkor jött a még nagyobb meglepetés, ugyanis a legnagyobb hibát az n=1 eset produkálta!
Maximális eltérések:
AMD 3DNow! : 0,00003051758 ( hiba = 1/32767 -> épp nincs meg a 14 bit )
AMD SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)
Intel SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)
Megjegyzés:
Az AMD SSE eredmények mikor eltértek az Intel eredményektől, mindig pontosabbak voltak.
Szerk.: A Newton-Raphson iteráció használható SSE esetén is, csak akkor manuálisan kell leprogramozni. Nem igényel több regisztert, csak eggyel több memória műveletet. Xb=Xa*(2-N*Xa), ahol Xa az N reciprok közelítő értéke. Ez egy körben megduplázza a hasznos bitek számát. Ami azt jelenti hogy az SSE 11 bites pontosságát nem lehet egy körben 24 bites mantissza méretre ( single precision ) interpolálni.
[Szerkesztve] -
#95904256
törölt tag
Ismerős dokumentáció. A végrehajtási időket nézegetve valóban úgy tűnik hogy az 1 darab 128 bites SSE művelet ( amit a processzor 2 darab 64 bites műveletként hajt végre ) azonos futásidőt produkál 2 darab különálló 64 bites 3DNow! művelettel. Azonban a 3DNow! kód ( ahol már program szinten két önálló utasítás van ) mérhetően gyorsabban fut le. A különbség nem drasztikus, csak néhány százalék.
Utána néztem a dokumentációkban reciprokos dolognak is.
3DNow! PFRCP pontossága: 14 bit
( AMD 21928 3DNow! Technology Manual )
Bár nekem néha csak 13 bites pontosságot sikerült kimérnem.
SSE RCPPS/RCPSS pontossága: |relativ.hiba| < 1,5*2^-12
( Intel 25366718 IA-32 Instruction Set )
Ez meg bizony csak 11-12 bitnyi pontosságot garantál.
Megjegyzés: Az AMD processzorok SSE reciprokképzés estén NEM a 3DNow! pontosságot hozzák. -
Raymond
titán
''Az én álláspontom szerint az x86-család fennállását »egyedül« a kompatibilitás tartja fenn (akár visszafelé, akár egymással).''
Az enyem szerint is mert egyszeruen igy van Es meg jo darabig igy is lesz mert nincs olyan masik architektura tobbe aminek meglenne az infrastruktoraja barmire is. Az eredeti x86 mar eleg sokat fejlodott es a kozeljovoben meg bovitik aztan lassan a legacy kompatibilitast megcsinaljak tisztan emulacioval mert annak aminek kell eleg lesz az emulalt sebesseg is. Foleg ha nem is nagyon lassu. Az x86 front-end mogott mar most is olyan hardver van aminek nem sok koze az eredeti CPU-khoz. Ezert ertelmetlen evek ota a CISC vs. RISC kerdes. -
#65675776
törölt tag
Ahhoz, hogy asztali fronton nincs IA-64 azért elég sok köze van a Microsoft-nak is. Kijelentették ugyanis, hogy nem fognak kétfajta 64 bites technológiát támogatni desktop vonalon. Itt viszont az AMD előbb jött, az intel meg kénytelen volt licencelni. Ahogy az NX bit-et is.
-
#95904256
törölt tag
Hali P.H.!
Miután jó egynéhány algoritmuson kipróbáltam a különbséget az SSE és a 3DNow! közt így nem nagyon tudnak meghatni egy harmadik fél dokumentációi alapján történő találgatások. Természetesen lehet találni olyan feladatot ahol az SSE több regiszterben tárolt adat miatt előnyben van (8x4x32bit vs. 8x2x32bit), viszont 3DNow!-ra is lehet találni olyan feladatokat amelyek a DSP jelegű utasítások révén élveznek előnyt.
A reciprokos dolgot meg próbáld ki... Igazam lesz... -
dezz
nagyúr
Pl. ''Inside Intel Core Microarchitecture. Setting new standard for energy-efficient performance'' white paper by Ofri Wechsler.
akosf: Az egyszerűbb vezérlő logika gyorsabb végrehajtást eredményez, vagy hogy érted? Vagy tranyószám/teljesítményben?
A Core2 a Pentium M-en alapul, ami - mobil proci lévén - spórolós design volt, főleg az aktuális csíkszélességhez képest (ami asszem 90nm volt). Aztán ezt némileg kibővítették, de csak annyira, hogy gyorsabb legyen, mint a K8. Viszont így maradt benne néhány szűk keresztmetszet. (Lásd alábbi linken, mik azok, magát a ROB-ot nem látom köztük.)
A K10-nél eleve a 65nm-hez (sőt talán már a későbbi 45nm-hez [értsd: 45nm-en lesz igazán gazdaságos]) alkalmazkodtak, azaz jóval kevésbé spóroltak a tranyókkal, vonalakkal.
[Szerkesztve] -
#95904256
törölt tag
Annyit megjegyeznék attól hogy az Intel CPU-k uop gyárak, nem jelenti azt hogy nem hatékonyak. Ezen uop-ok valamivel egyszerűbb szerkezetűek mint a konkurens makro-opok, így egyszerűbb vezérlő logikát igényelnek. A Core2-es 96 uop-os ROB-ja még ha szűk keresztmetszetet is jelent, azért jelentősen nem marad le a K8 72 makro-op-os ICU-jától. Ehhez hozzátenném hogy szeretnék látni egy olyan kódot ahol ez jelenti a szűk keresztmetszetet, ugyanis erősen párhuzamos (OoO) végrehajtás szűkséges hozzá. Más szóval egy ilyen limitet csak magas IPC értékű kóddal lehet elérni, ami még ritka.
-
dezz
nagyúr
Hát, ha még legalább konzekvensen a µop formát használná az Intel, az jó lenne, de állítólag egyes Intel doksikban a mikro-op formát használják. Bár ez még a kisebb gond, mert mikro-opban még valamennyire hasonlítanak egymásra, már ha nincs fúzió, de a ''makro-op''-jaik teljesen mást jelentenek.
''Prescott-tól talán ezt kiküszöbölték, a latency 1 lett, kérdés, hogy mennyi maradt meg ebből a Core-családra.''
Nem tudom, viszont a P4 vonalnak kevés köze van ehhez, mert a Core2 (a Core-on keresztül) a Pentium M-re épül (ami a P2-3-on kereszül a PPro-ra). ;)
Huh, nem sajnálták a tranzisztort és a területet attól a Massively Parallel Predecodertől...
Közben egy ilyet találtam a Core 2 predecodingjáról:
''7.15 Bottlenecks in Core2
Instruction fetch and predecoding
All parts of the pipeline in the Core2 design have been improved over the PM design so that the total throughput is increased significantly. The part that has been improved the least is instruction fetch and predecoding. This part cannot always keep up with the speed of the execution units. Instruction fetch and predecoding is therefore the most likely bottleneck in CPU-intensive code.
It is important to avoid long instructions in order to optimize instruction fetch and predecoding. The optimal average instruction length is approximately 3 bytes, which can be impossible to obtain.
Instruction fetch and predecoding is not a bottleneck in a loop that fits into no more than four aligned 16-byte blocks of code. The performance of a program can therefore be improved if the innermost loop has no more than 64 bytes of code or can be split into multiple loops that have no more than 64 bytes each.'' [link]
(Van itt szó másról is és más procikról is, érdemes átnézni.)
[Szerkesztve] -
Raymond
titán
''...de vajon az mennyi idő alatt, és hogyan végzi el a dolgát?''
Itt szovegertelmezesrol lehet sz. Az en verziom a kovetkezo:
''We find a very large block of logic with fourfold symmetry directly near the position were the 16 byte blocks of data are read and written from and to the instruction cache. We'll discuss the most likely candidate here, A fourfold incarnation of an earlier pre-decoder described in gate level detail in US Patent 6,260,134
This fourfold version can, according to the patent which describes it, pre- decode an entire line of 16 bytes in only two cycles by means of what it calls: massively parallel pre-decoding..........
..........The instruction pipeline may invoke the pre- decoding hardware in this case to initialize or correct the pre-decoding bits within only two cycles.''
En ugy ertelmezem hogy ket ciklus alatt vegez fuggetlenul attol hogy magatol tette a dolgat beolvasaskor vagy ahogy ott irva van ''something is wrong'' es soron kivul kell meghivni. Hosszabb vagy rovidebb ideig nem tarthat mert csak 16 byteos blokkal dolgozik. -
dezz
nagyúr
''''Early decoding produces three macro-ops per cycle from either path. The outputs of both decoders are multiplexed together and passed to the next stage in the pipeline, the instruction control unit.''
Na azért! Már kezdtem megijedni, hogy itt van egy érdekes szűk keresztmetszet, amikor megláttam a képet - de aztán arra gondoltam, ez nem lehet.
Meg akkor ugye az ábra fentebbi részein 1-1 makro-opról van szó valójában, csak eltérő számú aktív mikro-opot tartalmazhatnak.
''Ez vajon [fadd][fmul][---]-ra vagy [---][fmul][---], majd [fadd][---][---]-ra fordul?''
Hát ugye vagy az van, hogy a pre-decode egység figyeli a dependenciákat, és akkor a 2. eset van, vagy az ICU/ROB, és akkor talán lehet az első is. (Szóval a ROB küldené ki őket szépen egymás után.) Egy nagyon okos register-rename által jó esetben fel lehetne oldali a dependenciát (mintha Raymond írt is volna valami ilyesmit), de itt szerintem nincs ilyen, legalábbis nem látom, ebben az elrendezésben hogyan oldanák meg azt az esetet, ha erre éppen nincs lehetőség. -
dezz
nagyúr
Ha egy makro-opban az 1-2 mikro-op mellett az eredeti gépi kódú utasításra vonatkozó, ill. abból származó információk is vannak, akkor hogyan lenne lehetséges, hogy először csak a mikro-opok adódnak tovább, és csak később csatolódnak hozzájuk ezek az egyéb mezők? Mindez az információ megvan az egyes mikro-opokban is, tehát a makro-opokba rendezés végülis egy protokoll, ami arra kell, hogy segítse a reorderinget?
(Az ICU gondolom a ROB. Mit rövidítesz ICU-nak?)
Az ábrákon a Pack Buffer kimenetét 3 uOP-nak jelölik - az merült fel bennem, hogy ennek inkább 3 makro-opnak kellene lennie, nem? Nekem így lenne logikus. Máskülönben csak 1 uOP-os DirectPath (tehát nem Double) műveletekből jöhetne össze 3.0-át közelítő IPC, Double-ekből már csak max. 1, stb.
A 3.0 feletti IPC, mint már kiderült, nem lehetséges itt. Viszont az 1.0 feletti nem csak integer kóddal jöhet ki!
[Szerkesztve] -
Raymond
titán
''...egy decode elejére vonatkozó kérdés, hogy hogyan lehet egy órajel alatt több utasítás elejét/végét meghatározni.''
Ha jol ertettem akkor a pre-decode fazisban rejlik a megoldas. A leirtak alapjan a fetch-elt 16 byte adatot mar elore megjeloli mielott meg a scan/allign es onnan a decoderbe (direct es vector path) kerulnenek. [link]
[Szerkesztve] -
dezz
nagyúr
Huh, hát ez nagyon szép, hogy ilyen kimerítően kifejtetted. Megjegyzem, azt hiszem, jóval rövidebben is megértettem volna. De gondolom, ezt már nem is csak nekem írtad.
Viszont akkor lenne még 1-2 kérdésem. A sima (DirectPath) dekóderek kimenete 2 mikro-op széles. (Vagy itt is 2 makro-opot kellett volna írniuk esetleg?) Naszóval, ebbe beleértendő mindaz, amit írtál még az 1-2 mikro-op mellé (mármint az egy makro-opban)? Mert ugye ha nem, akkor további ciklusokba kerülne mindet továbbadni, ami ugye lehetetlenné tenné a 3.0-ás IPC-t.
A másik: akkor ugye az olyan összetett, nem dedikált egységgel egyben, hanem több lépésben végrehajtott utasítások, mint pl. sqrt, több makro-opra fordulnak (és nem pedig több mikro-opra, egy sorozatban)?
A CPI-s kérdésemre válaszolok magamnak. Szóval, mint az opt. guide-ban látható, a legtöbb ''multimédia'' utasítás is DirectPath-os, így a 3 sima dekóderen mehetnek keresztül, és a throughputjuk 2/1 vagy 3/1 is lehet (instr./clock). (Azaz, SSEx utasítások egy részénél megvan az 1.0 alatti CPI.) Amik persze VectorPath-osak, azoknál a legjobb eset az 1/1 - lenne, de inkább 1/''sok'' a rátájuk.
[Szerkesztve] -
dezz
nagyúr
Hmm, de hát ez nem úgy van, hogy az x86(/x87/SSEx) gépi kód a makro-kód, ill. makro-op-ok, és a dekóderek által fordított RISC kód a mikro-kód, ill. mikro-op-ok? Ezért ír a cikk is mikro-op-okat...
<1 CPI (clock per instruction): hmm, de hát ugyebár a 3 sima dekóder egyszerre mehet, és ha pl. 1 ciklusos műveletek vannak, akkor miért ne jöhetne ki az 1 alatti CPI? -
dezz
nagyúr
Ja, oké. Furcsa is volt, hogy csak 3 uOP széles a uCode Engine outputja, mert store-ral együtt már akár 4 uOP lenne (K8-nál meg akár 5). (Bár több lépésben is küldhetné a uOP-okat, de ez nem lenne túl hatékony.[*]) Viszont akkor nem értem, miért emleget a szöveg ''3 or more'' uOP-ot. Hogy jön össze K10-en 3-nál több?
[*] Mondjuk DirectPath esetén is ennek kell történnie, mert 2 uOP a sima dekóderek kimeneti szélessége. Nem?
Mindenesetre, a szöveg szerint a VectorPath utasításokkal csak a uCode Engine foglalkozik. Így nem nagyon lehet 1.0 CPI alá menni SSEx kódban. (Tényleg, az x87-es utasításokat tudják kezelni a sima dekóderek - annak ellenére, hogy adott esetben ugyanarra a uOP-ra fordulnak?)
Szerk: ''vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Lásd Athlon FX, és később Phenom FX vonal (socket F esetén): 2-procis rendszerek gamingre, videofeldolgozásra, stb.
[Szerkesztve] -
Raymond
titán
Az MP szeria (tobb mint 2 socket) mindig is draga volt mindket tabornal. Mondjuk az egyik elonye a Barcelona-nak platform szinten a plusz meg egy HT link. Ez benne is van az RWT cikkben.
Szerk: A koltsegek nem nagyobbak egyiknel sem (gyakorlatilag csak a merettol fugg). Csak a kereslet kicsi a ''jotallas'' a helyes mukodesre pedig szivos igy megkerik az arat. Ugyanaz a helyzet mint mondjuk a repulogep gyartoknal a kontaktok vagy mas komponensek. Sokkal tobbet fizetnek ertuk mint mondjuk egy autogyar pedig ugyanaz kapjak meg. Csak a garancia eonokkal nagyobb rajuk.
Az IBM LoadRunner persze Roadrunner akart lenni [link]
[Szerkesztve] -
dezz
nagyúr
Igen, már én is rájöttem erre a 3/(2+2+2)-re, miután elolvastam a vonatkozó részt (az egészet egyben még mindig nem
).
A szöveg szerint a VectorPath utasítások 3+ uOP-ból állnak (load, computation, store[, store]), és ezeket az a bizonyos uCode Engine fordítja, nem pedig a sima dekóderek. Így viszont elvileg órajelenként 1 ilyen (makro)utasítás indulhat.
Az a szövegrész, hogy K10-en már 1 uOP egy 128 bites SSE computation, vélhetően arra vonatkozik, 1 computation uOP van, tehát a loaddal, és 1-2 storral együtt 3 v. 4. -
P.H.
senior tag
Persze elrontottam, szóval a 2xxx CPU-k 2-300 dollárnál kezdődnek, 8xxx CPU-k pedig jóval $1000 felett. Amellett, hogy 8xxx 4/8-CPU-s rendszerekhez kell, vajon mennyivel nagyobb költség a megteremtésük (főleg a kimondottan egységesített gyártásfolyamat óta), mint egy asztali X2-nek?
[Szerkesztve] -
Raymond
titán
''Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Mindketto es ilyen sorrendben Ezt csinaljak mar a Mustang bejelentese es a K8 gyakorlatbani megjelenese ota. A szerver piacon tudjak megszorongatni az Intelt technikailag es teljesitmenyileg meg persze ott nagyobb a nyereseg kisebb eladott darabszam mellett. A technologia aztan lejon a mainstreambe is. Amit most csinalnak mar par eve az a platform ertekesitese nem csak a processzoroke. Opteron, Hyperstransport, Torrenza, Fusion es mind egybevag. 4 es 2 socket rendszerekbe siman verni fogjak az Intel megoldasokat mind teljesitmenyben mind osszfogyasztasban. A 1 socket rendszerben labdaba fog meg rugni az Intel foleg az integer teljesitmeny es az oriasi L2 cache miatt ami ezeknel a feladatoklan jol jon. Bonusz hogy most nagyon divatos a stream processing es ott megintcsak ott vannak a nyitott HT/Torrenza rendszerel (pl. Clearspeed koprocik) es jon a sajat megoldasuk ami miatt (is) az ATI-t megvettek. Ezen kivul az IBM ugyanezt hasznalja a Load Runner projektnel Opteron + CELL kombinacioval.
Sokan temetik (nem rad gondoltam) az AMD-t mert a 3DMarkXY nagyobb eredmenyt az egy Core2Duo-val de azert nem eszik olyan forron a kasat -
Rive
veterán
Ahogy én látom: az AMD a NetBurst ellenében azért tudott talpon maradni, mert amíg a NB egy erősen specializált architektúra, addig az AMD K7/K8 általános célú: szélesebb körben nyújt kiegyensúlyozott teljesítményt. (Igen, ez most az Intel Core indulásával eléggé megborult.)
Szerintem az AMD-nek továbbra is ehhez az irányvonalhoz kell tartania magát, ha talpon akar maradni.
SZVSZ minden egy mag megosztott erőforrásaira épülő HT erősen korlátozó tényező lenne ebből a szempontból. Hacsak a szűk keresztmetszeteket fel nem oldják valahogyan, pl. extra erőforrások beépítésével.
A másik megoldással kapcsolatban - az elágazások mindkét felének párhuzamos végrehajtása, majd az egyik szál eldobása - elvi számításról tudok, miszerint ebben a formában nagyon kevés gyorsulás várható tőle, aránytalan erőforrásigény mellett. Azt meg ne kérdezd, hogy ezt az elvi számítást hol láttam: már volt néhány éve. -
Raymond
titán
Hah, tudtam hogy varnom kell mert te sokkal ertelmesebben le tudod irni mint amit en kiizzadtam volna magambol
Nem is beszelve a plusz inforol...
A temahoz kapcsolodik ez:
[link]
Az oldal aljan vannak prezentacios slide-ok. Masodik sor elso kep ami a leirtakat szepen es egyszeruen illusztralja. Azon PR/Marketing slide-ok kevese koze tartozik ahol nem csusztat a gyarto mert nincs miert -
#95904256
törölt tag
Összesen 128 bájtot címezgettem, nem hiszem hogy a Data Cache lett volna a szűk keresztmetszet, de ezt csak egy hét múlva tudom letesztelni.
A ''4/8 bájtos utasítás'' alatt azt értem hogy az utasítás kódja ennyi bájtra fordult le.
szerk.: Majd kipróbálom XORPD XMM0,[DATA0] helyett XORPD XMM0,[ESI+00] formában, így kiderül hogy a data vagy decoder oldalról jött be a csökkenés.
[Szerkesztve] -
#95904256
törölt tag
Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.
Nekem van egy tippem, persze lehet hogy tévedek. De...
XORPD xmm,mem -> 1 órajel / utasítás ( 8 bájtos utasítás )
XORPD xmm,xmm -> 0,5 órajel / utasítás ( 4 bájtos utasítás )
Elvileg a Core2 x86 instruction predecodere 128 biten ( 16 bájton ) kapcsolódik az instruction cache-hez. A teszt kód 16 bájra volt illesztve, mégis, nem lehet hogy a decoder nem tudott két'' XORPD xmm,mem''-et 2x8 bájtról leképezni? -
Rive
veterán
Szerintem ezekből nem lenne észlelhető gyorsulás.
Régebben dolgoztam már perf. counterekkel, akkor még egy kínlódás volt az egész. Most, ahogy hirtelen utánakapargattam, már sokkal kultúráltabb a dolog. Szóval regisztráltam az AMD-nél és letöltöttem a vonatkozó szoftvert. Néhány nap/hét, és lesz valami hiteles kép a tényleges szűk keresztmetszetekről. Esetleg más is megpróbálhatná a dolgot.
A tényleges végrahajtás során előforduló valós szűk keresztmetszetek ismerete nélkül nem nagyon lehet megbecsülni, hogy ténylegesen mitől mehetne jobban egy proci. -
#95904256
törölt tag
Remek! Köszönöm.
Újabb ezernyi kérdésem lett.
Jöhet belőlük egy pár?
1, Mit jelent és miért jó az hogy az L2 Cache 16 utas?
Gondolom egyszerre 16 hozzáférési kérelem ( írás / olvasás ) irányulhat a cache vezérlőhöz, de honnan a fenéből jön össze ennyi kérelem?
2, Az AGU-k generálják a memória operandusok címeit?
Ebből az következne hogy pl. egy ADD reg,mem legalább 2 macro opból áll. Először lefut az AGU-n a memória operandus címképző macro opja, majd utána az ALU-n lefut az összeadás. Valamint a lebegőpontos/MMX egységnél az FSTORE végzi azt a munkát mint az integer résznél az AGU. Jól gondolom? -
#95904256
törölt tag
Hali P.H.!
Most aztán megvagyok keveredve, a szorzó és az összeadó áramköröket illetően.
Ezek szerint a műveletet ténylegesen végrehajtó egységek is pipe-oltak vagy csak az ütemező?
Ezt úgy értem hogy gondolom a tényleges szorzás nem 1 órajel alatt hajtódik végre ( rengeteg tranzisztort igényelne ), hanem közben több részeredményből tevődik össze, így vannak ''lépések''. Ezek a részeredmények haladnak egymás után, és ezt nevezzük pipe-nak?
Vagy úgy működik a dolog hogy van egy rakás különálló szorzó illetve összeadó és az ütemező amikor talál egy éppen nem foglalt egységet valamint van mit ''belepakolni'', akkor odaadja neki az operandusokat, az kiszámolja az eredményt ( 3/5 órajel ) majd elveszi tőle? -
Rive
veterán
- a decoder-ek »mögé« tennél egy Intel-féle nagyméretű trace cache-hez hasonló macro-op cache-t tennék, levenné a L1-ről és a decoder-ekről a sokszori felesleges munkát (pl. minden ciklus-lefutás újrafordítódik). Azt ne feledjük, hogy AMD-nél a 1x-stage pipe hosszának kb. felét teszi ki a fordítás macro-op szintre.
Huh. Korántsem vagyok benne biztos, hogy ez jó ötlet. Jelenleg az AMD az alacsonyabb frekin mozgó magokat használja. Ezeken a frekiken a dekóderek elegendően jól működnek. Egy trace cache nagyon sok extra tranyót jelentene: a disszipációt nem csökkentené.
Heveny emlékeim szerint a performance counterek segedelmével ellenőrizhető, hogy a pipe hányszor fogy ki a melóból a dekóderek késlekedése miatt. Szerintem ez a szám elenyésző, és olyankor is inkább a főmemória lassúsága a valós gond. Azaz SZVSZ a sebesség sem nőne.
- az elágazásbecslés-szempontú ugrásvégrehajtás mellett az előbbi prefix-szel együttműködve alkalmaznám azt a (például IA-64-ben implementált) elágazáskezelési technikát, amelyben spekulatívan mindkét ágat elkezdi végrehajtani, majd a kiértékeléskor az hamis ág utasításait eldobja. Igencsak megnőne az eldobott utasítok száma, viszont ugyanennyivel (összességében nagyban) javulna a megtartott utasításokok mennyisége a mostanihoz képest. Az micro-architecture elbírná szerintem ezt a többletnyomást.
Láttam erre vonatkozó számítást, aszerint sajna nem sokat hoz. A SUN shadow threadje jobb. Csak ott egy pöttyet durvább a memória-architektúra. Megvalósítható, de régebbi tapasztalataim szerint sok esetben kifejezetten a memória a szűk keresztmetszet.
- az egészet megfejelném a Hyper-Threading egy olyan megvalósításával, ahogy nem teljesen szimmetrikus a szálvégrehajtás, hanem az OS-től kapott prioritás mentén lenne egy főszál és egy mellékszál, ami a főszál által nem használt execution- és retirement sávszélességet használhatná. Azonos prioritási szinten természetesen szimmetrikus lenne.
Akkor viszont nincs értelme a fentebbi mókának. A hatékony HT egyik feltétele kifejezetten az, hogy legyenek munka nélküli VE-k.
Egy HT jó lehetne, de akkor mondjuk 4 integer VE/AGU, meg még két FP VE egy megnövelt L1 mellé. 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. -
#95904256
törölt tag
Hali P.H.!
Kipróbáltam a REP MOVSB, FSTSW illetve FCOS utasításokkal is a dolgot, miszerint a VectorPath felfüggeszti a többi utasítás dekódolását. Ez nem teljesen igaz. Valóban lelassul a dekódolás, de nem áll meg.
Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997 -
Raymond
titán
Az eddigi cikkek szerint lesz javitas par dologban amit felhoztal:
Elagazasbecsles
- 512-entry indirect predictor
- double size return stack
- tracking more branches (nem talaltam szamot)
Load/Store
''Barcelona can now re-order loads ahead of other loads, just like Core 2 can. It can also execute loads ahead of other stores, assuming that the processor knows that the two don't share the same memory address. While Intel uses a predictor to determine whether or not the store aliases with the load, AMD takes a more conservative approach. Barcelona waits until the store address is calculated before determining whether or not the load can be processed ahead of it. By doing it this way, Barcelona is never wrong and there's no chance of a mispredict penalty. AMD's designers looked at using a predictor like Intel did but found that it offered no performance improvement on its architecture. AMD can generate up to three store addresses per clock as it has three AGUs (Address Generation Units) compared to Intel's one for stores, so it would make sense that AMD has a bit more execution power to calculate a store address before moving a load ahead of it.'' -
dezz
nagyúr
Ha szemrevételezed pl. a #442-ben linkelt ábrát, ill. az 1-2-vel később linkelt ''magszerkezeti'' képet, láthatod, hogy 3db ALU van, és hozzá 3db scheduler is. Így lehetséges a 4 körüli IPC. Ugyebár ez a superscalar végrehajtás, ami az általános integer műveleteket illeti.
Azt nem tudom, most mennyire működhet egy időben az FMUL és FADD egység, illetve a többi, ami még ott van. De azt feltételezem, valamennyire igen. Ezt lehetne tovább bővíteni, ha több egység lenne, pl. 2-2 FMUL és FADD. Persze a ''körítést'' is bővíteni kell hozzá némileg.
Apropó, mint a ''magszerkezeti'' képen látható, az FMUL egység az x87 és SSE2 műveletek mellett a 2x32 bites 3DNow és SSE(1) műveleteket is elvégzik, tehát itt együtt van az 1-2-4x64 bit, és a 2x32 bit műveletvégzés. (Azt nem tudom, van-e az SSE2-ben 32 bites művelet, tehát 4x32 bit.)
Karakterisztika: akkor úgy látszik, itthon már rég óta így hívják, legalábbis x86 vonalon. Én csak 68k-ban utaztam, de arról sem olvastam soha magyarul.
ps. a többit majd asszem holnap, expressz meló van
[Szerkesztve] -
#95904256
törölt tag
Szerintem az OS programozóknak kellene figyelmesebbnek, felkészültebbnek lenniük, és nem a CPU gyártóknak kellene kézenfogva vezetni őket. Mert egyelőre csak az x87/MMX/3DNow! ... de aztán?
Jó, persze x87/MMX/3DNow! nem létszükséglet kernel módban, de az efféle ''korlátozom a szabadságod'' szemlélet nekem nem tetszik. Ezzel nem hibát szüntetnek meg, csak a hibalehetőségeket szűkítik. Ennek viszont van elegánsabb (szoftveres) módja is...
[Szerkesztve] -
dezz
nagyúr
''Lebegőpontos egységeket nem lehet csak úgy összekapcsolni, 32-64-80 biten más-más a karakterisztika és a mantissza mérete.''
Érdekes ez a karakterisztika kifejezés, régebben még kitevőnek hívták, plusz az előjelbit. Na szóval igen, ezt én is tudom. (Valaha még kézzel kódoltam sp fp rutint, 68k-n, az FPU-s korszak előtt, amiben a szorzást/osztást exponenciális táblázatok segítségével csináltam. Jó gyors is lett, csak az volt a bökkenő, hogy így az összeadás-kivonás jóval bonyibb, és így végül az vitte el az ide nagy részét. ) Szal természetesen úgy értettem, hogy amikor együttműködnek, máshogy kezelik az operandust.
''Aztán itt megértettem, hogy mit értesz superscalar x87 alatt. Nem rossz elképzelés, de az elvisz a MISD/MIMD irányába (Multiple Instruction, Single/Multiple Data), ez nem az asztali gépek világa. SISD/SIMD alatt órajelenként egy végrehajtó egységbe egy művelet léphet csak be. (Raymond #450)''
Hát, régebben a SIMD sem asztali dolog volt. De amúgy a MIMD és a superscalar végrehajtás két különböző dolog. Előbbi esetben eleve így MIMD-ben kell programozni (hacsak nem csinálja meg neked valami különleges fordító), utóbbinál meg a proci intézi. Mint ahogy az integer ALU-knál teszik is már jó ideje! Egyébként azt hittem, már most 2-way (vagy itt hogy írják) superscalar az x87-es végrehajtás is, és ezt lehetett volna 4-wayra szélesíteni. Ha az x87-et hanyagolják is a jövőben, a scalar SSEx végrehajtást szerintem még fogják majd superscalarosítani, mert nem várható, hogy ezentúl minden számítási kódot SIMD-ben írnak.
A #468-ban FPU alatt a korábbi x87 egységet értettem. De látom, ide sorolódik minden, ami fp.
A macro-op és micro-op-os dolgot eddig is értettem. Ugyebár a végrehajtó egységek ugyanazok, és az új, bővített regiszter-készlet is a rendelkezésükre áll. Nyilván ezért ösztönzik ezek használatára, ill. ilyen kódra való fordításra a programozókat. És Rajmund ugye valami olyasmit mondott, hogy 64 bites Win alatt már nem is támogatott a régi regiszter-készlet. -
#95904256
törölt tag
Hali P.H.!
Épp tegnap próbáltam az alábbi kódot egy K8 és egy Core2 magon:
(64 bit vs. 128 bit SSE)
cycle:
ADDPD XMM1,XMM0
ADDPD XMM2,XMM0
ADDPD XMM3,XMM0
ADDPD XMM4,XMM0
DEC EAX
JNZ cycle
A Core2 pont kétszer volt gyorsabb.
Fogadni mernék hogy ez cache-ben prefetchelt operandusok és más utasításokkal is működik. ( Na jó, MUL esetén 5 műveletet kell overlappolni a duplázáshoz. ) -
dezz
nagyúr
Visszatérve még erre:
''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier
- 1 db 80 bites adder/multiplier -> 1 db 80 bites adder/multiplier''
Nos ugye felvetettem, hogy ebben az esetben kihasználhatnák ezt az FPU kód superscalar végrehajtásában, 2+x telj. elérve (+ pl. a 2. 64 bites, ill. 2-4. 32 bites egység más-más utasítást hajthatna végre SSE-ben is), de erről nem szól a fáma. Talán itt a megoldás:![[kép]](http://images.dailytech.com/nimage/1644_slide_54.png "[kép]")
Nagyban: [link]
Ezen ugye az látható, hogy 1-1 egész - adott műveletet végző - egység lett 128 bites. 1x64 bitnél nyilván csak a fele működik...
Csak nem értem a 128 bites FADD-ot és FMUL-t, amik ugye sima FPU-s egységek.
Egyébként működhet egyszerre az összes egység? Gondolok itt kevert SSE+FPU kódra.
Ja, meg még egy dolog: ha csak 2 SSE egység van, és 4 órajel alatt végeznek, akkor effektíve 2 órajelenként lehet új műveletet indítani, nem? Közben asszem ''rájöttem'': 4-ből csak 1-ben van ide vonatkozóan használatban az egység, 1 a load, és 2 a store? Akkor már értem, mire jó a több portos cache.
akosf: Nagyszerű, de hogy lesz ebből 1.5x telj. (fp), azonos, vagy épp alacsonyabb órajelen?
[Szerkesztve] -
dezz
nagyúr
Miért nem jön ki a 2x-es sebesség (főleg, hogy 5 ciklus helyett 4 alatt megvan a 2x64 v. 4x32 bit), legalábbis egy egymás után csak SIMD utasításokat tartalmazó programrészben? Vagy úgy érted, ott kijön, csak nem lehet túl hosszan ezt csinálni, plusz ''etetni is kell'', így a gyakorlati telj. kisebb?
Apropó, ha 2x annyi lett a számoló egységek száma, miért nem szélesítették ki a scalar x87 kód superscalar végrehajtását ezekre is? Akkor az is szépen gyorsulhatott volna...
''Az lebegőpontos algoritmusok ugyanazok maradtak, csak megduplázták a számoló egységek számát.''
Persze, nem tudom, honnan vettem ezt a 128 bites (egy értéket jelentő) operandust.
''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier''
Hmm, külön vannak 32 és 64 bites egységek? Azt gondoltam volna, 64 bites operand esetén összekapcsolva működik 2 32 bites egység. Vagy ilyen esetben esetleg függetlenül működhetnek, más utasítást végrehajtva? (Nem látom ennek jelét mondjuk.)
''Ha skalár SSEx vagy x87 utasítást használsz, akkor ugyanaz a megfelelő méretű 0. sorszámú egység fog számolni, a feldolgozás sebessége azonos. Sőt, ugyanarra a micro-op-ra vetíti le őket a DirectPath decoder, csak a méret SSE esetén az utasításba van kódolva, x87 esetén pedig a FPU Control Word-ből veszi a méretet (az FLDCW tudomásom szerint sorbarendező utasítás még mindig). Csak ami skalár SSEx-ben 4/5 byte-os utasítás, az x87-ben 2 byte-os.''
Szóval, az x87 itt (illetve kb. 2 generáció óta) használhatja az összes fp regisztert? Korábban ugye volt valami olyasmi probléma, hogy kevés volt a reg, és állandóan a stackba kellett pakolgatni (nem ismerem az x86-os arch.-t ennyire, csak valaki valami ilyesmit magyarázott).
''A párhuzamosság miatt jogosak a 2x és 4x értékek x87-tel szemben, de ennyi van benne, pont olyan marketingszöveg, mint az Advanced Media Boost, ami gyakorlatilag pont ugyanezt a szélesítést jelenti a másik oldalon.''
Azért pl. a C2D is elég szépen gyorsult tőle, 4x32 bit v. 2x64 bit SIMD-ben közel kijön a 2x-es seb., azonos órajelű P-D-hez képest. (Csak mondjuk a C2D nem megy akkora órajeleken gyárilag.)
Azt hiszem, itt azért látványosabb lesz a dolog, mert megvan az órajel, sőt magasabb is a K8-nál szokásosnál.
[Szerkesztve] -
Raymond
titán
Itt ez a sok doksi de meg nem vilagos hogy peldaul az orajelenkent elvegezheto 64bit SSE utasitasok is megduplazodnak e vagy nem a K8-hoz kepest. Mert a 128bit megduplazodik, de volt egy GDC2007-es AMD prezentacio es abban az volt hogy a 64bit nem. A PDF-bol amit kiolvastam viszont az jon le hogy igen.
-
dezz
nagyúr
Mint írtam, az idézet ugyanabból a bekezdésből van, a #409-ben linkelt DailyTech cikkből, ami egy bizonyos AMD-s illetővel készült, német lapban lehozott interjún ([link]) alapul. De úgy tűnik, a DailyTechesek félreértették az eredeti szöveget. Ime Babelfishes fordításban az ide vonatkozó rész:
''How admits already sufficiently is, AMD introduces with the K10 a third Cachelevel. This L3 Cache together can access all cores, while they have dedicated L1 and L2 Caches. Lie if those need data in the L1 Cache, can CCUa core them directly load. This functions also, if they lie in the L1 Cache of another CCU. In this case communication runs again over the CROSS bar. If the data lie in the L2 Cache, they are gotten into the L1 Cache and deleted in the L2 Cache. If the data lie in the L3 Cache, they can be loaded directly into the L1 Cache, without a detour over the L2.
If the L1 Cache is full, the oldest data are written there again into the L2 Cache, are this also fully, into the L3 Cache etc. into main storage. In contrast to the L2 Cache data loaded by the L3 Cache are not obligatorily rejected. Assistance of a Shared bit can mark the CCU core-spreading used data, it is then also to different cores at the disposal.''
Ez már egybe cseng a doksival:
''A.5.4 L3 Cache
The AMD Family 10h processor contains an integrated L3 cache which is dynamically shared between all cores in AMD multi-core processors. The L3 cache is considered a non-inclusive victim cache architecture optimized for multi-core AMD processors. Blocks are allocated into the L3 on L2 victim/copy-backs. Requests that hit in the L3 cache can either leave the data in the L3 cache—if it is likely the data is being accessed by multiple cores—or remove the data from the L3 cache (and place it solely in the L1 cache, creating space for other L2 victim/copy-backs), if it is likely the data is only being accessed by a single core. Furthermore, the cache features bandwidth-adaptive policies that optimize latency when requested bandwidth is low, but allows scaling to higher aggregate L3 bandwidth when required (such as in a multi-core environment).''
Naszóval, akkor azt mondod, hogy a másik mag L1-éből a L2 és L3 megkerőlésével, közvetlenül a crossbaron keresztül, a kérő mag L2-jét is megkerülve, kerül az adat a kérő mag L1-ébe. (Nem lenne olyan nagy ''csoda'', tekintve hogy mint írják a L1 és L3 között is van közvetlen kapcsolat, a L2 kihagyásával.) Nos, egy másik fórumon tanakodtunk erről, és én is pont ezt vetettem fel (oly módon megfogalmazva, hogy a crossbarnak vannak közvetlen vonalai a L3/L2 fölé is), mire majdhogynem lehülyézett valaki.
De akkor mégis így van. (Kivéve, ha több mag is írja/olvassa, mert akkor a L3-ba kerül, és ott is marad.)
[Szerkesztve] -
dezz
nagyúr
''Tehát nem lehet beleírni az L3-ba, mert oda csak azok az adatok kerülnek, amik »helyhiány« miatt kerülnek ki az L1-ből.''
Az L3 már más: ''The L3 Cache, however, is not exclusive, but allows for a shared bit to be set. If a core loads data marked as shared, it will reside in the L3 cache and can be fetched by other cores as well.'' (Dailyteches szövegből, ua. bekezd., de a pdf-ben is benne van.)
Eszerint tehát a L3-on kersztül megy. De akkor hogy jön ide a crossbar?
Ez olyan 640kB memória mindenre elég tipusú kijelentés. 
).
![[kép]](http://www.beer-pages.com/images/heineken-case.jpg "[kép]")
De akkor mégis így van. (Kivéve, ha több mag is írja/olvassa, mert akkor a L3-ba kerül, és ott is marad.)Ú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.
- BestBuy topik
- gban: Ingyen kellene, de tegnapra
- Építő/felújító topik
- Eldurvul a Nova Lake-kel az Intel-féle hibrid dizájn
- Formula-1
- Vírusirtó topic
- Újabb európai vasúttársaság vált műholdas internetre
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Milyen autót vegyek?
- Autós topik
- További aktív témák...
- Intel Core i9-14900KF 24-Core 3.2GHz LGA1700 Box (BX8071514900KF) Processzor! BeszámítOK
- Ritkaság! Csere-Beszámítás! Intel I9 13900KS Processzor!
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
- ÚJ Intel Core Ultra 5 245KF 4,2GHz 24MB LGA1851 BOX 3év
- Ryzen 7 8700G /// Új, csak kipróbált // Számlával és Garanciával!
- Bomba ár! Lenovo ThinkPad P43s - i7-8G I 8GB I 256GB SSD I Nvidia I 14" FHD I Cam I W10 I Garancia!
- BANKMENTES részletfizetés ASUS TUF F16 FX607JV-QT212 Tesztvideó a leírásban Nézd meg működés közben
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 16 Pro Max - Desert Titanium - 256GB 1 ciklus 100% akku! 1 év garancia! Új készülék!
- Csere-Beszámítás! MSI Suprim X RTX 3080 10GB Videokártya!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest