- One mobilszolgáltatások
- Fotók, videók mobillal
- Apple Watch
- Bemutatkozott a Poco X7 és X7 Pro
- Csak semmi szimmetria: flegma dizájnnal készül a Nothing Phone (3)
- Google Pixel 9a - a lapos munka
- Apple iPhone 16 Pro - rutinvizsga
- Okosóra és okoskiegészítő topik
- CMF Buds Pro 2 - feltekerheted a hangerőt
- Milyen okostelefont vegyek?
Aktív témák
-
Power
senior tag
''Persze, mindenki abban hisz amiben akar. De teveszmeid neked vannak. Eleg sokminden osszegyult mar az elozo hozzaszolasomban, amit te mondtal es hulyeseg. Csak sorolom:''
Inkább hagyjuk a személyeskedést.
''1. Attoltesek nem lassitanak semmit''
A register renaming lassít?
Ez csupán az L/S egységek számától és végrehajtandó utasításoktól függ.
Ha nálad lassít, akkor:
a.) rossz a kódod
b.) rossz processzort használsz
Elméletileg semmit nem lassít.
A hozott példádat meg nem lehet önmagában lemérni, szóval kiváncsi lennék hogy hogyan sikerülhetett.
Ciklusban pörgetve már az átlapolódástól illetve a ciklustól már egész más a környezet, szóval torz képet ad.
A mov és az add ott is mehet egyszerre, tehát ott sem lassít.
''2. Intel&AMD ellenjavalja az assemblyt''
Ez a hivatalos álláspont.
''3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval''
Te folyamatosan kevered az utasítást és műveleteket.
Te a RISC-re írtad, hogy gyorsabb, mert 3 operandusúak az utasítások, én csupán ezt cáfoltam.
''4. Memoria operandusu muvelet regiszteresre helyettesitodik''
Pontosan. Milyen mikroutasításokat ismersz amelyek memóriacímeken végez pl. aritmetikai műveleteket.
''5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel''
??? Ezt te írod. Én ilyet nem írtam, csak annyit hogy itt sem a minnél több a legjobb.
''6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.''
Ezt megint te írod. Én csak, azt írtam, hogy a több nem biztos, hogy jobb.
''7. Risc compilert nehezebb irni, mint cisc/vliw compilert.''
??? Ember te folyamatosan ferdítesz!
Én azt írtam, hogy nem könnyű RISC-re sem:
''Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani''
Nem tudom ebből honnan veszed, hogy vliw-re, vagy cisc-re milyen?
Egyébként el vagy tévedve, ha az x86-ot cisc-nek tekinted.
''Risc compilert egyszerubb irni. Egyforma az utasitasok hossza. Ugyanarra a feladatra nincs tobb megoldas, mint a ciscnel, nem kell gondolkozni, hogy melyiket valassza a compiler. Egyszerubb a cimzes. stb. ''
Nem tudom honnan jön ide az egyforma utasításhossz vagy a többfajta címzés???
Nem a compiler működőképességében van a munka, az 1-2 hét alatt összehozható. Hanem hogy optimális kódot fordítson, na ahhoz sok-sok év kell.
x86 esetén sincs több megoldás, elégg rég óta 1 féle megoldást fordítanak adott feladatra. Tulajdonképp a RISC is emiatt fejlődött ki, ugyanis az akkori jó CISC fordítók is egyfélét fordítottak.
Egyébként a mai RISC-eknél sincs már egyforma utasításhossz.
Egyszerű címzés? pl. PA-RISC egyszerre támogatja mindkétféle endian-t.
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt elküldöm az inteleseknek, ők is szórakozzanak egy kicst :)
''Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz.''
Figyelj vegyél kicsit vissza újoncstílusodból!
''Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel.''
Mondod ezt az együgyüség magabiztosságával.
''Sokkal egyszerubb azt mondani, hogy 'nincs idom'.''
Valóban nincs sok időm, ugyanis dolgozom, értelmes emberekkel, értelmes célokért és még sok pénzt is kapok érte.
Szerinted vitatkozzam inkább veled, eredménytelenül??? :)
A június végén megyek az USA-ba és találkozom többek közt John Crawforddal(gyerünk nézd csak meg a Google-ba kicsoda az ürge), majd megemlítem neki a gondolataid. -
Power
senior tag
''Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake.''
Ne gyerekeskedj!
Az IBM vagy a SUN esetleg az Intel szerver részlege szerinted a quake-re tervezi a processzorokat???
''Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.''
A P4EE egy áttokozott Xeon.
''Ha programoztal volna assemblyben, tudnad, hogy x86 felulirja az egyik operandust, es ha kesobb szukseged van ra, akkor extra utasitassal kell elmenteni (rosszabb esetben memoriaba). Attoltes lassit, probald ki. Ha nagyon kotni akarod az ebet a karohoz, mutass peldat, amikor nem lassit, szivesen lemerem''
Mire?
Te írod állandóan, hogy gyorsít. Én ezt vitattom. Írj te, hogy hol gyorsít ez?
A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.
Felejtsd már el ezt a kézi optimalizálást. Mind az intel, mind az Amd ellenjavalja az assembly-t. Egy 386-os vagy egy P2-es esetén használhatsz, de 2004-ben már csak magadat fogod szívatni.
''Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.''
''Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent. Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas.''
Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.
''Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Fogalmad sincs róla. :)
''Masreszt a register renaming nem helyettesiti a tobb regisztert. X db regiszterben nem tudsz X+1 adatot tartani, errol szol az egesz. Ki kell irni membe (ami szerinted regiszterbe irasra helyettesitodik??? Vicces). Membe iras (level 1 cachebe is) lassu.''
Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?
''Ez megint hulyeseg. Mutass 2 processzort, amik csak a cache mereteben ternek el egymastol, es amiben a kisebb cache van, az gyorsabb. Nagyon kivancsi vagyok.''
1. Több processzoros környezetben a kozisztencia problémák léphetnek fel és egy túlméretezett cache visszafoghatja a rendszert.
2. Gyártási problémák - túlontúl nagy cache -> rosszabb kihozatal, alacsonyabb órajel
''Nem, csak te hiszed, hogy ezeket szet kell valasztani. Annyirol volt szo, hogy szetkapja az ember a legfaszabb x86 processzorat, a riscszeru magot megtartja, rak bele tobb regisztert es nehany uj utasitast (3-4 operandusut), es gyorsabb lesz a proci. Igen, van, ahol az osszetett muvelet miatt, van ahol azert, mert nem irja felul az operandust, van ahol azert, mert nem kell kiirni membe. Tok mind1, gyorsabb lesz.''
Tudod mi az az MMX/SSE/SSE2?
''Tegyel egy probat. Irjal egy akarmilyen c proggyt, forditsd le, aztan nezd meg a kodot amit kaptal. Latni fogod, hogy tele van olyan reszletekkel, amikor adat kiirodik membe, aztan visszaolvasodik. Ugye mondanom sem kell, hogy membe irni (level 1 cachebe is) jopar orajel. Szal 5% az 100 orajelenkent kevesebb, mint 1 ilyen. Szerintem tobbet fogsz talalni.''
Micsoda???
Látod a mikro kódot? Látod a futásközbeni átrendezést?
Felejtsd már el az x86-os opcode-okat, totál más zajlik a háttérben.
''Kerdezd meg az ismeroseidtol, hogy riscre vay x86-ra konnyebb compilert irni. Nyilvan riscre. Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le. -
kisfurko
senior tag
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt lemérted? Érdekelne. Manapság nagyon sok szabályra kell figyelni. P6 óta már nem vagyok biztos abban, hogy jobbat írunk kézzel, tekintve, hogy nem publikus a belső.
Sajnos nincs intel compilerem (csak májkroszoft), szóval nem tudom kipróbálni.
''''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Én el tudom képzelni, főleg, hogy a P4 már lefordított kóddal dolgozik. Simán meg lehet különböztetni fix és változó címeket.
Régen én is hasonlóan gondolkoztam...:))
Igaz Power?
[Szerkesztve] -
Power
senior tag
''Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.''
Nem a xeon-okról volt szó, hanem a RISC-ek 1 illetve több processzoros példányai között. A XeonMP pedig igeni gyorsabb azonos órajelen, mint a sima P4.
Nyílván a Xeon-oknak a megbízhatóság miatt nem hajhatják olyan magasan, de 3 GHz-es XeonMP már van.
SPECint2K peak:
Xeon - 3,2GHz - 1563
XeonMP - 3,0GHz - 1408
P4 - 3,4GHz - 1393
Ez alapján még az alacsonyabb órajel ellenére sem lassabb, sőt.
''Nem tudom ertelmezni amit irtal, hogy ugyanolyan gyorsak. PPC-t nem tudom, de szerintem mind dual procira van tervezve, A64 meg multiprocira, szal nincs beloluk single-re tervezett, nem?''
Ebből a szempontból tökmindegy.
''Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent.''
Te ezt honnan veszed, hogy én mit csináltam és mit nem? :))
Kis naiv. Már rég egész más hajtódik végre, mint amit te látsz az x86 opcodok alapján. Az áttöltések nem lassítanak semmit, csak plusz tranzisztor kérdése, regiszter átnevezés az egész. Semmit nem gyorsít.
''Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas. Probalj egy a*b+b*c+c*a kifejezest kiszamitani 2 es 3-4 operandusu muveletekkel, es latni fogod, hogy melyik a gyorsabb. ''
Barátom te keversz valamit! :)
Itt nem a 4 operandus miatt gyorsabb, hanem azért mert kétműveletet hajt végre a VE. A három operandusú műveletek: a = b + c, ez a klasszikus RISC.
''Szukseg van tobb regiszterre, megint azt tudom mondani, hogy latszik, hogy nem programoztal assemblyben. De tekintsd pl. ugy, hogy a regiszterek a 0. szintu cache, minel tobb van, annal jobb. Kulonben ennel nyilvanvalobb dolgot, hogy az x86 architecturaban keves a regiszter, nem is lehet talalni. Te ezt komolyan cafolni probalod???? Ja, taskvaltasnal trade-off van, ezert van optimalis meret, nem kell ezer regiszter. Eleg mondjuk 32.''
Már megint feltételezgetsz? :)
Az x86 is van elég regiszter nem csak az amit az opcode-ból látsz. Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.
A 32 nem elég, de ennyi van az x86.
Ha jól emlékszem a P4-ben 128 entry-s a regiszter file.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
''Ez igaz, ilyenkor a l1 cache-be toltest lassitja.''
Nem mert könnyen párhuzamosítható. Az L1-L2 között késleltetés pedig még így is lassú - 10-30 órajel.
''3. Latod, hogy tudtam. 3 operandusu muvelettel es tobb regiszterrel. Illetve igazabol 'felesleges' utasitasokat sporoltam meg ezekkel. Egyebkent nyilvan nem az IPC fog vissza, az csak meri a proci egy jellemzojet, nem meghatarozza''
Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.
''Nemnem. A peldam jo, egy csomo tranyot kidobtam, amikor csak a magot tartottam meg, par regiszter meg par utasitas siman kitelik belole. Es forditot csak x86-ra meg itaniumra nehez irni, riscre sokkal egyszerubb, ez is egy elonye, csak eddig errol nem volt szo, mert nem a hardverhez kapcsolodik.''
Abban biztos vagyok, hogy még nem írtál compilert. :)
Én sem, de sok olyan embert ismerek aki igen. Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani.
''Amugy eddig azt magyaraztad, hogy risckel kozelebe se jutok az x86-nak, mostmar visszakoztal, hogy szignifikans kulonbseget nem tudok osszehozni. Egyreszt ez a nem szignifikans kulonbseg szerintem akar 20-30% is lehet ''
Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam :)
''(ki lehet probalni G5-on csak 4-6-8 regiszter hasznalataval mennyivel lassabb kodot lehet irni, es amikor rajossz, hogy hoppa, ki kell irni a memoriaba az adatot, mert nincs tobb regiszter, akkor kiderul, hogy mennyit lassit), masreszt mivel kidobtam a procibol egy nagy reszt, valszeg magasabb orajelet is el lehetne erni, harmadreszt ez 0 uj otletet tartalmazo megoldas, szal ha meg 1-2 evet belefektet az ember a tervezesbe, nyilvan egyeb gyoritasokat is kitalal, es nem csak egy siman lemasolt procit krealna''
A G5 alatt a PPC970-et érted?
Ez ilyen visszafele bizonyítás? :))
Na mindegy, nem akarok semmi bántót írni. -
Power
senior tag
''Persze, a tobbiek is okosak. De mondjuk azok mas celu processzorok, szal nem gondolnam, hogy az osszehasonlitas valamennyire is erdekes. Szal egy olyan procit, ami csak single proc uzemmodban mukodik, nem erdemes egy olyanhoz hasonlitani, ami 64 procis kornyezetben is mukodik.''
Egy olyan processzor ami sok proci környezetre terveztek nem lassabb, mint amit ugyanabból egy procis környezetre terveztek, sőt mindegyike gyorsabb.
Ugyanolyan célú processzorok pl. egy PowerPC970-es, mint egy P4 vagy egy A64. Ezek kb. mindegyike ugyanolyan gyors(mindegyik másra van kihegyezve).
''Fejtsd ki legyszi, hogy milyen elvi oka van, hogy egy risc proci gyorsabb legyen, mint egy p4. Kulonosen, mert hiszen tudjuk, hogy belul riscszeru magja van, szal igy mar lehetne rogton olyan procit csinalni, ami ugyanilyen gyors, es risc, ha ennek a magjat vesszuk (igaz, az nem x86 kompatibilis). Megszorjuk meg par 3 operandusu utasitassal ill. sok regiszterrel, es maris gyorsabb (es meg az utasitasok mikroutasitasra bontasat is megsporoltuk -> rovidebb pipeline, vagyis egy pipeline stall koltsege kisebb -> meg gyorsabb). Tessek, ez egy recept a gyorsabb risc procihoz.''
Neked ez rögeszméd, hogy ha 3 operandusos utasításaid vannak attól máris gyors lesz minden? :) Ezt honnan veszed?
1. Nincs szükség sokkal több regiszterre, threadváltásnál megfogná a rendszert.
Van egy optimális méret aminél nem érdemes többet belepakolni, túl sok tranzisztort emészt fel, az egészben és itt nem csak a több registerfile-ra gondolok.
2. A mikroutasításra bontás már az L1 cache-be töltéskor megtörténhet, úgyhogy nem kell, lassítson.
3. Az IPC-t nem tudod növelni, ha megszakadsz se egy RISC-el sem márpedig ez ami visszafog. A függőségek illetve az alapblokk hossza adott.
4. A memória késleltetéssel sem tudsz mit kezdeni.
Lehet izmozni, de szignifákns különbséget nem fogsz tudni elérni RISC-kel sem, viszont annál több munka van vele + sok extra tranzisztor.
Manapság nagyon komoly elemző munka előzi meg egy processzor tervezését. A jó fordító írása még egy RISC-re vagy x86-ra is évekig, márpedig annélkül nem ér sokat a leggyorsabb vas sem. -
Power
senior tag
''Bocs, felreertettel. ''Helyesen 'nem x86''' alatt azt ertettem, hogy amikor eddig arra hivatkoztam, hogy a risc mennyivel jobb, stb., az azt jelentette, hogy a 'nem x86' mennyivel jobb.
Nem hiszem, sokkal jobb lenne. Eddig egyetlen jo erv nem volt a mellett, hogy az x86 miert lenne az abszolut sebessegkiraly irany (nem is az). Persze, az Intel meg az AMD mernokei fasza csavok, es mara nagyon kiraly procikat hoztak ossze. (Nagyon sok penzert, amin sokkal gyorsabb nem x86-os procit lehetett volna fejleszteni). Igen, a kompatibilitas a legnagyobb ertek, ezert is mehet a sebesseg rovasara.''
Jelenleg a SPECint2K szerint a P4EE a leggyorsabb.
Figyelj sem az IBM-nél, a HP-nél, sem a SUN-nál sem hülyegyerekek tervezik a processzorokat. Nekik sem nagyon sikerült, ráadásul az utóbbi kettő még dual core-ral is nehezen hozza a P4 sebességét.
Nem hiszem, hogy akármilyen risc architechtúrával gyorsabb lehetne.
Ennek elvi okai vannak és nem technikai.
Az 1 threades IPC-nek elvi korlátait nem lehet átlépni a mai risc/x86-tal, a vliw/epic-kel igen, de ott meg a fordító írása bitang nehéz.
''Igen, Itanium teljesen mas megkozelites. Miert csinaltak igy, es miert nem x86 az is?''
A 80-as évek elején megjelent risc és superskalár ez a 90-es évek elején már látszottak a korlátai ezért fordultak a vliw felé. Most pedig a 2000-es évek elején ugyanez lesz a CMP. Aztán megint jön vmi.
''Mert megprobaltak valami gyorsat csinalni, es ugy gondoltak (ahogy en is, de te nem), hogy azt nem x86 alapon lehet megcsinalni.''
Pontosan, de ebből a szempontból az x86-ra ugyanígy igaz, mint a risc-re.
Én csak azt vitattom, hogy gyorsabb RISC magot lehet építeni, mint x86-ot. Lehet nagyon egyszerű RISC magot építeni, de a mai RISC-ek már egyáltalán nem azok. -
Power
senior tag
''Ez a ketto osszefugg. Az x86 processzorok (a kompatibilitas miatt) ossze-vissza allitgatjak a flageket, es emiatt szopatjak a pipelinet (illetve a branch predictiont). De errol mar volt szo korabban. De nezd meg pl., hany orajel kell a flag allito utasitasokhoz (pl. shift, rotate).''
Nem probléma a teljesítmény szempontjából.
1 órajel kell az a használatos rotate és shift utasításokhoz.
Vannak bizonyos utasítások amit már évek óta kifejezetten ellenjavalott használni, de aki sz*patni akarja magát az használja, mindenesetre a magas szintű nyelvek compilerei nem használják. Az, hogy nem vették ki az ISA-ból az pedig érthető.
''Hulyeseg, hogy mindig riscet mondunk (mondok), amugy helyesen 'nem x86'''
Az IA-64 nem risc :)
A transmeta sem.
Sőt egyébként a mai risc-ek sem felelnek meg a klasszikus értelembevett risc definiciónak.
''Hogy ne legyen felreertes, mar mondtam ugyan, szal nem arrol van szo, hogy a mostani x86 procik szarok, eppen ellenkezoleg, de sokkal faszabbak lennenek, ha nem x86-ok lennenek''
Hidd el nem lenne sokkal jobb.
A mai risc-ek eleve 32 bitesek voltak, de ma már 64 bitesek. Nekik is meg van a maga 32/64 bites nyűgés.
A kompatibilitás sokkal nagyobb érték, mint bármi más.
''Meg az itanic is jo pelda erre, az Intel szerint is szopat az x86 architectura, az itanium nem is arra van optimalizalva.''
Az itanium teljesen más megközelítés. A risc és cisc sokkal közelebb áll egymáshoz, mint az epichez vagy a vliwhez.
Az epic-et nem az intel találta ki, már több, mint 10 éve masszírozzák, mert már akkor látszottak a risc és x86 problémai.
[Szerkesztve] -
Power
senior tag
''Azert egy riscben egyszerubb a flag kezeles''
Aligha. Egyébként ezt kifejthetnétek bővebben konkrétan mire gondoltak. Mi egyszerűbb benne és miért?
''masik hasonlo cucc a szazmillio fele ugro utasitas.''
:F
Feltételes vezérlés átadás a RISC-nek is szerves része.
Vagy mire gondolsz? -
Power
senior tag
''1. Nyilvan arrol van szo, hogy egy hasonlo teljesitmenyu risc proci kevesebb tranzisztorbol all, mint egy cisc vagy vliw stb.''
Ez mondom már mióta, hogy nem igaz!!!
''USP-IV - ez 2 USP-III corebol all''
Telejesen mindegy - 2 core, de az 1 processzor gyártási szempontból és itt erről beszéltünk.
''az USP-III-ban a logic 11 millio tranzisztor''
Az L1 szerves része a core-nak.
''PA-8800 - ez ugye ket PA-8700-as corebol epul fel +cache, a core-ok 25 millio tranzisztorbol allnak''
Mivel ezekben csak L1 van ezt simán hozzáadhatod a core-hoz, de még annélkül is baromi sok. Az Itanium2 core-ja(cache-ek nélkül) kevesebb, mint 25 millió tranziszort tartalmaz és csak 1 core van a chipen.
''Tobbirol nem talaltam egyertelmu adatot, ha te talalsz, legyszi ird ide.''
Azért nem nagyon, mert mint írtam az L1 a core része és nem is adják meg nagyon külön.
A 64 bites háborús topik indító cikkében:
[L]http://www.realworldtech.com/page.cfm?ArticleID=RWT042704221446[/L]
Itt az ábra közel méretarányos.
Itt látszik, hogy egyáltalán nem lehet azt mondani, hogy a madison nagy lenne, főleg nem a core-ja.
A Montecito-val már más a helyzet, de a core ott sem lesz olyan nagy.
Itt nem szerepel az USP-IV+, a PA-8900 vagy akár a Niagara amely szintén nem lesz pici.
Az látszik, hogy az IA-64 chipek nagyrésze az L3. Egy fejlett busszal jócskán kisebb L3 is elég lehetne.
Továbbá: az USP és PA-RISC-ekhez külső cache chipek kellenek!!!
Ugyanígy a Power-ekhez is. Az Itanium-nál belenyomták, mert a kis core miatt belefért. -
Power
senior tag
''1. Egy risc proci kisebb (most a cacheket hagyjuk). Mitol lenne nagyobb?''
Melyik???
A risc nem azt jelenti, hogy kisebb vagy jobb :)
Az USP-IV illetve a PA-8800 majdnem akkora, a Power5 pedig picivel nagyobb, mint a Madison. Ha a cache-eket hagynánk, akkor a Madison még kisebb lenne hozzájuk képest.
''2. Ha minden egyforma (technologia, csikszelesseg stb.), akkor ugyanazert a penzert a kisebb lapkameretubol tobbet lehet gyartani.''
Ezek mindegyikénél ugyanaz a csíkszélesség.
A másik meg az, hogy nem mindegy mi van benne, nagyban függ attól, hogy mennyire egyszerű a gyártás vagy sem. A méret csak 1 dolog.
''Mar volt szo rola, de nem ugyanazok a gondok. Pl. egy risc procinal nincsenek olyan nagy gondok, mint az x86 pipeline szopato flagallitasai. Szerintem ha riscet fejlesztettek volna, akkor mar most 4-5 gigahertznel tartananak, es teljesitmenyben meg legalabb 2x-nel. Az intel nem ezert nem csinalt riscet, hanem mert azt nem tudta volna eladni, az x86-ot meg igen.''
Dehogynem.
Hadd ne menjek bele, hogy a mai x86 processzorok mennyire hasonló felépítésüek, mint a mai RISC-ek.
A 4-5 GHz-es procinak nincs értelme, a memória nem tudja követni az IPC nem lenne magasabb, sőt. A mai RISC processzorok is mehetnének 3GHz-en, de nem mennek, mert teljesítményben rosszabb eredményeket ad egy nagyon hosszú pipeline cserében jóval több hőt termel.
A RISC és az x86 architechtúrák fejlesztésének egyetlen kiútja a SMT és CMP, ez eléggé behatárolja az elkövetkező éveket.
Az Itaniumban elméletileg azonban sokkal nagyobb lehetőségek vannak.
Az más kérdés hogy nem biztos, hogy megéri a rögös út. :) -
Power
senior tag
''Vajon az Itanium es egy risc proci fejlesztesi koltsegei hogy viszonyulnak egymashoz szerinted?''
Ez attól függ, hogy mi a fejlesztés célja.
''Nyilvan a risc olcsobb.''
Nem biztos!!!
''Masreszt egy kisebb lapkameretu proci hosszutavon is olcsobba bir valni a nagyobb kihozatal stb. miatt.''
1. Egyáltalán nem biztos, hogy egy RISC proci kisebb
2. A lapkaméret és a kihozatal között nincs egyenes összefüggés
''Es igaz ugyan, hogy az eladott kb. 18 db Itanium procinal a fejlesztesi koltseg dominal, de egy piacvezeto procinal mar sokkal jelentosebb az eloallitasi koltseg (mint az Itaniumnal, nyilvan a fejlesztesi koltseg sokaig meghatarozo az arban).''
Az összes felső kategóriás processzornál a fejlesztési költség dominál.
''Amugy mit ertesz 'a risc' alatt? Szerintem csak siman risc van, es termeszetesen nem ugyanazok a gondok vele, mint az x86-nal.''
Az 'a' pusztán névelő volt a mondat elején. :)
A teljesítmény növelés szempontjából az x86-nak ugyanazok a gondjai, mint a risc-nek. Az intel ezért nem RISC-et csinált, mert azzal semmiféle előrelépést nem tett volna.
[Szerkesztve] -
Power
senior tag
''Hat annyiban igaz, hogy nem x86, de szerintem gyorsabb lenne, ha riscet fejlesztettek volna, es nem is kerulne annyiba az eloallitasa.''
A RISC nem megoldás, ugyanazon problémákkal küszködik, mint az x86.
Egyébként nem az előállítási költségek a jelentősek az Itaniumnál, hanem a fejlesztési költségek. A kettő között több nagyságrend különbség van. -
Fiery
veterán
''Arrol volt szo, hogy x86 nelkul faszabb procit lehetne csinalni. Nem csinalt meg senki ilyet.''
Itanic. Intel megcsinalta. Pont az x86-tol valo elszakadas es a brutalis eloallitasi koltsegek miatt nem tudta felvaltani az x86-os procikat (es nem is fogja egyhamar, talan sosem).
Fiery -
DcsabaS
senior tag
(#251) perla!
1.) ''Az rdramnak mi koze a kompatibilitashoz? Szerintem semmi''
Nagyon is sok koze van. Az RDRAM annak jegyeben szuletett, hogy szakitsunk az SDRAM tovabbi fejlesztesevel, dobjuk el, es csinaljunk helyette mast, valami olyat, amiert - ha sikerul elterjeszteni - majd jo sok licensz dijet lehet kovetelni, de amelyik ceg nem ugy tancol ahogy futyulunk, annak el sem adjuk.
De nezd meg a Rambus mostani ajanlatat, micsoda palfordulas! Mostmar olyan RAM interfeszt terveztek, amely kepes kiszolgalni az SDR SDRAM-tol kezdve az XDR-ig mindent (magyarankompatibilis veluk)! Ezt kellett volna csinalniuk kezdetben is! Ez optimalis kifutasat adja az egyes RAM technologiaknak, es akkor kovetkezik be a valtas, amikor a felhasznaloknak legjobban megfelel!
2.) Optimalizalas: az x86-os kodot az Athlon-ok kulonosebb optimalizacio nelkul is nagyon jol futtatjak, mert maga a proci olyan. (Az Intel P4 vonulatra ez nem jellemzo, meglehetosen egyenetlen teljesitmenyeket mutat fel.)
Ha olyasmire akarjuk hasznalni a CPU-t, ami valojaban nem igenyelne x86-ot, lasd pl. szerverek es 3D, tortenetesen az x86-ttal egyutt is nagyon jo az Athlon(64).
Marad tehat a dompingszeru multimedia, ott tenyleg nem eleg az x86, ugyanakkor nincs akadalya a megfelelo SIMD kiterjesztesnek.
(Hogy mit es mennyit lehet ''nyerni'' (:) a korlatozott x86 kompatibilitassal, arra remek aktualis peldaval szolgal az Itanic tortenete.)
3.) Igen, SIMD szempontbol a G5 a legjobb, a P4 a masodik, es az Athlon 64 csak a harmadik. Kar erte, mert szerintem ez is fontos. (Talan egyszer majd ebben is elre tor az AMD.)
Hogy dicserjem a G5-ot: az mindenesetre nagyszeru benne, hogy azon idiotakkal (mar bocsanat) szemben, akik szerint nincs szukseg 64 bitre, meg multiprocesszoros gepekre desktop celokra, segit hamarabb bebizonyitani, hogy igenis van.
4.) Itt van a laborban, meg lehet nezni (a gazdaja szereti mutogatni (:) ), ugyanakkor semmi erdemlegesre nem hasznalja, valoszinuleg Power Point szeru prezentaciokat fog vele gyartani. A ficko videoban teljesen jaratlan, ugyhogy neki a SIMD semmit nem hasznal. Ha a gep olcsobb lenne, akkor valoszinuleg tobben megvehetnek, olyanok is, akik ki tudnak erdemben hasznalni.
5.) ''Nem erzed butasagnak, elfecserelt idonek szuperszamitogepen nem optimalizalt kod futtatasat? ''
Barmilyen vicces, nem. Ugyanis tudomanyos temakban az adott kerdeshez erto ember ideje a legnagyobb ertek, aki ezert nem tokolhet holmi program optimalizaciokkal. Aki pedig tud es szeret is programozni (informatikus), az meg nem ert magahoz a tudomanyos kerdeshez, es ugy optimalizalna, hogy kozben keverne a jezuskat a geppuskaval, ezert bar szep lenne a programja, de a lenyeg szempontjabol rosszul mukodne. Altalanos tapasztalat.
(Nemileg hasonlo folyamat zajlott le ugy 15-20 evvel ezelott. Elotte a ''tudos'' lediktalta a cikket a gep es gyorsiro nonek, aztan atnezte, bejelolte a javitasokat (jezuska-geppuska cserek), ujra legepeltette, stb. A PC-k megjelenesevel ennek vege lett. A kutatok maguk irjak a cikkekket, ha osszesen csak 2 ujjal is, de szamitogepen, es ha vannak is benne hibak, inkabb csak esztetikai jelleguek, gyors es gepirot meg nem alkalmaznak.)
Egy erdekes adalek: 95-ben (vagy 96-ban) a szamitogepes sakk vilagbajnoksagon eloszor fordult elo, hogy a PC-k nagyon eloretortek a sakkgepekkel szemben. Az elso 10-ben 8 db PC volt! A 2 db nem PC kozul az egyik a frissen debutalt IBM szuperszamitogep, a Deep Blue (vagy 3000 db 64 bites CPU-val!), a 2. helyezett meg egy 4 Alpha processzoros gep volt. Na most a Deep Blue holtversenyben vegzett az elso helyen az akkor szinten ujnak szamito Fritz 1.0 sakkprogrammal, amely viszont csak egy x86-os, 90 MHz-es Pentiumon futott (:)))!!! Na most nyilvan nem arrol van szo, hogy a Deep Blue nem eleg eros gep, vagy hogy a sakkozas nem jol parhuzamosithato, hanem arrol: aki hozzafer egy szuperszamitogephez, annak eszebe sincs optimalizalni.
''Amugy az oke, hogy az egyet merek, kettot osztok feladathoz nem kell tul nagy szamitasi teljesitmeny, es a ganyolt program is megoldja ''
Akkor meg mindig nem vagy kepben (:). Gondolj arra, hogy a tudomanyos meroberendezeseket es (muszereket) altalaban modulkent, nagyon sokfele celra hasznaljak, hol igy, hol ugy osszerakva. Ugyanakkor ma mar nem lehet meglenni a meresek szamitogepes felugyelete, es az adatok szamitogepes feldolgozasa nelkul. A rugalmassag es a teljesitmeny szinkron igenyet pl. ugy lehet osszehangolni, hogy a LabVIEW rendszert (vagy mas hasonlot) hasznalnak, ami ugyebar arrol szol, hogy az adott feladatnak megfeleloen, egy kimondottan magas szintu programnyelven allitja ossze a kutato, hogy mit es hogyan szeretne csinalni, a szamitogeppel meg elvegezteti. Ez nagyon sok adat folyamatos begyujteset es processzalasat, valamint eszkozok vezerleset jelentheti, de megsem lehet sebessegre optimalizalni, mert nem lehet kobe vesni semmit, hiszen barmikor modositani kellhet rajta. Marad tehat az, hogy egy megfeleloen gyors gepet kell vasarolni a feladathoz. Ez menni szokott.
A G5 vonatkozasaban ez pl. azt is jelenti, hogy amennyiben tudna fogadni a megfelelo interface eszkozoket, es futna rajta a LabVIEW, akkor mindjart megnone a valodi tudomanyos erdekessege. (Addig legfeljebb csak szimulaciokra lehetne hasznalni, ami persze szinten nagyon fontos es hasznos, de csak egy reszterulet.)
''Azt akarod nekem bemeselni, hogy senki senmmilyen feladatra nem hasznal optimalizalt kodot? ''
Nem. Hanem azt mondom, hogy sebessegre a tudomanyban csak ritkan optimalizalnak. Inkabb vesznek/berelnek gyorsabb gepeket.
''Tok sok optimalizalt library van. Akar ha csak egy FFT-t nezek, szerinted mindig mindenki leall ezt ujra megirni, vagy hasznalnak egy mar letezot?''
Dehogy. Ami optimalizacio kesz van, vagyis a gyerto cegek megcsinaltak, azt szivesen felhasznaljak. Csak hat az a helyzet, hogy a tudomany frontvonalaban hiaba mondod, hogy 1 ev mulva majd lesz optimalizacio, ha egyszer most lenne jo. 1 ev mulva mar gyorsabb gep is lesz.
''Ha esetleg letezot hasznalnak, akkor vajon egy gyorsabb, simd utasitasokat hasznalot fognak hasznalni, vagy direkt egy lassabbat? Ehh...''
Nem azok a feladatok igenylik a legtobb CPU erot, amelyeket SIMD-del gyorsitani lehet, hanem inkabb azok, amelyekhez tovabbi CPU-k kellenenek (parhuzamositas). Ezert a G5-ben vonzobb a dual procis felepitese, mind a hatekony SIMD.
*************
(#254) Don Vittorio!
''Szerinted én ezt írtam? Ehhh. ''
Szerintem Te ezt irtad: ''ha kiléptél a Win95-ből a DOS-ba... ''
Marpedig, ha a Win95-bol lepsz ki a DOS-ba, ahelyett, hogy teljesen ujrainditanad a gepet es megallitanad a boot-olas folyamatat a GUI elott, akkor nem tisztul ki teljesen a memoria (foleg helytelenul installalt Windows-os driver-ek eseten), es akkor NEM LESZ teljes erteku DOS-od. Ez egy lenyeges korulmeny, amirol a jelek szerint Te nem tudtal, erre fel szemelyeskedni kezdesz (plane HAZIGAZDA-kent), es meg csusztatsz is. Finoman szolva nem szep dolog.
''Ismétlem, semmi értelme nincs a DOS-ablakkal bohóckodni. ''
Ebben latod egyetertunk. -
DcsabaS
senior tag
1.) Most trefalsz?!? Az Intel ezen lepeseit (pl. az RDRAM erolteteset) pont az motivalta, hogy szerettek volna elhagyni a kompatibilitast. De nem am azert, mert az olyan nehez volna, hanem mert azt hittek, hogy eronek erejevel az egesz iparagat a sajat utcajukba kenyszerithetik, es akkor aztan csak annak adnak (vagy nem adnak) licenszet, akinek akarnak, az altaluk onkenyesen megszabhato csillagaszati aron. Szerencsere a vasarlok nem honoraltak, hogy sokkal tobb penzert kapjak meg ugyanazt (vagy alig jobbat). Ezek a mellekvaganyok tehat nem a kompatibilitas miatt, hanem pont annak elhagyasara valo torekvesek miatt szulettek.
2.) Nem huz vissza dramai modon, ahogyan az Athlon64-et sem huzza. Az SSE2, 3, 4, 5, stb. lehetosegeit sem korlatozzai.
3.) SIMD media kodolas: pontosan arrol van szo, hogy ez a G5-ben is ugyanugy extension, mint ahogy a P4-ben, vagy az Athlon-ban. Szoval nem igaz, hogy az x86 visszahuzna. Az egy teljesen mas kerdes, vagyis fuggetlen az x86 kompatibilitastol, hogy milyen teljesitmenyu SIMD kiterjesztes megvalositasat latja a CPU gyartoja indokoltnak. (Szemely szerint en tamogatom, hogy legyen minel gyorsabb, de - egyelore - a kisebbseghez tartozom.)
4.) Hogyne ismernem. Tegnap is villogott itt valaki vele, egy amolyan fonok. (MAX-Lab, Lund).
5.) Ez tokre ugy van, ahogy leirtam. Tapasztalatbol beszelek, kutatokent. Amit viszont Te irtal, az csak a kivulallok fantazialasa. (Ismetlem, optimalizalast csak nagyon ritkan vegeznek. Inkabb elmennek egy szuperszamitogephez...) Kozonseges esetekben pedig olyan gepeket igyekeznek hasznalni, amelyek egyreszt megbizhatoak (termeszetesen, no tuning es hasonlok), masreszt a ''ganyolva'' megirt programokat is jol futtatjak.
6.) Opteron: architekturalis okokbol nem fogy ki belole a savszelesseg tobb procis kialakitasnal, ami egyreszt jo szervereknel, masreszt nagyon gyors klasztereket lehet belole osszerakni (szimulacios szamitasokhoz), es megvan a lehetoseg arra is, hogy a tobb core-os verziok hasznalhatok legyenek az eredetileg az 1 core-os verziokhoz keszult alaplapokban (ismet csak kompatibilitas). -
DcsabaS
senior tag
A nullarol indulva termeszetesen konnyebb tervezni, hiszen semmi sincs, ami a szarnyalo fantaziankat korlatozna. Amde:
1.) pont ez szokta azt eredmenyezni, hogy a dolog ugyan onmagaban szep, de nem igazan jo a szukseges dolgokra
2.) tul gyakori ismetlodes eseten (mindig a nullarol indulni) tul sokba is kerul
Az x86 kompatibilitas egyebkent NEM huzza vissza dramaian sem az Intel, sem az AMD procikat. Hardveresen relative csak csekely mennyisegu tobblet tranzisztort jelent, amikor meg eppen nem azt a reszt hasznaljak a procik, akkor vegkepp semmit sem huz vissza.
A kerdes inkabb az, hogy ki mennyire talalja el, mire van piaci igeny es mekkora. Az asztali PC-k x86-os CPU-nak fejleszteset manapsag leginkabb a 3D teljesitmeny tamogatasa, illetve nemileg kisebb mertekben a nagyobb multimedialis sebesseg motivalja. Az AMD ezt az Opteron csalad megalkotasanal kiegeszitettek az erosen javitott szerver teljesitmennyel, es a sokkalta nagyobb RAM kezeles lehetosegevel, amivel szerintem speciel nagyon jo lora tettek (de nem reszletezem).
Az Intel inkabb megmaradt a media kodolas tovabbi hangsulyozasanal. Hasonlot latok az Apple G5-nel is. Valamint az utobbinal meg azt a felismerest, hogy a tarsadalom egy resze (talan 1 szazalek?) erosen sznob, mindegy mije van, csak mondhassa, hogy valamilyen elitnek szamito dologban gyorsabb/szebb, mint a mase.
Valaki dicserte itt valahol a G5 tudomanyos kepessegeit is. Na az is vicces (:). Ugyanis a valodi tudomanyos programokra abszolut nem jellemzo, hogy barmire is optimalizalva lennenek, ugyanis a kutatokra egyaltalan nem jellemzo, hogy az optimalizalassal lenne kedvuk veszodni, de az sem, hogy programozokat fizessenek meg az optimalizalasert. Igy hat a hardver es az oprendszer szempontjabol az jelenti a kihivast, hogy a kimondottan ''ganyolt'' tudomanyos programoknak is megfeleloen kell futniuk.
Na ez az, ahol az x86 nagyon jo, az Athlon/Athlon64 pedig kulonosen. -
Ezt még a szerkesztésed előtt írtam, amikor még valamiért (:F) Nekem címezted a hozzászólásodat, és ha megfigyeled, nem is a Te megnyilvánulásaidra hegyeztem ki a mondanivalómat. De ha kicsit visszaolvasol a témában, ne adj' Isten a témák között, megtalálhatod azt a pár notórius alakot akik ezeknek a Motorola / PPC / whateva igehirdetéseknek a döntő hányadáért felelősek...
Ami persze nem baj, minden humorforrást meg kell manapság becsülni. :P -
''Rohoghetsz rajta, de ez a valosag.''
Én ezeken a tirádákon röhögök.
Az x86 olyan, amilyen... sok marhaság maradt benne ''for hysterical raisins'', de ez van. Ahogy mondod, ''ez a valóság''. Ész nélkül fikázni minden egyes adódó alkalommal (és ha nincs ilyen, akkor teremteni) se nem produktív, se nem különösebben érett gondolkodást sejtető hozzáállás. -
Fiery
veterán
''De mondjuk ennyi erovel azt is mondhatnank, hogy ne vegyen senki 3 gigas p4-et mert a 2 gigas mindenre eleg.''
Megsem, mivel:
- a gyorsabb procihoz gyorsabb memoria es altalaban gyorsabb diszk alrendszer is tarsul
- bar a gyorsabb procin a nem teljesitmeny kritikus szoftverek egyenkent nem feltetlenul futnak erezhetoen gyorsabban, azonban az altalanos felhasznalas soran (pl. a szoftverek indulasa, leallasa, dokumentumok betoltese/mentese) megis tapasztalhato az uj rendszer nagyobb osszteljesitmenye
- vannak a jatekokon kivul is teljesitmeny igenyes feladatok, pl. video enkodolas/dekodolas... Egy kedves baratom most valtott K6-III/450-rol AXP 2200+-ra, es vegre meg tudta nezni a DiVX 5-os es XViD-es filmjeit :D Pedig az office feladatokkal, de me'g a Visual Studio-val se volt baja a regi gepen
Fiery -
Fiery
veterán
Ezt irtad:
''Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.''
Ezzel kapcsolatban merult fel bennem az a kerdes, vajon hogyan ''irsz egy progit gyorsabbra'' G5-on :)
Mert egy ''progi megirasa'' tobbnyire abbol all, hogy C-ben vagy Object Pascalban (Delphi), esetleg Javaban firkalgatod a forraskodot. Ez ugye _elvileg_ nagyon hasonloan megy Macen es PC-n is -- azonban pl. egy Visual C-ben osszetakolt pure C/C++ progi egyszeru portolasaval nem tul valoszinu, hogy latvanyos gyorsulast ernel el a G5-re valo ugrassal. Az optimalizacio megint mas tema, de az meg baromi sok melo, es nem feltetlenul eri meg...
Arrol nem is beszelve, hogy a portolas sem egyszeru melo -- hacsak nem Linuxrol beszelunk.
Fiery -
Fiery
veterán
''Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.''
Ja, es ez semmit sem jelent. Nezd csak meg, a gepedre telepitett szoftverek hany szazaleka teljesitmeny-kritikus!
Az enyemen a telepitett es hasznalt szoftverek 90 %-a hasonlo tempoval menne egy Duron-600-on is. Az ilyen szoftvereket csak azert sosem fogjak Macre portolni, hogy azon majd gyorsabban futnak...
Es pont ez a baj a Mackel: szep meg jo, de a libego ablakokon meg a technologiai csilli-villiken kivul nem nyujt tobbet, mint a PC a legtobb juzer szamara.
Fiery -
Chain|Q
tag
Szal a P4 szerinted nem kompatibilis visszafele?? Dehogynem, full kompatibilis. Masik dolog, hogy lassabbak rajta bizonyos kodok.
Akarcsak egy emulacional. Full kompatibilis, de van ami lassabban fut rajta. Egyebkent, ironikus modon, egy emulacio gyorsabb is lehet, ha jol van megirva, ugyanis kioptimalizalhat szuksegtelen utasitasokat a kodbol... (Tipikus pelda a mar emlitett jelzobit orulet.) Termeszetesen ezt JIT emulaciora ertem nem interpretivre.
De ez csak orajel/orajelre igaz, abszolut ertelemben nem.
Egy jol megirt JIT emulacio korulbelul az eredeti CPU 75-90%-at kepes hozni sebessegben ha az ugyanazon CPU-n futo nativ programokhoz merunk, erre mukodo letezo peldak vannak. 10-25% teljesitmeny kulonbseg pedig az eppen aktualis piacon levo x86 CPU-k kozott is van, szoval a teljesitmenykenyszert mint okot nem tudom elfogadni.
Az x86 dobozzal az a baj, hogy ez nem csak bezarja az emlitett cegeket, de jo kis meleg kucko, amin kivul nemigen van fejlesztesi tapasztalata egyiknek sem. Az Intel most kidugta az ujjat a hidegbe (IA-64), jol ra is fazott, ugy nez ki, de maganak koszonheti, mivel ilyen mentalitassal ahogy ok tettek, nem lehet bevezetni egy uj CPU architekturat a piacra. Ok sem akartak tenylegesen kibujni az x86 kuckobol, egy fenekkel pedig nem lehet ket lovat megulni. Az AMD pedig ertelemszeruen meretebol is fakadoan mindent egy lora tett fel, neki az egyetlen megoldas a 64 bites x86 volt. Ugy nez ki, egyelore bejott nekik, szoval nekik sem akarodzik kibujni a kenyelmes kuckobol, amig a nep megveszi a cuccot. De ezek piaci, politikai dolgok, es nem sok kozuk van ahhoz, hogy technologiailag mi a jo. Marpedig _ENGEM_ a technologia erdekel, nem a politika. Utaljatok erte. :D -
Fiery
veterán
-
Fiery
veterán
Azert nincs ertelme hasonlitgatni, mert ennyi erovel kiterhetnenk arra is, melyik jobb: a notebook vagy az asztali PC? Baromi sok erv szolna itt is az egyik es a masik mellett is, donteni azonban nem lehetne, hiszen 2 kulonbozo piacra szanjak oket.
Technologiailag lehetne hasonlitgatni, de az megint nem vezet sehova: verhetik a melluket a brillians otletek kitalaloi, de ha nem tudjak az otleteket forintositani, akkor hiaba szuperjok az otletek...
A technologia nem muveszet. A muveszetben magat az otletet is (vagy csak az otletet) dijazzak, a technologiaban azonban a vegso szot a piaci sikeresseg mondja ki.
Fiery -
Fiery
veterán
Hiaba hasonlitgatod a G5-ot es az Opteront, semmi ertelme. Ja, es mellesleg: a kutyat nem erdekli, hogy a szamitogepben pofogo processzor hany tranyobol epul fel. Bizonyos hatarokon belul az sem szamit, mennyit disszipal a processzor: 10 vagy 70 watt, a legtobb felhasznalonak baromira mindegy.
Az persze egyertelmu, hogy bizonyos, nagyon szuk koru felhasznalasra a Macek nagyon jok, jobbak mint a PC-k... Ez azonban nem jelenti azt, hogy osszessegeben jobbak lennenek, vagy hogy az x86 egy katasztrofa lenne.
Ahogy irtam legutobbi firkalmanyomban:
''Ahogy az elemzők fogalmaznak, az AMD64 egyáltalán nem brilliáns, de elég jónak tűnik a jelenlegi problémák költséghatékony kezelésére vagy elodázására.''
Ez azt hiszem, az x86-os procikra mindig is igaz volt. A piaci versenyben sokszor fontosabb az, hogy az adott problemat gyorsan, olcson es fajdalommentesen kezeljek/elodazzak, mint hogy egy brillians, bonyolult, ismeretlen, uj utat fedezzenek fel.
Fiery -
Chain|Q
tag
Miert jo az, ha tervezel egy zsenialis procit, es a celkozonseg olyan progit futtat rajta, amire nincs optimalizalva, vagyis lassabban fut a progi rajta, mint az ellenfel szoftverhez tervezett procijan?
Ez nem jo, megis ez tortent, ugyanis a P4-bol koztudottan rengeteg olyan dolog volt kihagyva, ami szukseges a megfelelo sebesseg eleresehez bizonyos ''regi progik'' eseteben. Pl. a hardveres bitforgato egyseg (ROL/ROR), vagy emlithetnem a katasztrofalis FPU teljesitmenyt is. A P4 volt az egyik leginkabb olyan proci a kozelmultban, ami optimalizalasi, ergo ezekszerint (a ti ertelmezesetek szerint) visszafele kompatibilitasi szempontbol katasztrofalis volt, es igazan csak a direkt ra keszult programok futnak rajta jol. Megis ez terjedt el a legjobban, marketingszempontok miatt. Szoval most akkor hogyis van ez?
Egyebkent en programozaselmeleti dolgokrol beszelek a processzorok kapcsan, amin sporolni lehetne. Tipikus peldak a stack-kezeles az x86 procikban. Anno kezi asmhez nagyszeru volt, hogy minden stack ki-be mozgataskor modosult a veremmutato is, ma mar ez a forditoprogramok koraban felesleges, es csak plusz eroforrasokat igenyel. Ugyanez pepitaban az FPU is. Akkor ott a totalis zsakutcanak minosulo MMX, vagy a 4 privilegiumszint amibol gyakorlatilag mindenki csak 2-t hasznal. Vagy eppen a kvazi minden utasitasnal modosulo jelzobitek, amiktol nagyon nehez hatekony pipelineos optimalizalast csinalni, ha sok ugrabugra van a kodban. Ezek elhagyasatol nem lenne lassabb egy processzor, sot, gyorsabb es hatekonyabb. (lasd meg: PowerPC Microprocessor Family: The programming Environments for 32-Bit Microprocessors, Motorola, 1997, MPCFPE32B/AD) A visszafele kompatibilitas biztositasara pedig vannak egyeb (szoftveres) modszerek, mint azt mar emlitettem volt. -
perla
csendes tag
Meg valami eszembe jutott, a cikkel kapcsolatban. Irtak, hogy 24kbyte adat es 64kbyte trace cache. Legjobb tudomasok szerint a mostani procikban 12k bejegyzes van a trace cacheben, ami valojaban 80 kbyte (256 set, 8 utas, egy line 40 byte, ami 6 utasitas, 53 bit/utasitas), szal a 64kbyte az gondolom eliras, hiszen az kevesebb lenne, mint ami most van. Amennyire en tudom, 16k-ra akarjak fejleszteni, es az ugy epulne fel, hogy 512 set, 8 utas, 32 byte egy line, ez 4 utasitas lenne, vagyis 64bit/utasitas. Ez osszesen 128kbyte. Illetve ami meg kulonbseg, hogy a mostani trace cache orajelenkent 3 utasitast tud megtalalni, a tervezett uj meg 4-et.
Aktív témák
Hirdetés
- ÁRGARANCIA!Épített KomPhone i5 13400F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- DELL PowerEdge R630 rack szerver barebone - 2xSocket 2011v4 , 24x DDR4 DIMM, H330 RAID, 39369Ft+ÁFA
- Bomba ár! Lenovo X1 Yoga 1st - i7-6G I 8GB I 256SSD I 14" WQHD I HDMI I W10 I CAM I Garancia!
- Csere-Beszámítás! Sapphire Pulse RX 9070 XT 16GB Videokártya! Bemutató darab!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest