- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy A36 5G - a középső testvér
- Honor Magic6 Pro - kör közepén számok
- Honor 200 - kétszázért pont jó lenne
- Xiaomi 13 - felnőni nehéz
- Redmi Note 13 4G
- Yettel topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- iPhone topik
- Samsung Galaxy A54 - türelemjáték
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. -
Power
senior tag
válasz
kisfurko
#297
üzenetére
''Ez igaz, de nem mindegy, hogy 8 regiszterre kell trükközni, vagy minimum 32-re. Meg az sem mindegy, hogy kétoperandusú vagy több. Mert kétoperandusúhoz több regiszter kell. A flagekről meg csak annyit, hogy sokszor tök feleslegesek (mert részszámítás), nyugodtan lehetne szabályozni, hogy mikor kell. Egyébként nem RISC/CISC összehasonlítást kell csinálni (hiszen manapság nincs igazi CISC), én is, mint perla x86 vs. jobb.''
A 3 operandusú nem is működne kevéssel ott lenne csak nagy baj, ott már eleve ezért is több van. Az igaz, hogy a renaming regiszterből ehhez viszonyítva már nem kell annyi.
Ahhoz viszont, hogy a flageket ne állítsa új útasítás halmazok kellenek, ezeket bele lehet pakolni.
Az x86 vs. bármi. Itt egyedül a bármi, ha az risc akkor jobbat vitatom.
''Ezt azért nehezen hiszem, nem véletlen, hogy a K8-ba is duplaannyi regisztert raktak.''
Itt adatfüggőségről beszéltem, nem regiszter függőségről. -
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
válasz
kisfurko
#283
üzenetére
''Azért annyit elismerhetnél már perla-nak, hogy sokkal egyszerűbb lenne a pipeline-t megcsinálni, ha nem kéne mindenféle függőségekkel szívni, hogy most ez az utasításrész melyik valódi regisztert, mikor érinti, vagy összeharácsolni az EFLAGS állapotát egy-egy utasítás után.''
A regiszter kezelés illetve a flagek a RISC procikban is jelen van, ezt register átnevezéssel jól lehet kezelni a RISC procikban is így csinálják, ez nem gond, könnyen orvosolható probléma.
''Tudom, hogy a mostani RISC-szerű procikban is van register renaming, de egy háromoperandusú utasításkészlet jóval kevesebb függőséget okoz. Igaz ez nem RISC/CISC kérdése.''
Nem a 3 operandusú okoz kevesebb függőséget, hanem a több elsődleges regiszter. A gyakorlatban azonban ugyanakkora a függőség egy P4/K8-nál, mint egy USP/Power-nél. -
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. -
Power
senior tag
''Mint irtam, mar annak idejen is ellentmondasos hirek jelentek meg arrol, hogy pontosan milyen hardverrel is rendelkezik a Deep Blue. De 1995-ben mar letezett es versenyeztettek is, barmilyen procikbol is raktak ossze.''
Tudod, ahhoz hogy megjelenhess valamivel tesztelni kell, edzeni. Nekik Kasparov volt a céljuk, elérték. A kezdeti szárnypróbálgatásokat felesleges szajkózni.
''Ez ugye attol fugg, hogy mire es hogyan hasznaljak. Nyilvan tudod, hogy ha pl. egy 32 bit-es CPU kifut a kozvetlenul kezelheto RAM-bol (mondjuk 4 GByte), es a HDD-hez kenytelen nyulkalni egy komolyabb szimulacional vagy adatbazisnal, akkor egy 64 bit-es CPU pusztan azzal is tud lenni nagysagrendekkel gyorsabb, hogy mondjuk 16 GByte RAM-ot kezel.''
Jaj! Már megint az általánosság. Itt és most konkrét dolgokról van szó, ne menekülj az általánosságokba.
''Az IBM-esek akkortajt nem azt allitottak, hogy egy kicsit gyorsabb gepet csinaltak, hanem azt, hogy egy supercomputert.''
A Deep Blue 1997-ben az is volt.
''En mindenesetre meglepodtem rajta, mint ahogy alighanem (#256) Fiery-nek is meglepo volt. Azzal egyetertek, hogy hiaba a ''supercomputer'', ha nincs a feladatra optimalizalva a szoftvere.''
Figyú. Ha valamit 256 cél-hw-re optimalizálva tervezel 6 évig, akkor a 4-dik évben nem biztos, hogy 14-en optimálisan kifutja magát.
''Az egesz tortenetet csak azert ideztem, hogy vilagos legyen: igenis van olyan (plane tudomanyos korokben), hogy adva van a nagyszeru hardver, es viszonylag rosszul megirt, azaz nem, vagy nem jol optimalizalt programokat futtatnak rajta.''
Azért írtam, hogy ez egy kifejezetten rossz példa volt. A nagyon nagy arcok alkották a DeepBlue-t.
''A Deep Blue operacios rendszere feltehetoen optimalizalt volt. Csakhogy itt most a sakkprogramrol van szo, amit rajta futtatak!''
Az is tökéletes volt a koncepcióhoz. Az egy más kérdés, hogy közben ''forradalom'' zajlott le a sakkprogramozásban, mind a pc-k fejlődésében, de ez 90-ben még nem látszott.
''Plane szegyen, hogy milyen rosszul muzsikalt egy x86-os Pentiummal es a ra ganyolt programmal szemben (...''
Más gép ellen játszani és más ember ellen. A DeepBlue Kasparov ellen tökéletes volt, 96-ban(97-ben) a Fritz-et is megverte volna. Az x86-os pentiumról meg csak annyit, hogy nagyjából azonos volt a fixpontos teljesítménye, mint a Power2-es procié. -
Power
senior tag
''Mint irtam, mar annak idejen is ellentmondasos hirek jelentek meg arrol, hogy pontosan milyen hardverrel is rendelkezik a Deep Blue. De 1995-ben mar letezett es versenyeztettek is, barmilyen procikbol is raktak ossze.''
Tudod, ahhoz hogy megjelenhess valamivel tesztelni kell, edzeni. Nekik Kasparov volt a céljuk, elérték. A kezdeti szárnypróbálgatásokat felesleges szajkózni.
''Ez ugye attol fugg, hogy mire es hogyan hasznaljak. Nyilvan tudod, hogy ha pl. egy 32 bit-es CPU kifut a kozvetlenul kezelheto RAM-bol (mondjuk 4 GByte), es a HDD-hez kenytelen nyulkalni egy komolyabb szimulacional vagy adatbazisnal, akkor egy 64 bit-es CPU pusztan azzal is tud lenni nagysagrendekkel gyorsabb, hogy mondjuk 16 GByte RAM-ot kezel.''
Jaj! Már megint az általánosság. Itt és most konkrét dolgokról van szó, ne menekülj az általánosságokba.
''Az IBM-esek akkortajt nem azt allitottak, hogy egy kicsit gyorsabb gepet csinaltak, hanem azt, hogy egy supercomputert.''
A Deep Blue 1997-ben az is volt.
''En mindenesetre meglepodtem rajta, mint ahogy alighanem (#256) Fiery-nek is meglepo volt. Azzal egyetertek, hogy hiaba a ''supercomputer'', ha nincs a feladatra optimalizalva a szoftvere.''
Figyú. Ha valamit 256 cél-hw-re optimalizálva tervezel 6 évig, akkor a 4-dik évben nem biztos, hogy 14-en optimálisan kifutja magát.
''Az egesz tortenetet csak azert ideztem, hogy vilagos legyen: igenis van olyan (plane tudomanyos korokben), hogy adva van a nagyszeru hardver, es viszonylag rosszul megirt, azaz nem, vagy nem jol optimalizalt programokat futtatnak rajta.''
Azért írtam, hogy ez egy kifejezetten rossz példa volt. A nagyon nagy arcok alkották a DeepBlue-t.
''A Deep Blue operacios rendszere feltehetoen optimalizalt volt. Csakhogy itt most a sakkprogramrol van szo, amit rajta futtatak!''
Az is tökéletes volt a koncepcióhoz. Az egy más kérdés, hogy közben ''forradalom'' zajlott le a sakkprogramozásban, mind a pc-k fejlődésében, de ez 90-ben még nem látszott.
''Plane szegyen, hogy milyen rosszul muzsikalt egy x86-os Pentiummal es a ra ganyolt programmal szemben (...''
Más gép ellen játszani és más ember ellen. A DeepBlue Kasparov ellen tökéletes volt, 96-ban(97-ben) a Fritz-et is megverte volna. Az x86-os pentiumról meg csak annyit, hogy nagyjából azonos volt a fixpontos teljesítménye, mint a Power2-es procié. -
Power
senior tag
1. 1997-ben pontosan 32 db processzor Power2SC processzort 135MHz-en plusz az 512 sakkprocesszort. Ezt a processzort 1996-ban fejlesztették ki, szóval már 1995-ben aligha használhatták, valószínű a sakkprocesszora sem a végleges volt.
Annyit sikerült találnom, hogy 1995-ös prototípus csupán 2 node-os volt és nem 8, hanem csak 6 engine proci volt 1 node-on. Ezért nyílvánvaló, hogy hw-s sem nagyságrendekkel gyorsabb, mint egy P90. Ráadásul az engine is egész más célhw-re készült, nem meglepő hogy nem lett első(kb. 1/50-ed akkora teljesítménye volt, mint a 97-esnek). A DeepBlue programja tökéletesen optimalizálva volt a hw-re, nem kétéves hülyegyerekek írták a szoftvert sem.
Ez egy kifejezetten rossz példa volt a nem optimalizálásra.
3.
Még mindig nem érted? Ez egy célszámítógép volt!!!
Teljesen más elveken működött, mint a Fritz. Látom problémákba ütközöl, hogy eltérő a hw-hoz eltérő megközelítés és eltérő megvalósítás nem feltétlenül azt jelenti, hogy nincs maximálisan kihasználva.
A játékerő nem egyenlő a kihasználtásggal vagy az optimalizáltsággal.
A Deep Blue már múzeumba van, nem hiszem hogy bármilyen összehasonlítási alap lehet egy 1997-es sakkszámítógép, egy jelenlegi bármilyen maival.
Azért kezdődik 96-ban, mert a prototípus az prototípus. Remélem Papp Laciról sem annyi szűrődött le benned, hogy az első edzésén alaposan megverték. -
Power
senior tag
1. De közelében sem volt a 3000-nek, nemhogy 95-ben, még később sem.
2. Rendben, de Deep Blue-nak tulajdonképpen a 97-est tekinthetjük, csak érdekességként említettem.
3. Kihasználta. Pont erre épített, egy több, mint 40 éves algortimust használt cél hw-re.
4. Csak ne volnál tájékozatlanul ennyire magabiztos. :)
Az IBM és a hozzáértők máshogy tudják(de biztos neked van igazad).
Nézz csak ide:
[L]http://www.research.ibm.com/deepblue/press/html/g.6.4.html[/L]
[Szerkesztve] -
Power
senior tag
Én nem akartam reagálni, de egyre azé mégis:
DcsabaS:
''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''
Fiery:
''Lehet, hogy sakkban nagy vagy''
Aligha.
1. A Deep Blue processzor számát illetően erősen el van tájolva a kollega.
2. 1995-ben volt Fritz-Deep Blue, amely azonban messze nem ugyanaz volt, mint a Kaszparovval mérkőző 97-es(a kettő között jelentős számításbeli különbség volt).
3. A két program elve teljesen más, ezért volt köztük különbség és nem az optimalizálás a különbség. Az optimalizálással nem lehet nagyságrendet javítani, mert akkor az nem optimalizálás, hanem fejlesztés(vagyha igen, akkor az egy szar program volt). Esetünkben sem optimalizálásról volt szó, hanem az enginek különbsége jött elő.
4. A Deep Blue nem klasszikus szuperszámítógép. Speciális sakkprocesszorok voltak benne, amelyeket Power processzorok vezéreltek(minden RS/6000-es node-ok 16 sakkproci kapcsolódott).
[Szerkesztve] -
Power
senior tag
Lásd Itanium + Windows...
A bináris x86-os kódot soha az életben nem tudsz full sebességgel futatni egy eltérő hw-en, akármilyen oprendszer van alatta.
''Ja és ha csak egy a-t kell átírni b-re mert ugyan nem fur 1:1-be a progi a másik platform alatt, akkor azt megteszi a fejlesztő is hidd el, vagy eleve úgy írja meg a progit, hogy mindkettőre telepíteni lehessen.''
Csakhogy a legtöbb esetben nem ennyi a gond.
Nézd meg az AMD64-es windows mennyi ideig készül, pedig már volt 64 bites win. Nem olyan könnyű dolog, az akármennyire is annak látszik. -
Power
senior tag
Átrendeződéstől énsem tartok.
''De teljesen új irányt vehet a pc fejlesztése, hiszen eddig a legegyszerűbb legolcsóbb módot választották, növelték az órajelet, de alapvetően maradt ugyanaz a gép. most nagyobb hangsújt fog kapni az architektúra fejlesztése ami viszont kihatással lesz a szoftver fejlesztésre, mert míg egy program kérszer olyan nagy órajelü (ugyanolyan tipusu) procival durván kétszer gyorsabb lett addig az architektúra fejlesztés csak akkor hoz gyorsulást ha a szoftvert megfelelően optializálják. És szerintem ez az aranykor végét is jelentheti, az olcsó teljesítménynövelését.''
Eddig is komoly architechtúra fejlesztés volt ám!
Az órajel emelésnek meg kell ugyanis teremteni a feltételeit.
A szoftver fejlesztésre valóban kihatással lesz, de az optimlizálásnak is vége.
Az alapblokk nem nőhet már tovább, nincs nagyon mit optimalizálni, az IPC-nek meg a maximuma.
Egyetlen kiút a párhuzamos programozás. Ez nem optimalizálás, hanem kemény fejlesztés. Ez nem az aranykor végét jelenti, csupán változás kezdetét.
''Az új ''világban'' viszont egy új architektúrálisan fejlettebb, többszálú többmagos stb proci használata nem fog automatikusan teljesítménynövekedést hozni csak ha a szoftvereket is megfelelőre cseréljük.''
Dehogynem, csak nem fix hw-re kell fordítani, így a konkrét optimalizáció nem lehetséges(ugyanis nem tudhatod, hogy 1 thread-et képes futattni a proci, vagy ezret).
Aktív témák
Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Milyen légkondit a lakásba?
- Milyen videókártyát?
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Tőzsde és gazdaság
- OTP Bank topic
- Kerékpárosok, bringások ide!
- Tesla topik
- Argos: Szeretem az ecetfát
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- További aktív témák...
- LG 42C3 - 42" OLED EVO - 4K 120Hz 0.1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- LG 48GQ900-B - 48" OLED - 4K 3840x2160 - 138Hz & 0.1ms - G-Sync - FreeSync - HDMI 2.1
- Azonnali készpénzes AMD Ryzen 1xxx 2xxx 3xxx 5xxx processzor felvásárlás személyesen / csomagküldés
- ÁRGARANCIA! Épített KomPhone Ryzen 5 9600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged