Új hozzászólás Aktív témák
-
#79
Nowhereman
őstag
Nowhereman
őstag
Valamit lehagytatok. A könyvelőnő dos-os könyvelőprogiját kezelő gép és a épűletet betöltő gépek közt folytonos az átmenet. Tehát kedvező egy olyan proci, ami mindet el tudja látni. Az Athlon64 futathat dos-t és képes töbedmagával szuperszámítógépként műxeni/lehet hogy a konkurens gyorsabb, de ha 2 A64-t pakolunk be helyette, még mindig olcsóbb és kisebb áramfelvételű rendszert kapunk.../
és csak ezek után következik a programozók ohaja-sóhaja... -
#78
sziszegőII
tag
sziszegőII
tag
Jó ez a topik
Azt azért ne tévesszük szem elől hogy az x86-os architektúra főleg az asztali gépekben virágzik meg a low end serverekben és munkaállomásokban....
Ha megnézed a szuperszámitúgépek töbségében risc proci müxik vagy itanium és egyebek.
Nézzetek meg egy mac -et vagy egy sun munkaállomást vagy sgi-t ITT A LÉNYEG AZ HOGY A HARDVERT ÉS AZ OPRENDSZERT TALÁN MÉG A SZOFTVEREKET IS UGYAN AZ A GYÁRTÓ GYÁRTOTTA. Apple mac/mac os, SUN/spark/Solaris, SGI/mips Rxxxx/ Irix Igy azért könnyebb jóval. Bár én váltig azt állitom hogy ezek az architektúrák jóval fejlettebbek mint a wintel/AMD féle.
Azt nem is kell ugye mondanom hogy azonos órajelen jóval nagyobb a teljesitménye egy MAC g4 nek mint egy pc-nek. Bár halkan jegyzem meg hogy a MAC g4 em amiről most is irok van olyan gyors mint a 2800+ A64 em HA!!! azt nézem hogy szól a zene DVD-t irok és nyitva kb 7 explorer ablak és nem látok különbséget 400 és 1800 mhz között ugyan úgy 1 giga 133 kontra 400 MHZ rammal. Persze egy nyilván van de én mint átlag user nem veszem észre ugyan úgy nyilnak az ablakok szól a zene, pörkölődik a korong és 1 s-el sem kell többet várnom semmire mint az 1800-mhzs cpu-m nál. Ugyan ez igaz a 250 MHZ-s mips-es octanomra.
De hogy érdekesebb legyen a dolog a 2 db 550-es p3 -as SGI gépemnek a sávszélje cpu felől 3.2 gb/s vag felől pedig 1,6 gb/s. Szóval a chipset is számit stb stb. Ebből látszik hogy nem a cpu az elsődleges kibic hanem maga az architektura és az oprendszer. Miért kellet várnom a win xp-re kb 2 percet mire ment a hálózat is bootoláskor??? Mikor a mac -em mire bekapcsol a monitor ott az asztal és a messenger, az sgi-m meg már bios-ból csatolja a hálózati erőforrásokat. Szóval ez a wintel dolognak van még mit ellopni a többiektől. -
DcsabaS
senior tag
Hallható/nézhető egy tanuláságos előadás egy volt inteles fő CPU tervezőtől (WMV formátumban):
Bővebben: link
Bővebben: link -
Üdv néktek!
Elképzelhető, hogy igazatok van, mégis bosszant engem (mint szűklátókörű egyént) a túlkomplikálás.
Valószínűleg ott rontották el, amikor 386-oson is DOS-t használtak...
No, részemről ennyi, nincs kedvem tovább vitázni, egyezzünk meg annyiban, hogy az x86 a legkevésbé sem esztétikus processzor. Amolyan emberi tákolmány (''jaú lász á is'').
[Szerkesztve] -
Power
senior tag
Egy link az intel compiler és a többi
http://www.aceshardware.com/read_news.jsp?id=75000387
Azért van abban valami, hogy mégiscsak az intel ismeri legjobban a saját cuccait.
Bár ahogy nézem a K8-as SPEC teszteket ott is intel compiler-t használnak. Gondolom végig nézték az összeset és amelyikkel a legmagasabb értéket kapták azt nevezték be. -
Power
senior tag
Figyu mindenki érzi, hogy nem ez a világok legjobbika.
De realitás, az hogy nagyon nagy dobbantással lehet csak tovább lépni, kicsivel jobb az kevés.
Egy radikális váltáshoz nem elég előny, az hogy technikailag jobb, ha drágább és visszafelé nem kompatibilis, ráadásul teljesítményben sem jobb egyértelműen.
Ha volna egy proci, ami 2x gyorsabb, ugyanazon az áron akkor már érdemes volna elgondolkozni egy radikális váltáson. Próbáld a vásárlók helyébe képzelni magad.
Most szoftverfejlesztéssel foglalkozom -
DcsabaS
senior tag
Kedves (#70) kisfurko!
A tömegeknek is vannak igényeik arra, hogy az új eszközzel a régi feladataikat (céljaikat) is maradéktalanul elvégezhessék. Pont azért, hogy ne kelljen megtartaniuk a felesleges régi eszközeiket.
Kérdezed:
''Mit hanyagoltam el? Miért nem továbbfejlesztés az, amit írtam? Csak azért, mert egy dologgal szakít (ami, mint már írtam, kezdettől fogva rossz volt)?''
Hatalmasan túlértékeled a szakítás nyereségét és alulértékeled a veszteségét, ugyanis:
1.) Amit Te rossznak tartasz, az NEM volt rossz, legfeljebb csak lehetett volna jobb is.
2.) Az elvetéséből fakadó nyereség mindössze pár százaléknyi tranzisztor, meg valamennyi tervezési egyszerűbbség, amit leginkább a BUTA TERVEZŐK díjaznak.
3.) Az elvetés a visszafelé való kompatibilitást olymértékben sérti, hogy a piac szemlátomást nem kér belőle.
Írod:
''Tisztában vagyok vele, hogy nem ez a legfontosabb, de legyünk már igényesek. És gondoljunk a compiler fejlesztőkre, akik ha jobban végzik a dolgukat, akkor nekünk is jobb lesz.''
Rendben van, legyünk igényesek! Az igényes tervezés nem az, hogy egy üres térre tervezel valamit, ami az ürességhez képest jól mutat, hanem azt, hogy a meglevő városrészt tudud kiegészíteni valami olyannal, hogy szebb/jobb legyen!
A CPU tervezésnél sem az a cél, hogy olyan CPU-t alkossunk, amely ''fénysebességgel'' képes végrehajtani senki által sem igényelt funkciókat, hanem az, hogy olyan CPU-t alkossunk, amely minél gyorsabban tudja ellátni a reálisan igényelt funkciókat.
És itt alapszabály (amit már írtam), hogy NEM VÁRHATÓ EL A FUTTATNI KÍVÁNT ALKALMAZÓI PROGRAMOK ÚJRAFORDÍTÁSA. Az új CPU-nak az ilyen értelemben nem optimalizált programokat is kielégítő sebességgel és megbízhatósággal kell futtatnia. Csak az operációs rendszertől, és bizonyos alapvető hardver kezelő driverektől kívánhatjuk meg az optimalizálást az új procihoz.
A jövőbeli programokat persze majd optimalizálhatják az új CPU-ra, de tartok tőle, hogy pár éven belül az ilyesmiről is végleg leszoknak.
Kérdezed:
''Különben én biztos vagyok abban, hogy a most készült x86-os procik többsége életében nem fog 16 bites kódot futtatni a BIOS-on kívül (hacsak a Windows nem tartalmaz azt). Akkor minek is ragaszkodunk a kompatibilitáshoz?''
Mert a kérdés úgy vetődik fel, hogy melyiket választanád:
1.) Egy CPU-t, amelyik csakis 64 bit-es (vagy most 32 bit-es) programokat futtat megfelelően,
2.) vagy 3-5 százalékkal drágábbért egy olyat, amelyik a régebbieket is és garantáltan!
Meglehet, hogy éppoly ritkán volt/van/lesz szükséged erre a kompatibilitásra, mint a balesetbiztosításra. De a bölcs ember (aki ugyebár hosszabb távon gondolkodik) nem hagyja figyelmen kívül az ilyesmit. -
''Határozott igény merülhet fel arra, hogy pl. egy mérésvezérlő kártyát bele lehessen tenni egy gyorsabb gépbe is, illetve a programját újabb operációs rendszeren is lehessen futtatni.''
Tömegek igénylik ezt...
''Hát ahol most tartunk, ugyanis a műszaki fejlesztés is döntően a már korábban kidolgozott módszerek TOVÁBBFEJLESZTÉSÉT jelenti, nem pedig az előző dolgokat elhanyagoló pálfordulásokat.''
Mit hanyagoltam el? Miért nem továbbfejlesztés az, amit írtam? Csak azért, mert egy dologgal szakít (ami, mint már írtam, kezdettől fogva rossz volt)?
Tisztában vagyok vele, hogy nem ez a legfontosabb, de legyünk már igényesek. És gondoljunk a compiler fejlesztőkre, akik ha jobban végzik a dolgukat, akkor nekünk is jobb lesz.
''Inkább azt vedd észre, hogy a rendszer nyitottsága, a moduláris felépítés és a kompatibilis részegység rendszere olyan hatalmas előnyt biztosított (és biztosít máig), hogy az x86-os architektúra minden fogyatékosságát feledtetni tudta!''
A szemellenzősökkel.
Különben én biztos vagyok abban, hogy a most készült x86-os procik többsége életében nem fog 16 bites kódot futtatni a BIOS-on kívül (hacsak a Windows nem tartalmaz azt). Akkor minek is ragaszkodunk a kompatibilitáshoz? -
''Nem érted. Te nem tudod majd úgy elrendezni az utasításokat ahogy kell és lehet.''
De ha van egy ''varázsló'', aki elrendezi az utasításokat, és meg is mondja, miért úgy, akkor te még változtathatsz rajta, ismerve olyan dolgokat, amiket csak az utasításokból nem lehet tudni. Én szerettem is volna ilyet írni, de mivel a mai procikról igen keveset mondanak meg, nincs elég információ hozzá.
''Az egyedi szállak végrehajtási üteme is a többi szálltól függ.''
Nyertél. -
''Attól függ milyen alkalmazás. Lesz olyan amelyik még lassul is és lesz olyan is amely +50% vagy még afelett. Ez nagyon kód függő.''
Ezért írtam, hogy átlagban 10%.
''Lényegesen egyszerűbb vezérelni.''
No ebben teljesen igazad van. De attól még radikálisabban fejlesztenek.
''Nem kell megsúgnod semmit, mert valószínű nagyobb rálátásom van, sebaj.''
Bocs, ez a megsúgós már nekem is bökte a szemem utólag...
Egyébként mit dolgozol, hogy nagy rálátásod van? Nem kötekedésből, hanem komolyan érdekel!
A végével teljesen egyetértek, de akkor is váltani kell egyszer. Vagy szerintetek tényleg járható út ez, hogy toldozzuk-foltozzuk az utasításkészletet? Sokkal nehezebb a compiler fejlesztők dolga is, hiszen egy olyan absztrakción keresztül kell optimalizálniuk, aminek már baromi kevés köze van a valósághoz. Ezek a foltozások pedig még nehezebbé teszik a majdani átállást. Továbbra is azt hiszem, hogy sokkal többe fog majd kerülni az átállás, mint most kerülne. Persze, ha kitalálnak valami óriási újítást (nagyságrenddel gyorsabb működés), akkor jöhetnek az emulátorok. -
DcsabaS
senior tag
''Erre az a megoldás, hogy a régi feladatnak megfelelő cuccost olcsóbban tovább csinálni, nem pedig az újakat a régiekhez igazítani.''
Ez egy lehetséges megoldás, de távolról sem univerzális. Határozott igény merülhet fel arra, hogy pl. egy mérésvezérlő kártyát bele lehessen tenni egy gyorsabb gépbe is, illetve a programját újabb operációs rendszeren is lehessen futtatni.
''Aki pedig P4-et vesz, mert kell a teljesítménye, az nem DOS-os programokkal szórakozik, mert valószínűleg nem a leghatékonyabb.''
Ne viccelj már! A régi Mössbauer-berendezések vezérlő szoftvere kivétel nélkül mind DOS-os volt, de az adatok utólagos processzálásához már akkor is jól jöttek volna a gyorsabb procik (csak nem voltak). Ma már gyorsabbak a gépek, de talán már a cég sem létezik, aki az eredeti berendezést csinálta, vagy ha létezik is, az újabb hardver és szoftver együtt akár több tízmillióba is kerülhet. Még mindig nem tudod elképzelni, hogy valaki új géppel szeretné használni a régi cuccot, és profitálni is a sebességből? (Az ilyen alapvető tudományos berendezések elavulása sokkal lassúbb folyamat, mint a PC-ké!)
''Hol tartanánk most, ha mi is így fejlesztenénk?''
Hát ahol most tartunk, ugyanis a műszaki fejlesztés is döntően a már korábban kidolgozott módszerek TOVÁBBFEJLESZTÉSÉT jelenti, nem pedig az előző dolgokat elhanyagoló pálfordulásokat.
''Igen, de a 8086 a kukában végezte volna az IBM nélkül. Az x86 sikeréhez kellett az IBM, de amikor elterjedt, akkor már nem.''
Inkább azt vedd észre, hogy a rendszer nyitottsága, a moduláris felépítés és a kompatibilis részegység rendszere olyan hatalmas előnyt biztosított (és biztosít máig), hogy az x86-os architektúra minden fogyatékosságát feledtetni tudta!
*************
''Nem írtam, hogy mindent megold, de 5 év múlva már nem fog senki se jobb kódot generálni kézzel, mégha szuperzseni akkor se és ez nem azért lesz, mert a compiler a legeslegjobbat generálja.''
Így van, nagyon fontos észrevenni és megérteni ezen fejlődési irány szükségszerűségét!
*************
''Az intel majd megveszik, annyira szeretnek jó compilert az IA64es procijaihoz, és már 7 éve nem siekrül. ''
Na ja, egy olyan processzorra nem is könnyű, amelynek tervezésénél a nehézségeket az utókorra hagyták (ti. a programozókra), és tervezés címén csak a triviálisnak látszó problémákra kerestek megoldást (... -
Power
senior tag
Szerinted az intel, hp, dec volt és az amd mérnökei nem tudnak kódolni vagy rosszabbul, mint te?
Megmosolyogtatsz, ugyanis pont az én véleményemmel egyezik meg az övék is.
''Értem, hogy a fordító sokkal több dolgot ki tud hámozni a kódból, azt viszont sosem fogja tudni, mit szeretnél csinálni valójában.''
Nem érted. Te nem tudod majd úgy elrendezni az utasításokat ahogy kell és lehet.
''Az SMT pedig nem alakítja át gyökeresen a programozást, sőt, szinte semmit sem változtat a programkódon (kivéve, hogy már jobban megéri másik szálakat futtatni). Az már egy magasabb szint, szerintem. A CMP szintúgy.''
A programozást is átalakítja, de nem erről beszéltem.
Honnan tudnád optimalizálni a kódot, ha sosem lesz két egyforma lefutásod?
Ne olyan programot képzelj el, amiben A pontnál hopp inditok még egy szállat, aztán B pontnál bevárod és azán kész. Képzeld el, hogy szállak ezrei futnak egyszerre egymástól csak nagyon laza függésben s a processzor egyszere többet futatt belőlük N darabot. Az egyedi szállak végrehajtási üteme is a többi szálltól függ. -
Power
senior tag
''És mivel magyarázod, hogy kb. 10%-ot gyorsult az Athlon64 attól, hogy 64-bites üzemmódban futott? Nagy része van benne a +8 regiszternek''
Attól függ milyen alkalmazás. Lesz olyan amelyik még lassul is és lesz olyan is amely +50% vagy még afelett. Ez nagyon kód függő.
''Sokkal egyszerűbb egy dp3 művelet, mi? Sokkal egyszerűbb 4 float-tal számolni, ugye? Sokkal egyszerűbb textúrát szűrni?''
Könnyebben párhuzamosítható, nem kell rendszeresen átrendezni az utasításokat, nincs annyi függőség kezelés. Lényegesen egyszerűbb vezérelni.
Nem kell megsúgnod semmit, mert valószínű nagyobb rálátásom van, sebaj.
Az Itaniumban is lényegesen bonyolultabb az ütemezés, mint egy GPU-ban.
''Ezt honnan veszed?''
Akkor fogd fel úgy az x86-ot, mint apit. Akkor mi a baj, hogy így van vagy sem?
''Nem tudom, miért utáljátok az emulátorokat. Az áttéréshez bőven elég jók.
Milyen jó is lesz majd, amikor lesz 500 utasítás, de igazából csak 100 az ajánlott.''
Utálja a fene.
Eddig nem sikerült hatékonyan implementálni, azaz jelentős teljesítmény veszteség nélkül. Ezért aki ezt az utat választja, a teljesítményből áldozz. Nézd meg az Itanumot lehet azon is futattni mindent, de valahogy mégse vesznek 5000 dollárért egy olyan gépet, amelyen olyan sebességgel futnak az alkalmazásai, mint egy 1000 dolláros gépen. Abban a szegmensben amúgy sem szeretnek váltani olyan sűrűn még gépet sem, nem hogy architechtúrát.
Ha valaki készítene egy olyan processzort ami játszva emulálna mindent és nem lenne drágább sem, akkor azzal lehetne kezdeni valamit, de ilyen csak a csak mesében van. -
-
''Mielőtt nevetgélsz mennyit is optimalizáltál prescott-ra illetve A64-re?
Ugyanis erről írtam.''
Nem tehettem, mert annyi pénzem nincs.
De nem sokkal másabb, mint előtte volt (pont a fennálló korlátok miatt). Sok ember magyarázott nekem már arról, hogy nem lehet/nem érdemes ''kézzel'' optimalizálni, de később mindig kiderült, hogy csak ők nem tudtak a compiler-nél jobbat csinálni.
''Nem írtam, hogy mindent megold, de 5 év múlva már nem fog senki se jobb kódot generálni kézzel, mégha szuperzseni akkor se és ez nem azért lesz, mert a compiler a legeslegjobbat generálja.
Hallottál már az előre betöltésről? Abszolute nem determinisztikus a kódvégrehajtási sorrendje és az adatok betöltése, kiírása.''
Ez megint olyan dolog, mint ha azt mondtad volna a 70-es évek végén, hogy senki se fog kézzel jobb processzort tervezni, mert baromi bonyolult lesz. No, hogy tervezik most?
Maximum szüksége lesz a kézzel optimalizálónak egy ''súgóra'', aki segít.
''Pont ezt mondom, hogy ezt lassan felejtheted el.
És még nem is beszéltem a SMT-ről vagy a CMP-ről, pedig pár év múlva már ilyenek fognak repkedni szinte mindenhol.''
Értem, hogy a fordító sokkal több dolgot ki tud hámozni a kódból, azt viszont sosem fogja tudni, mit szeretnél csinálni valójában.
Az SMT pedig nem alakítja át gyökeresen a programozást, sőt, szinte semmit sem változtat a programkódon (kivéve, hogy már jobban megéri másik szálakat futtatni). Az már egy magasabb szint, szerintem. A CMP szintúgy. -
''Ezek csak apró technikai részletek, egyik sem jelent problémát. Manapság nem ez akadályozza meg a minnél nagyobb teljesítmény elérését.''
És mivel magyarázod, hogy kb. 10%-ot gyorsult az Athlon64 attól, hogy 64-bites üzemmódban futott? Nagy része van benne a +8 regiszternek.
''Egyáltalán nincs. Sokkal egyszerűbb szerkezetű egységekből épük, viszont abból több van benne. Megszakítás például van-e?''
Sokkal egyszerűbb egy dp3 művelet, mi? Sokkal egyszerűbb 4 float-tal számolni, ugye? Sokkal egyszerűbb textúrát szűrni?
Tény, hogy nincs benne olyan kifinomult ütemező, de nincs is rá szükség, hiszen a bemenet igazodik a belsőhöz. Ha a CPU-t is úgy lehetne programozni, akkor kevésbé komplex ütemező kellene (lásd Itanium).
Megsúgom, talán a megszakítási alrendszer a legprimitívebb...
''Ezt senki nem mondta, ez elvárás.''
De miért elvárás? Azok a részek, amik régiek, mehetnének emulátorral.
''Mivel GPU-knál eleve több gyártó volt, ezért célszerű volt egy közös interface-t kidolgozni.''
Processzorgyártóból is több van...
Azért hoztam példának, mert a shader kódban is architektúrális változtatásokat
csináltak, mert az alatta dolgozó hardware-nek úgy jobban fekszik. Ennek ellenére a régi shader kódot is használhatod. Pl. az ATI radeon 8500 más felépítésű, mint a Geforce3, mégis megfelelő sebességgel futtatja (értsd legalább akkora) a régi kódot.
''Ha a CPU-knál is így lenne, akkor most az volna a ''porblémád''.''
Ezt honnan veszed?
Nem tudom, miért utáljátok az emulátorokat. Az áttéréshez bőven elég jók.
Milyen jó is lesz majd, amikor lesz 500 utasítás, de igazából csak 100 az ajánlott. -
Miracle
senior tag
Az intel majd megveszik, annyira szeretnek jó compilert az IA64es procijaihoz, és már 7 éve nem siekrül. nem fogok neked tudni pontos forrást adni, mert az intel weblapján kevéésé valószínű, hogy ki lesz írva, hányan dolgoznak rajta, de miután ez az itanium platform második legnagyobb problémája, de a legnagyobb, amin segíteni lehet, a több száz biztos.
-
Power
senior tag
''Látom baromi sokat optimalizáltál már...''
Mielőtt nevetgélsz mennyit is optimalizáltál prescott-ra illetve A64-re?
Ugyanis erről írtam.
''A jó compiler minden gondot megold, trallalaaaa...
Azért, mert bizonyos problémákat a szőnyeg alá söprünk, nem jelenti azt, hogy azok nem léteznek. Mondd el nekem, mit csinál a processzor (milyen kódot generál a fordító), ha több, mint hét adaton végzel műveletet? ''
Nem írtam, hogy mindent megold, de 5 év múlva már nem fog senki se jobb kódot generálni kézzel, mégha szuperzseni akkor se és ez nem azért lesz, mert a compiler a legeslegjobbat generálja.
Hallottál már az előre betöltésről? Abszolute nem determinisztikus a kódvégrehajtási sorrendje és az adatok betöltése, kiírása.
''Senki sem akar full-assembly programot írni, de a kritikus részeket kénytelen vagy kézzel optimalizálni, mert egy nagyságrenddel nagyobb rálátásod van a feladatra, mint a fordítónak.''
Pont ezt mondom, hogy ezt lassan felejtheted el.
És még nem is beszéltem a SMT-ről vagy a CMP-ről, pedig pár év múlva már ilyenek fognak repkedni szinte mindenhol. -
Power
senior tag
''Erről beszéltem én, hogy filozófiai jellegű inkább a döntés. Ha nektek ez így megfelel, legyetek boldogok vele.''
Kit érdekel, hogy 1-2 ember mit gondol vagy mi lenne a jó filozófia?
Már rég nem arról szól az egész, hogy mi lenne szép vagy jó.
''Tényleg olyan jól volt kihasználva? Akkor miért nincs L1 kód cache a P4-ben? Megmondom, azért, mert a dekóder nem tudott elég mikroutasítást pumpálni a belsőnek, ezért inkább a már dekódolt utasításokat rakja el a TRACE cache-ben (vagy hogy hívják).
''Egyszerű'' utasításfordítás? Nézted már az x86-os opcode-okat?''
Ezek csak apró technikai részletek, egyik sem jelent problémát. Manapság nem ez akadályozza meg a minnél nagyobb teljesítmény elérését.
''Van olyan komplex egy mai GPU, mint egy CPU, ezért is hoztam fel
Mit nem tud, amit egy CPU igen? Programot futtat, van már elágazás is, alapműveletek és egyéb ''finomságok''.''
Egyáltalán nincs. Sokkal egyszerűbb szerkezetű egységekből épük, viszont abból több van benne. Megszakítás például van-e?
''Ez megint hit alapú megközelítés. Ki mondta, hogy a CPU-knak binárisan kompatibilisnek kell lenniük?''
Ezt senki nem mondta, ez elvárás.
''Ki mondta, hogy a GPU-knak nem? No, jó, a GPU-k még nem futtatnak túl komplex programokat, de már most megalapozták a fejlődést (HLSL).''
Mivel GPU-knál eleve több gyártó volt, ezért célszerű volt egy közös interface-t kidolgozni. Ha a CPU-knál is így lenne, akkor most az volna a ''porblémád''.
''Én egyértelműen definiáltról beszéltem, ami annyit tesz, hogy pontosan meghatározott. Mekkora egy int mérete? Az attól függ, ugye. És ez nem jó.''
Nem az int-et kell használni, csak ott ahol nem számít a méret.
long, short pontosan definiált, a mérete is.
''De itt az volt az alapkérdés, hogy miért jó/nem jó, miben jobbak/rosszabbak a többiek, vagy tévedek?''
Egyiksem jobb:
Az összes RISC/CISC és átmenetei ugyanazokkal az alapproblémákkal küszködnek. Az ettől eltérőek meg egyelőre inkább érdekesség kategória. -
De amikor már nem tudnak nagyot durrantani ilyen tervezéssel, akkor nem lesz más lehetőség. Illetve abba gondolj bele, ha mondjuk az egyik nem jön ki új cuccal a másikkal egy időben (mert van elég tartalék pénze), és kifejleszti a sokkal jobbat. Ekkor a másik pofára esik, de be kell hoznia a lemaradást, s ő is átáll más tervezésre. Hiszen ki venné meg a kétszer olyan gyakran megjelenő szarabbat?
Ezt a rövid termékciklust is csak kitalálta az nvidia, már most is nehezen tartják. A gyártástechnológiák fejlesztése is lelassulni látszik, szóval minden amellett szól, hogy jobban ki kell használni a rendelkezésre álló lehetőségeket. -
Pötyi
őstag
''Minek vegyen P4-est''
Hát ez az! Mivel már nem lehet mást kapni! Rá van kényszerítve, hogy azt vegyen. Erre volt jó az én példám harminc hozzászólásal ezelött a POS terminállal, meg a pénzjegykiadó automatával. Minek bele az erőmű? Semmi értelme. De ha egyszer nem lehet már régit kapni?
[Szerkesztve] -
''Egy rakás olyan hardver és szoftver van, ami bár régi és tulajdonképpen elavult, nincs helyette más, és ezért nem dobhatjuk ki. Ezért a visszafelé való kompatibilitásnak nem csak a közvetlenül megelőző generációra kell vonatkoznia, hanem sokkal többre. (A régi dolgokat csak úgy kidobni amúgy sem pozitívum, csak pocsékolás.)''
Erre az a megoldás, hogy a régi feladatnak megfelelő cuccost olcsóbban tovább csinálni, nem pedig az újakat a régiekhez igazítani. Én nem is akarok semmilyen manapság is jó, öreg dolgot kidobni! Nagyon is szeretem a jól bevált dolgokat.
A problémám pont ez. Minek vegyen P4-est egy cég, ha DOS-os ügyviteli rendszert használ? Még a villanyszámlája is sokkal több lesz, s ki sem használja a procit. Aki pedig P4-et vesz, mert kell a teljesítménye, az nem DOS-os programokkal szórakozik, mert valószínűleg nem a leghatékonyabb.
''A piaci igények döntik el, hogy meddig kell visszafelé kompatibilisnek lenni. Az x86 sikere pont azt mutatja, hogy jóval tovább, mint azt sokan hitték.''
Igen, mert ez az egyetlen aduja a zintelnek. Ez piaci igény?
''Tudsz-e róla, hogy a sejtjeid alapvető biokémiai felépítése csaknem ugyanaz, mint a milliárd évekkel ezelőtt élt sejteké? És szerinted mi lett volna az élővilággal, ha eldobta volna e jól működő megoldásokat? (Vannak nem használt kövületek is, igaz, de elférnek. Miért kéne megsemmisíteni őket?''
Azért a mutációval való fejlődés során szükségszerű az, hogy a fejlettebb sokban hasonlítson az eredetire. De ez nem jelenti azt, hogy ez a legjobb út. Majd kiderül...
Hol tartanánk most, ha mi is így fejlesztenénk?
''Ez nem igaz. Annyira nem, hogy maga az IBM is belebukott, amikor az eredtileg általa kitalált PC helyébe a PS2-őt próbálta állítani. Szóval nem az IBM támogatása volt itt a lényeg, hanem egy NYITOTT és KOMPATIBILIS architektúra megjelenése, amelyre az egész iparág és a felhasználók is nagyon ráharaptak, mert szükségük volt rá. Ha nincs az IBM PC, akkor előbb-otóbb lett volna valami más, ami elég nyitott és elég kompatibilis ahhoz, hogy meghódítsa a piacot.''
Igen, de a 8086 a kukában végezte volna az IBM nélkül. Az x86 sikeréhez kellett az IBM, de amikor elterjedt, akkor már nem. -
-
''Ki szív? Te?
1. A prescott illetve A64 nem javalott assemblyben programozni.
2. Senki nem szív a 8 regiszter miatt, totálisan ki van használva az összes(ja, hogy valaki megszokta, hogy saját maga varacskol vele - na ezt felejtse el, de ez az összes jövőbeni processzornál így lesz).
3. Az, hogy mi szükségszerű az a jó compiler eldönti.''
Ha-ha-ha-ha...
Látom baromi sokat optimalizáltál már...
A jó compiler minden gondot megold, trallalaaaa...
Azért, mert bizonyos problémákat a szőnyeg alá söprünk, nem jelenti azt, hogy azok nem léteznek. Mondd el nekem, mit csinál a processzor (milyen kódot generál a fordító), ha több, mint hét adaton végzel műveletet? Használja a memóriát (L1 cache késleltetése bejön). Tud ezen változtatni bármilyen fordító? Véletlenül bővítették ki 16-ra a regiszterek számát az x86-64-ben?
Senki sem akar full-assembly programot írni, de a kritikus részeket kénytelen vagy kézzel optimalizálni, mert egy nagyságrenddel nagyobb rálátásod van a feladatra, mint a fordítónak. -
Van olyan komplex egy mai GPU, mint egy CPU, ezért is hoztam fel. Mit nem tud, amit egy CPU igen? Programot futtat, van már elágazás is, alapműveletek és egyéb ''finomságok''. Ez megint hit alapú megközelítés. Ki mondta, hogy a CPU-knak binárisan kompatibilisnek kell lenniük? Ki mondta, hogy a GPU-knak nem
Azert azt tegyuk hozza, hogy GPU-t tervezni joval egyszerubb moka, mint CPU-t. Legalabbis ATTERVEZNI mindenkeppen. Alacsony orajel, sima HDL-es leirassal megoldhato. -
''Azért a mélyen ez már részben megtörtént. Egyrészt ugyan kompatibilisek az x86-tal a legújabb P4 és A64, de egy csomó utasítást már nem érdemes, sőt kifejezetten ellenjavalott használni (pl. x87 utasításait). Van ebben fejlődés.''
Ezzel teljes mértékben tisztában vagyok, de ebben az az abszurd, hogy a gyakran használt utasításokat nehezebb dekódolni, mint a nem javallottakat.
''Ez tudod olyan mérnök gondolkodás. A piac nem igényli.
Ahogy most állunk még sok-sok évig kitart, de pontosan még addig se lát senki se előre.''
Erről beszéltem én, hogy filozófiai jellegű inkább a döntés. Ha nektek ez így megfelel, legyetek boldogok vele.
''Márhogyne volna jól kihasználva???
Egy egyszerű utasítás fordítás és már ugyanott vagy.''
Tényleg olyan jól volt kihasználva? Akkor miért nincs L1 kód cache a P4-ben? Megmondom, azért, mert a dekóder nem tudott elég mikroutasítást pumpálni a belsőnek, ezért inkább a már dekódolt utasításokat rakja el a TRACE cache-ben (vagy hogy hívják).
''Egyszerű'' utasításfordítás? Nézted már az x86-os opcode-okat?
''Ne hasonlíts már egy cél chipet egy általános cpu-hoz.
A GPU-knak nem kell binárisan kompatibilisnek lennie.''
Van olyan komplex egy mai GPU, mint egy CPU, ezért is hoztam fel. Mit nem tud, amit egy CPU igen? Programot futtat, van már elágazás is, alapműveletek és egyéb ''finomságok''. Ez megint hit alapú megközelítés. Ki mondta, hogy a CPU-knak binárisan kompatibilisnek kell lenniük? Ki mondta, hogy a GPU-knak nem?
No, jó, a GPU-k még nem futtatnak túl komplex programokat, de már most megalapozták a fejlődést (HLSL).
''Már, hogy ne volnának előre definiált típusok???
Vannak, csak használni kell, ha nem használod az a te felelőséged.''
Én egyértelműen definiáltról beszéltem, ami annyit tesz, hogy pontosan meghatározott. Mekkora egy int mérete? Az attól függ, ugye. És ez nem jó.
''Akkor egyetlen vetélytárs volt az M68k család, de akkor most az szídnád, mai szemmel annak is elég korlátolt az utasításkészlete.''
Korántsem annyira, mint az x86-é. Kapásból 16 bites egy utasítás kód, ami jóval nagyobb szabadságot tesz lehetővé bővítés szempontjából. Arról nem is beszélve, hogy Motoroláék a családon belül komoly változtatásokat csináltak, ha úgy gondolták, kell. A 68030-ba például nem egyszerűen beleintegrálták az MMU-t, hanem kidobták belőle a keveset használt dolgokat. Vagy a 68040-be az FPU nem csak belevedrezték, mint a zinteléknél, hanem kihagyták a függvényeket, csomó konstanst, de számolni sokkal gyorsabban tudott (ha jól emlékszem 2 ciklus volt a szorzás). A 68000-t sem egyszerűen kibővítették, hanem az elcseszett dolgokat megváltoztatták.
''Lehet szeretni és nem szeretni, de x86 van és kész.''
De itt az volt az alapkérdés, hogy miért jó/nem jó, miben jobbak/rosszabbak a többiek, vagy tévedek? -
-
DcsabaS
senior tag
''Nincs a kompatibilitással semmi baj, mindaddig, amíg csak az előző generációval kompatibilis. Régebbivel maximum akkor érdemes, ha annyira jó volt (az x86 esetében ez nagyon nem igaz).''
Egy rakás olyan hardver és szoftver van, ami bár régi és tulajdonképpen elavult, nincs helyette más, és ezért nem dobhatjuk ki. Ezért a visszafelé való kompatibilitásnak nem csak a közvetlenül megelőző generációra kell vonatkoznia, hanem sokkal többre. (A régi dolgokat csak úgy kidobni amúgy sem pozitívum, csak pocsékolás.)
''Érdekes, hogy rossz terméknek tartod, mégis pozitívumként tartod számon, hogy a leggazdagabb gyártóé...''
Ez természetes, hiszen ha egy termék mögött erősebb cég áll, akkor kisebb az esélye annak, hogy a cég nagy hirtelen tönkremegy, és megszűnik a termék támogatása.
''Nem is mondta senki, hogy kétévente új architektúra kell, de azért nem kéne húsz évre visszamenőleg kompatibilisnek lenni... Valamikor kell váltani, ha halogatod, annál nehezebb.''
A piaci igények döntik el, hogy meddig kell visszafelé kompatibilisnek lenni. Az x86 sikere pont azt mutatja, hogy jóval tovább, mint azt sokan hitték. Ezzel együtt időnként tényleg célszerű váltani. Éspedig akkor, amikor MUSZÁJ.
''Ezért kéne kidobni az x86 architektúrát. Értsétek meg, hogy a mai x86-osnak hívott processzorok belül nem is hasonlítanak az eredeti x86 architektúrához!''
Tudsz-e róla, hogy a sejtjeid alapvető biokémiai felépítése csaknem ugyanaz, mint a milliárd évekkel ezelőtt élt sejteké? És szerinted mi lett volna az élővilággal, ha eldobta volna e jól működő megoldásokat? (Vannak nem használt kövületek is, igaz, de elférnek. Miért kéne megsemmisíteni őket? Mindig csodálkozom azokon, akik vesznek a régi 1.3 GByte-os HDD helyett egy 40 GByte-osat, és ahelyett, hogy kompletten átmásolnák a régi tartalmát, nekiállnak ''garasoskodni'', hogy melyik 10 kByte-os file-t nem kell átmásolni - aztán egy hónap múlva jönnek rá, hogy mégis csak jó lett volna átmásolni, de addigra már esetleg el is adták, vagy eldobták a régi HDD-t, de minimum formattálták, mert nem tudták elviselni sem a gondolatot, hogy ne szépen, tisztán, azaz üresen tegyék el...)
Egy korszerű prociban a régivel való kompatibilitásért nem kell túl sok tranzisztorral fizetnünk, csupán körültekintőbb tervezéssel.
''Azt se felejtsük el, hogy az x86 nem attól lett domináns, hogy olyan remek, hanem mert az IBM hozzásegítette ehhez a szutykos PC-vel. ''
Ez nem igaz. Annyira nem, hogy maga az IBM is belebukott, amikor az eredtileg általa kitalált PC helyébe a PS2-őt próbálta állítani. Szóval nem az IBM támogatása volt itt a lényeg, hanem egy NYITOTT és KOMPATIBILIS architektúra megjelenése, amelyre az egész iparág és a felhasználók is nagyon ráharaptak, mert szükségük volt rá. Ha nincs az IBM PC, akkor előbb-otóbb lett volna valami más, ami elég nyitott és elég kompatibilis ahhoz, hogy meghódítsa a piacot. -
-
Power
senior tag
''Én nem mondtam, hogy teljesen RISC legyen, jó ez a CISC/RISC hibrid. Egyszerűen csak újra kéne gyártani az architektúrának (itt a belső realizációt értem) megfelelőre az utasításkészletet. Miért szívunk 8 regiszterrel, ha belül vagy 48 (mittomén mennyi van manapság) van? Miért szívunk azzal, hogy az egyik forrásoperandust felülírja az eredmény, ha belül ez nem szükségszerű? Lehetne még sorolni.''
Ki szív? Te?
1. A prescott illetve A64 nem javalott assemblyben programozni.
2. Senki nem szív a 8 regiszter miatt, totálisan ki van használva az összes(ja, hogy valaki megszokta, hogy saját maga varacskol vele - na ezt felejtse el, de ez az összes jövőbeni processzornál így lesz).
3. Az, hogy mi szükségszerű az a jó compiler eldönti.
''Ez igaz, de mint fentebb írtam, minél később, annál nehezebb/drágább.''
Egyelőre nem éri meg, mert van még benne bőven szufla.
''A ''paríros'' munkáról is áttértek ''számítógépesre'', pedig az szeritem nagyobb meló, mint újrafordítani egy kódot.''
Egy újrafordítás az semmi. Attól aztán még nem fog jól működni.
Validálni kell a szoftvert.
Mit gondolsz áramlanak az Itaniumos szoftverek? Messze nem egy újrafordítás az egész. -
Power
senior tag
''Nincs a kompatibilitással semmi baj, mindaddig, amíg csak az előző generációval kompatibilis. Régebbivel maximum akkor érdemes, ha annyira jó volt (az x86 esetében ez nagyon nem igaz). Így szép lassan le lehetne építeni.
Nézd meg a Pentium 4-et (az első példányokat, vagy a Prescott-ot)! Lassabbak voltak, mint az előző generáció, de idővel behozták. Valahogy így képzelném el az utasításkészlet-váltást is.''
Azért a mélyen ez már részben megtörtént. Egyrészt ugyan kompatibilisek az x86-tal a legújabb P4 és A64, de egy csomó utasítást már nem érdemes, sőt kifejezetten ellenjavalott használni (pl. x87 utasításait). Van ebben fejlődés.
Sok 100 milliárd értékű szoftvert egyszerűen nem lehet kidobni, mert szükség van rá és a jövőben is szükség lesz rá. Képzeld el, egy autót ami nem kompatibilis az úttal és új útat kellene építeni.
Az Itanium-nak nem a hw a gyenge pontja.
''Nem is mondta senki, hogy kétévente új architektúra kell, de azért nem kéne húsz évre visszamenőleg kompatibilisnek lenni... Valamikor kell váltani, ha halogatod, annál nehezebb.''
Ez tudod olyan mérnök gondolkodás. A piac nem igényli.
Ahogy most állunk még sok-sok évig kitart, de pontosan még addig se lát senki se előre.
''Értsétek meg, hogy a mai x86-osnak hívott processzorok belül nem is hasonlítanak az eredeti x86 architektúrához! Ott figyelnek a nem jól kihasznált egységek, mert ócska, régi architektúrát modelleznek.''
Márhogyne volna jól kihasználva???
Egy egyszerű utasítás fordítás és már ugyanott vagy.
A mai RISC processzorok is ugyanabban a helyzetben vannak, sőt a legtöbb még csak nem is bírta a versenyt.
''Érdekes, hogy a grafikus chip-ek piacán baromira nem így megy. Ott mernek változtatni, ennek köszönhetően igen nagy fejlődés van. ''
Ne hasonlíts már egy cél chipet egy általános cpu-hoz.
A GPU-knak nem kell binárisan kompatibilisnek lennie.
''pont ezt utálom a C-ben, hogy nincsenek egyértelműen definiálva típusok, ebből jön a legtöbb újrafordítási szívás''
Már, hogy ne volnának előre definiált típusok???
Vannak, csak használni kell, ha nem használod az a te felelőséged.
''Azt se felejtsük el, hogy az x86 nem attól lett domináns, hogy olyan remek, hanem mert az IBM hozzásegítette ehhez a szutykos PC-vel. Az akkori vetélytárs processzorok jobbak és keresettebbek (darabszámra nem biztos, de géptípusok közt biztos) voltak.''
Akkor egyetlen vetélytárs volt az M68k család, de akkor most az szídnád, mai szemmel annak is elég korlátolt az utasításkészlete.
Lehet szeretni és nem szeretni, de x86 van és kész. -
''de vedd figyelembe, hogy ha te már a binárist lebontod a kérdéses RISC utasításokra, akkor az olyen szinten kezdi el zabálni a memóriasávszélességet, hogy az csodálatos. a cache-ről már nem is beszélve. sokkal gyakrabbal lesz cache-miss, ami a jelenlegi a processzoroknál messze a legnagyobb problémát és teljesítmény-korlátozást jelenti.
Egyébként ha csak egy RISC magra cserélnénk ki a processzormagot, akkor azzal nem sokat javítanánk a helyzeten, ugyanis az architektúra felépítése szerintem tovább ''öröklődne'' annak ellenére, hogy kevesebb utasítással van megvalósítva. Ha már valamire váltunk, akkor egy itaniumhoz hasinló komolyságú változáson érdemes gondolkozni, mert a RISC/CISC cuccok napjai... hát nem azt mondom, hogy meg vannak számlálva, de a korlátaik már jóval élesebben kirajzolódtak, mint az itaniumnak.''
Én nem mondtam, hogy teljesen RISC legyen, jó ez a CISC/RISC hibrid. Egyszerűen csak újra kéne gyártani az architektúrának (itt a belső realizációt értem) megfelelőre az utasításkészletet. Miért szívunk 8 regiszterrel, ha belül vagy 48 (mittomén mennyi van manapság) van? Miért szívunk azzal, hogy az egyik forrásoperandust felülírja az eredmény, ha belül ez nem szükségszerű? Lehetne még sorolni.
''tulajdonképpen most a legfontosabb szerintem a kompatibilitás, mert a modern szoftverek(a nagyobbak) a bonyolultságuk miatt csak hatalmas összegekért írhatók át.''
Ez igaz, de mint fentebb írtam, minél később, annál nehezebb/drágább. A ''paríros'' munkáról is áttértek ''számítógépesre'', pedig az szeritem nagyobb meló, mint újrafordítani egy kódot.
No, minden jót! Mára elég lesz belőlem. -
''Az emberek csak akkor dobják ki a régit, ha már van helyette egyértelműen jobb - nagyon helyesen. Vagyis amellett, hogy az új néhány dologban lehet jobb, semmi lényeges szempontból (pl. kompatibilitás) nem lehet rosszabb - mert akkor meg kellene tartani a régit is.''
Nem voltam érthető, úgy látszik...
Nincs a kompatibilitással semmi baj, mindaddig, amíg csak az előző generációval kompatibilis. Régebbivel maximum akkor érdemes, ha annyira jó volt (az x86 esetében ez nagyon nem igaz). Így szép lassan le lehetne építeni.
Nézd meg a Pentium 4-et (az első példányokat, vagy a Prescott-ot)! Lassabbak voltak, mint az előző generáció, de idővel behozták. Valahogy így képzelném el az utasításkészlet-váltást is.
''Ugyan minek?!? Drága. Melegszik. Ha nincs optimalizálva a kód, akkor még lassú is. A megbízhatósága is még kérdéses. A platform stabilitása (jövőbeli kifutása) szintén. Egyetlen pozitívuma, hogy egy rendkívül tőkeerős cég áll mögötte.''
Szerintem abba a szegmensbe nem drága, kb. annyit kérnek érte, amit ér. Más kérdés, hogy nekem sem tetszik, de sokkal jobb, mint az x86. A kódot pedig azért kell optimalizálni, mert teljesen másként működik, az utasítások ''párosítását'' a fordítónak kell megcsinálni, nem beépített scheduler csinálja, mint egy mai x86-osban.
Érdekes, hogy rossz terméknek tartod, mégis pozitívumként tartod számon, hogy a leggazdagabb gyártóé...
''Tévedés. Az Itániumnak majd a k+1-edik verziója lesz a ''nyerő'', de csak annak árán, hogy pont azokat a bonyolításokat teszik majd bele vissza, amit a szándékolt elvi egyszerűség/inkompatibilitás jegyében kihagytak.''
Majd meglátjuk, én nem így gondolom.
''Ez így nem teljesen igaz. Gondolj csak arra, hogy ha hosszú távon szeretnél életben maradni, akkor először is jó, ha gyakori időpillanatokban veszel levegőt. Nem követhetsz olyan stratégiát, hogy ''most pár napig nem veszek levegőt, cserében majd utána 10-szer annyit''. Magyarán, a jövő oltárán sem áldozhatjuk fel (pláne rendszeresen) a jelent.''
Nem is mondta senki, hogy kétévente új architektúra kell, de azért nem kéne húsz évre visszamenőleg kompatibilisnek lenni... Valamikor kell váltani, ha halogatod, annál nehezebb.
''Én inkább azt mondanám, hogy ha van előttünk egy természetes akadály, amiért mindenképpen változtatni kell, akkor ELÉG NAGYOT kell változtatnunk. Pl. ha már lecseréljük a PCI buszt, akkor valami olyanra cseréljük le, ami elég hosszú ideig jó lehet.''
Én is ezt gondolom. Ezért kéne kidobni az x86 architektúrát. Értsétek meg, hogy a mai x86-osnak hívott processzorok belül nem is hasonlítanak az eredeti x86 architektúrához! Ott figyelnek a nem jól kihasznált egységek, mert ócska, régi architektúrát modelleznek.
''A chip gyártók (leszámítva az Intelt) kényszerhelyzetben vannak. Sokan és sokszor próbáltak meg jobbat csinálni az x86-nál, de az élet azt bizonyítja, hogy ez csak egyes szempontokból volt sikeres.''
Érdekes, hogy a grafikus chip-ek piacán baromira nem így megy. Ott mernek változtatni, ennek köszönhetően igen nagy fejlődés van. Persze ehhez az is kellett, hogy legyen egy köztes szint (DirectX, OpenGL), de erre ott vannak a programnyelvek (pont ezt utálom a C-ben, hogy nincsenek egyértelműen definiálva típusok, ebből jön a legtöbb újrafordítási szívás).
Azt se felejtsük el, hogy az x86 nem attól lett domináns, hogy olyan remek, hanem mert az IBM hozzásegítette ehhez a szutykos PC-vel. Az akkori vetélytárs processzorok jobbak és keresettebbek (darabszámra nem biztos, de géptípusok közt biztos) voltak. -
Miracle
senior tag
nem fejezem be, mert elfelejtettem, amit akartam mondani.
''Szerintem az átfordító hatékonyságával nem lenne akkora probléma, mert az alatta levő struktúra ugyanaz (mármint a CISC proci belseje úgyis RISC). (...)''
de vedd figyelembe, hogy ha te már a binárist lebontod a kérdéses RISC utasításokra, akkor az olyen szinten kezdi el zabálni a memóriasávszélességet, hogy az csodálatos. a cache-ről már nem is beszélve. sokkal gyakrabbal lesz cache-miss, ami a jelenlegi a processzoroknál messze a legnagyobb problémát és teljesítmény-korlátozást jelenti.
Egyébként ha csak egy RISC magra cserélnénk ki a processzormagot, akkor azzal nem sokat javítanánk a helyzeten, ugyanis az architektúra felépítése szerintem tovább ''öröklődne'' annak ellenére, hogy kevesebb utasítással van megvalósítva. Ha már valamire váltunk, akkor egy itaniumhoz hasinló komolyságú változáson érdemes gondolkozni, mert a RISC/CISC cuccok napjai... hát nem azt mondom, hogy meg vannak számlálva, de a korlátaik már jóval élesebben kirajzolódtak, mint az itaniumnak.
most jegyezném meg, hogy a SUN megoldotta a problémát, és jobban mint az itanium, de ez nagyon off lenne, meg gondolom a niagara nem új nektek.
azok a processzortervezési irányelvek, amiket felvázoltál szerintem egy kicsit érdekesek.
tulajdonképpen most a legfontosabb szerintem a kompatibilitás, mert a modern szoftverek(a nagyobbak) a bonyolultságuk miatt csak hatalmas összegekért írhatók át. a rossz kompatibilitás az egyetlen oka annak, hogy az itanium nincs elterjedve.
a másik nagy problémám az az, hogy a fenti modelt(mondjuk hogy jó) az itaniumra alkalmaztad. ez csak azért baj, mert a fenti model egy desktop CPUra jó, de az itaniumnak még csak távolról sincsenek jelenleg desktop hajlamai.
az itanium a saját szegmensében(nagyteljesítményű drága workstation/szerver) azt kell hogy mondjam a legolcsóbb. a versentársai: HP-PARISC POWER4 (5 is majd) SUN ultrasparc sorozat DE!C alpha(tudom, halott... még) ezek közül bizony az itanium a legolcsóbb, akárhogy is vesszük a dolgot. a nagy hőtermelés valóban jelent egy kis problémát, de a prescotthoz képest nem is olyan nagyot
az athlon 64 meg nem mintaszerűen van tervezve, hanem az egyetlen módon, amit az AMD megengedhetett magának.
az intel megteheti, hogy 10 évig passzióból fejleszt egy platformot, mielőtt abból haszna lesz.
az AMD nem teheti meg, mert nincs annyi pénze.
azon kícül az AMD nagyon ácsingózik a XEONok piacára, ahol tulajdon képpen a desktop CPUkkal azonos áron tud procit gyártani, de körülbelül 10szeres áron eladni. ez motiválta őket leginkább.
és akárhogy is nézzük az athlon 64 nem az itanium ellenfele, hanem a XEONoknak. más szegmensbe irányítják a kettőt.
azaz az AMd nagyon irányítaná felfelé is, de oda az intel sem nagyon tud betörni(nagyon konzervatív piac) az AMD meg a 0 presztízsével még kevésbé. de nyugi: a XEONok piacán(low-end szerver, workstation) bizony hatalmas nyereségre tehet szert. -
DcsabaS
senior tag
''de ezek egymásnak ellentmondó tényezők. ''
Ezért nagyon fontos helyesen felmérni, hogy mi közöttük a fontossági sorrend.
''Érdekes, hogy az emberek mindent kidobnak a kukába, a programokat viszont nem hajlandók.''
Az emberek csak akkor dobják ki a régit, ha már van helyette egyértelműen jobb - nagyon helyesen. Vagyis amellett, hogy az új néhány dologban lehet jobb, semmi lényeges szempontból (pl. kompatibilitás) nem lehet rosszabb - mert akkor meg kellene tartani a régit is.
''Értem én, hogy drága dolog átállni, de egy 20 éves programot még emulációval is többszörös sebességgel lehet futtatni (gondolj az AMIGA emulátorra, ami a hardware-t is!!! emulálja).''
Csakhogy nem a 20 éves programok emulációval való futtatási sebessége a kérdéses, hanem a jelen és a közelmúlt programjaié. Senki sem veszi jó néven, ha az új és drága rendszer lassúbb. Tehát az újnak annyival gyorsabbnak kell lennie (''hardveresen''), hogy még az emuláció dacára se legyen kisebb a sebessége a réginél. Ha ez megoldható, akkor lehet szó emulálásról.
''Ha már az Athlon 64-et és az Itanium-ot említetted, bizony lazán odaver az Itanium.''
Ugyan minek?!? Drága. Melegszik. Ha nincs optimalizálva a kód, akkor még lassú is. A megbízhatósága is még kérdéses. A platform stabilitása (jövőbeli kifutása) szintén. Egyetlen pozitívuma, hogy egy rendkívül tőkeerős cég áll mögötte.
''Tudom, nekünk tömegembereknek az Athlon 64 a nyerő, mert az most elérhető. De az Itanium féle procik is azok lesznek (ill. hamarabb lehettek volna, ha nincs ez a görcsös ragaszkodás és a zintel bénázásai).''
Tévedés. Az Itániumnak majd a k+1-edik verziója lesz a ''nyerő'', de csak annak árán, hogy pont azokat a bonyolításokat teszik majd bele vissza, amit a szándékolt elvi egyszerűség/inkompatibilitás jegyében kihagytak.
''Ez a stratégia viszont nem hosszútávú, csak azt veszi figyelembe, hogy a termék sikeres legyen a megjelenése időpontjában.''
Ez így nem teljesen igaz. Gondolj csak arra, hogy ha hosszú távon szeretnél életben maradni, akkor először is jó, ha gyakori időpillanatokban veszel levegőt. Nem követhetsz olyan stratégiát, hogy ''most pár napig nem veszek levegőt, cserében majd utána 10-szer annyit''. Magyarán, a jövő oltárán sem áldozhatjuk fel (pláne rendszeresen) a jelent.
''Nem mondom azt, hogy minden átmenet nélkül álljon át mindenki, de ha valami akadályoz bennünket, azt minél előbb meg kell szüntetni.''
Én inkább azt mondanám, hogy ha van előttünk egy természetes akadály, amiért mindenképpen változtatni kell, akkor ELÉG NAGYOT kell változtatnunk. Pl. ha már lecseréljük a PCI buszt, akkor valami olyanra cseréljük le, ami elég hosszú ideig jó lehet.
''Arról nem is beszélve, hogy egy pár éve egy átlag felhasználó (tehát a célréteg) nem használja ki a rendelkezésre álló számítási kapacitást, így eljöttnek tekinthetjük az időt a váltásra, hiszen nem húzna vissza annyira.''
A felhasználók tényleg nem használják ki optimálisan a számítási kapacitásaikat, de ettől még nem kívánnak maguknak lassúbbat, illetve olyat, amin akkor sem futna egy régi program, ha azt nagyon szeretnék.
''A probléma a chip gyártókkal van, ha azt mondanák, hogy holnaptól nincs x86, mindenki átállna, de sajnos túl sok bőrt le lehet még nyúzni erről (illetve talán attól félnek, hogy akkor nem őket választanák, mert megszűnne a kényszer).''
A chip gyártók (leszámítva az Intelt) kényszerhelyzetben vannak. Sokan és sokszor próbáltak meg jobbat csinálni az x86-nál, de az élet azt bizonyítja, hogy ez csak egyes szempontokból volt sikeres. -
Hmm...
Ez így eléggé manager ízű.
Én egy szóval sem mondtam, hogy ki kell dobni a régit. Szerintem a szart kell kidobni.
Könnyű megmondani a frankót felülről (ezt nem rád értem), de ezek egymásnak ellentmondó tényezők. Természetesen minden mérnök tisztában kell legyen vele, hogy ez a dolgok menete, mégis ne ez vezérelje őket. A profit legyen a közgazdász/managga feladata, a mérnök legyen igényes.
Érdekes, hogy az emberek mindent kidobnak a kukába, a programokat viszont nem hajlandók. Értem én, hogy drága dolog átállni, de egy 20 éves programot még emulációval is többszörös sebességgel lehet futtatni (gondolj az AMIGA emulátorra, ami a hardware-t is!!! emulálja). Bizony, már legalább tíz éve elavultnak számított a 16-bites kód, de a mai napig lehet futtatni. Minek? Simán mehetne emulátorral. Elfogadható lenne a sebessége is. A sokat szidott Itanium is lazán futtat pár évvel ezelőtti x86 kódot jó sebességgel (tévedés ne essék, szerintem sem teljesen OK az a CPU).
Ha már az Athlon 64-et és az Itanium-ot említetted, bizony lazán odaver az Itanium. Tudom, nekünk tömegembereknek az Athlon 64 a nyerő, mert az most elérhető. De az Itanium féle procik is azok lesznek (ill. hamarabb lehettek volna, ha nincs ez a görcsös ragaszkodás és a zintel bénázásai).
Emlékszem még arra, amikor nem akartak átállni 32-bites módra az emberek, és vinnyogtak. A win95 nevű szörny is emiatt született. Ne felejtsük el, a 386-os 1987-re lett kész a win95 pedig 95 végén jutott a néphez. 8 év!!! Tudom, volt olyan is, hogy NT, de az akkor komolytalan volt (túl nagy rendszerigény). Más gépeken viszont vígan futottak 32-bites programok (tömegtermékeken, mint AMIGA, Macintosh).
A sok szöveg után egy kis tanulság:
Ezen a ponton a vita filozófiai irányba terelődik, mert a jelenlegi körülmények között teljesen igazad van (itt feltételezzül, hogy az emberek nem kooperatívak). Pont úgy kell csinálni, ahogy írtad. Ez a stratégia viszont nem hosszútávú, csak azt veszi figyelembe, hogy a termék sikeres legyen a megjelenése időpontjában. Igaz, ha a célod kizárólag a profit, akkor hosszútávon is jó ez neked, másnak viszont nem.
Nem mondom azt, hogy minden átmenet nélkül álljon át mindenki, de ha valami akadályoz bennünket, azt minél előbb meg kell szüntetni. Nem érdemes hurcolni magunkkal megszokásból hülyeségeket, a történelem során ez sosem vezetett sehova.
Arról nem is beszélve, hogy egy pár éve egy átlag felhasználó (tehát a célréteg) nem használja ki a rendelkezésre álló számítási kapacitást, így eljöttnek tekinthetjük az időt a váltásra, hiszen nem húzna vissza annyira.
A probléma a chip gyártókkal van, ha azt mondanák, hogy holnaptól nincs x86, mindenki átállna, de sajnos túl sok bőrt le lehet még nyúzni erről (illetve talán attól félnek, hogy akkor nem őket választanák, mert megszűnne a kényszer).
Ha már a kényszernél tartunk, nem értem, hogy miért nem indul monopol ellenes per a zintel ellen.
Zárszónak pedig csak annyit, hogy én nagyon idealista vagyok...
[Szerkesztve] -
Szia!
''láttam én már egy duál XEON alaplapon ISA slotot. el is magyarázták, hogy miért: ha valaki megvesz a szerverébe egy diagnosztikai kártyát(ami nem tudom, mit csinál, de biztosan jó valamire az ára alapján: 4000-5000 USD) skkor az szeretné használni. és az, aki vete azt a lapot bele is tette a saját diag. zsugáját. tehát az az ISA még nincs teljesen elfeledve.''
Öööö... Itt félre értettél. Nem az a bajom, hogy van ISA slot, hanem az, hogy ha nincs ISA slot, akkor minek támogatni a hozzá tartozó baromságokat. Bár csak lenne még ISA slot-om, akkor használhatnám itthon a GUS PnP-t
''nem mondtam, hogy hatékony volt a kód: nem volt az, de ez nem a CISC processzorok, hanem a fordító-technológiák fejletlensége miatt volt.''
Tudom, írtam is, de mindent a megadott fejlettségi szint szerint kell végezni (különben túl drága). Arról nem is beszélve, hogy sajnos a processzor utasításkészletének a bonyolódásával a fordító bonyolultsága nem lineárisan növekszik, szerintem.
Szerintem az átfordító hatékonyságával nem lenne akkora probléma, mert az alatta levő struktúra ugyanaz (mármint a CISC proci belseje úgyis RISC). Így ha az átfodított kódot közel optimálisra gyúrjuk, akkor majdnem ugyanúgy megy. Ez az irány pedig azért könnyebb, mert rugalmasabb a cél kód. Tehát én programozási szempontból különböző architektúrákra gondoltam, nem két tetszőleges architektúrára (magyarul ki kell dobni a régi dekódert+ütemező egy részét és jobbat odatenni, más nem változik, majd csak a következő generációban, hiszen akkorra már átálltak).
Érted, hogy mire gondolok? Nem erősségem a magyarázás... -
DcsabaS
senior tag
A fiatalok valahogy mindig ki szeretnék dobni a régit, hogy teljesen tiszta lappal indulhassanak és alkothassanak valami újat. Aztán az a vége, hogy a megálmodott új dolog pont arra nem jó, amire kellene.
Helyesen a CPU tervezésnél is azt kell helyesen látni, hogy mi a prioritási sorrend, figyelembe véve a várható felhasználókat. Az x86-os procik eddigi sikerét a következő sorrendben látom:
1.) Legyen alkalmas az elvégzendő feladatra. (Másszóval, támogassa a szükséges funkciókat, még ha körülményesen, vagy relatíve lassan is. Tartalmazhat hibákat is, csak ne túl sokat.)
2.) Legyen elég olcsó. (Vagyis tömeges igényeket szolgáljon ki, és nem lehet egyetlen feladatra mások rovására túlzottan specializált, sem pedig túl sok tranzisztort felhasználó.)
3.) Legyen visszafelé is kompatibilis, vagyis a korábbi programokat az újabb CPU-kon is lehessen futtatni, illetve tudjon együttműködni a korábban kifejlesztett hardver eszközökkel.
4.) Legyen elég egyszerű a használata. (Vagyis elfogadható teljesítményt kell nyújtania bármiféle optimalizáció nélkül is.)
Ezután jönnek a luxus szempontok:
5.) Legyen minél nagyobb processzálási teljesítményű.
6.) Legyen minél megbízhatóbb.
7.) Fogyasszon minél kevesebbet.
Akik az x86-os CPU-k halálát kívánják, általában szem elől tévesztik a 3.) szempontot, és félreértik a 4.)-est. Ugyanis általában csak annyit látnak, hogy egy RISC CPU-t belülről könnyebb programozni, és nem látják, hogy a felhasználóktól az NEM várható el, hogy a CPU cseréjénél újrafordítsák és optimalizálják az általuk használt programjaikat. Az optimalizálások szükséges részét magának a CPU-nak _KELL_ elvégeznie, különben effektíve csak olyan lesz az új proci, ami csak a semmit tudja rendkívül gyorsan processzálni.
Az Itánium egyébként iskolapéldája az ilyen idióta CPU tervezésnek. Gyakorlatilag csak az 5.) szempontnak adtak nagy prioritást, szinte minden mást elhanyagoltak. (És még az 5.) szempont is csak speciális esetekben érvényesülhet.)
Ezzel szemben az Athlon64 szinte mintaszerűen van tervezve, azaz nagyon helyes arányban súlyozták a szempontokat. -
Miracle
senior tag
''Jó, jó, tudom, hogy PCI-on keresztül is lehet használni, de minek, ha a PCI eredeti megoldása jobb...''
láttam én már egy duál XEON alaplapon ISA slotot. el is magyarázták, hogy miért: ha valaki megvesz a szerverébe egy diagnosztikai kártyát(ami nem tudom, mit csinál, de biztosan jó valamire az ára alapján: 4000-5000 USD) skkor az szeretné használni. és az, aki vete azt a lapot bele is tette a saját diag. zsugáját. tehát az az ISA még nincs teljesen elfeledve.
''De nem!
Mivel régen nem volt annyira menő az órajel emelése, ill. nehézségekbe is ütközött, így más utat kellett találni a teljesítmény növeléséhez. Köztudott volt, hogy a CISC processzorokat csak assemblyben lehetett jól kihasználni, a fordítók főként csak az egyszerűbb utasításokat használták. Nagyon nincs igazad abban, hogy a fordítók által generált kód hatékonyságával nem volt probléma.''
nem mondtam, hogy hatékony volt a kód: nem volt az, de ez nem a CISC processzorok, hanem a fordító-technológiák fejletlensége miatt volt. a mikrokód meg vagy 20-25 éve amikor a RISC forradalom elkezdődött már mind az IBM, mind a DEC rendszereit fojtogatta. akkor szakított nagyot a SUN. A tanenbaum féle architektúrás könyvben ez nagyon szépen le van írva.
''Azt nem értem igazából, hogy miért nem lehet a régi utasításkészletet kidobni, s az újakkal helyettesíteni just-in-time compilerrel mondjuk. Vagy a létező programot átfordítani (nem újrafordítani!). Volt ilyenje a zinteléknek a 8086-osnál, ami 8080-ról fordított. Belül úgyis ezt csinálja a processzor...''
just-in-time compiler: mert egy komplett oprendszert rendszerkönyvtárakkal lefordítani több óra, arról meg nem is beszélve, hogy sokan nem szívesen adnák ki a forrásukat. az átfordítás meg elég komplex lett már mostanság, hogy minden kódban processzor-magra van minden optimalizálva. egy átfordítással minden optimalizáció elmenne, mert szerintem egy adott ASM kódból annyira ''nemhatékony'' algoritmust tudna csak a gép csinálni, amivel már foglalkozni sem nagyon érdemes. arról meg ne is beszéljünk, hogy a kódnak van egy csomó olyan része, ami csak architektúrafüggő, azzal nem tudna mit csinálni.
meg arra is alapulhat egy kód, sőt, szerintem sokszor alapul is, hogy mondjuk 32xxxnél átfordul. vagy ilyesmi. ezt meg egy átfordító VÉGKÉPP nem veheti észre. és ez csak egy példa volt.
arról meg nem is beszélve, hogy aza z átfordítás, amit te példaként írtál egy adott architektúra két nagyon hasonló verziója között működött, most meg ha váltanánk, akkor
mennem kell, majd befejezem. hi. -
He-he...
Az a 16 IRQ elég lenne, ha olyan baromságokat elfelejtenénk, hogy kaszkádosítás, meg 13-as foglalt a koprocesszornak (már nincs is olyan iterface!).
Különben ezt már orvosolták. Vicces még az is, ha már az IRQ-król volt szó, hogy a régi DMA alrendszert is emulálják a chipset-ek, pedig már nincs is ISA busz...
Jó, jó, tudom, hogy PCI-on keresztül is lehet használni, de minek, ha a PCI eredeti megoldása jobb...
De a 16-os korlát IRQ-ra nem a prociból jön, mert az 256 vektort tud fogadni (elméletileg).
Ezek szerintem nem tartoznak szorosan az x86-hoz, lehetne más chipset-eket is gyártani. -
De nem!
Mivel régen nem volt annyira menő az órajel emelése, ill. nehézségekbe is ütközött, így más utat kellett találni a teljesítmény növeléséhez. Köztudott volt, hogy a CISC processzorokat csak assemblyben lehetett jól kihasználni, a fordítók főként csak az egyszerűbb utasításokat használták. Nagyon nincs igazad abban, hogy a fordítók által generált kód hatékonyságával nem volt probléma. Bizony az akkori fordítók sokkal ''butábbak'' voltak a mostaniakhoz képest (mert sokkal kisebb erőforrások álltak rendelkezésre). Persze létezhettek tuti fordítók is, de széles körben nem volt lehetőség olyat használni. Nézz meg egy 16-bites x86 kódot akármelyik fordítóval, még egy tapasztalatlan is tud rajta optimalizálni.
Tehát főként azért választották azt az utat, hogy kevés primitív utasítás, mert jobban lehetett rá fordítani és még gyorsabb is volt egy-egy utasítás végrehajtása az egyszerűbb (ill. hiányzó) dekóderrel. A sok regiszter pedig a memóriahozzáférések számának csökkentésére került be.
A kezdeti RISC procik órajele tudomásom szerint nem volt sokkal több CISC társaikénál, de javítsatok ki, ha tévednék.
Egyébként az órajel növelés azért sem volt hatásos, mert a lassú memóriák úgysem tudták kiszolgálni. Nem volt olyan sok hely a cache-nek, mint manapság. Már pár kilobyte is igen soknak számított.
Megemlítenék még egy dolgot, ha nem lenne világos valakinek, hogy a 486 óta az x86-osok belseje ''RISC-es''. A 386 még mikrokódból nyomta, a 486 viszont csak a bonyolult utasításokat hajtotta végre mikrokóddal (ezért is gyorsabb sokkal). Hasonló volt a helyzet a Motorola 680x0 vonalon.
Azt nem értem, hogy miért említetted a SIMD-et, az egyszerűen jó, de nem volt hely számára régen.
Egyébként amikor a zintel kiadta az MMX doksiját, röhögtem rajta, mert enyhén szólva nevetséges volt. Más létező megoldásoknak a nyomába sem ért.
Azt is tudom, hogy a RISC-ek sem hibátlanok, de valamit valamiért. Amikor kispórolják a pipeline ürítést, az vicces tud lenni.
Ha már ennyit írtam, akkor írok még...
Azt nem értem igazából, hogy miért nem lehet a régi utasításkészletet kidobni, s az újakkal helyettesíteni just-in-time compilerrel mondjuk. Vagy a létező programot átfordítani (nem újrafordítani!). Volt ilyenje a zinteléknek a 8086-osnál, ami 8080-ról fordított. Belül úgyis ezt csinálja a processzor... -
Miracle
senior tag
most nem mindegy, hogy meg van osztva? CPUidő van elég, azaz egy ilyen kis dolog, hogy megosztott irq most már észrevehetetlen sebességkülönbséget jelent csak.
nem akarom az elavult tehnológiát védeni, de mondjuk van, ami tökéletesen működik, és csak szépségbeli problémát jelent, meg 0.00001% sebességet... ezt nem mondanám nagy hibának.
[Szerkesztve] -
Pötyi
őstag
Az x86 mindössze 16 irq-járól nem is beszélve... Rég kibővítettem volna legalább 32-re. A kíndóz a sok ezközt megosztott erőforrásokkal tudja csak kezelni...
(Jó, itt is vannak szélsőséges értékek, a Digital Alphanak 256 irq-ja van. Valahol félúton kéne valami racionális darabszámot találni.)
[Szerkesztve] -
Miracle
senior tag
''A flexibilisebb CPU felépítéssel egyszerűbb és hatékonyabb compilereket lehet írni. Nem véletlenül találták ki a RISC procikat (sok általános regiszter). Kevesebb megkötés a regisztereknél könnyebb optimalizálást tesz lehetővé.''
nem szeretnélek elkeseríteni, sem a hitedből kiábrándítani, de amikor a RISc procikat kitalálták ezek a lehető legkisebb problémát sem jelentették. akkor az elképzelhető nagyon magas órajel, és rövid végrehajtási idő volt a fontos, illetve mindenek előtt a meges legfontosabb, amely újítás mindenen túltesz: a mikrokód elhagyása. SIMD egységek akkoriban még csak a tudományos lapokban voltak elterjedve.
egyébként nem csak az X86 betegeskedik mostanság, hasonlóan komoly problémák vannak a RISC egységekkel is, csak azokat sokkal jobban koordinálva fejlesztik, az egyes architektúrák között jóval nagyobb különbségek lehetnek, és vannak is, ezért ott kevésbé feltűnő. mondjuk a problémák rejtve maradásában az is nagy szerepet játszik, hogy az átlag user csak olvas ilyen processzorokról, hogy milyen nagyon jók, a problémákkal csak a fordító-fejlesztők találkoznak.
és még egy megjegyzés: az összes életben lévő RISC processzort ki is bővítették szépen megfelelő SIMD egységekkel. -
No de valljuk be, ''vektoros'' kódot nem is lehet a hagyományos módszerekkel kifejezni. Pont ezért vannak olyan függvények, amik tulajdonképpen utasítások. Ne várjuk el a fordítótól, hogy vektorosítsa a kódunkat, azt bizony nekünk kell. Persze ennek az a hátulütője, hogy a hátulgombolós kód nem lesz valami hatékony...
Az említett hibák pedig nem hiszem, hogy csak az assemblyben nyomulókat érintenék. A kevés regiszter pl. a fordított kódoknál jobban előjön, és bizony az L1 cache-re is várni kell, míg a regiszterre nem.
Az FPU pedig azért van jól kihasználva, mert egy tipikus művelet úgyis hosszabb, ezért vele párhuzamosan mehet egy FXCH pl. Viszont igazából nincs is szükség az FXCH-ra, ha nem stack-szerű az FPU. Ez nem számológép, ahol a műveleti sorrendet ennek kell eldönteni...
A flexibilisebb CPU felépítéssel egyszerűbb és hatékonyabb compilereket lehet írni. Nem véletlenül találták ki a RISC procikat (sok általános regiszter). Kevesebb megkötés a regisztereknél könnyebb optimalizálást tesz lehetővé.
Természetesen nem állítottam egy szóval sem, hogy ezek a koloncok nélkül jóval hatékonyabb lenne az egész. Én max. 10%-os javulást tudnék elképzelni (igen nagy jóindulattal ). -
Miracle
senior tag
Azért megjegyezném, hogy SSE/SSE2(/SSE3) használata elég körülményes, mert a különböző fordítók eléggé rossz arányban használják, míg a FPU nagyon jól ki van használva.
és az általad említett hibák csak az assembly programozókat érintik, akik ... hát valljuk be, hogy a programozóknak csak egy igen vékony szeletét teszik ki.
és AMD64ben van egy halom új regiszter. -
No, akkor én is beszállok.
Azért szar a x86, mert:
1. kevés a regiszter
Ez alatt azt értem, hogy csak 7 db regisztered van. Egy normálisabb rutinnál ez baromi kevés. Továbba ebből a 7-ből csak 4 használható byte-osan is.
2. regiszterek korlátozottak
Osztani csak edx:eax-et tudod. Szorozni (normálisan) szintén csak ezekkel tudsz. Port írás/olvasás csak dx-en keresztül. Csak CL-lel tudsz shiftelni változó hosszúságút. Sztring utasítások csak előre meghatározott regiszterekkel működnek.
3. FPU gagyi
Igen sötét lehetett a megalkotó, hogy stack szerűen kell programozni. Meg kevés a 8 regiszter.
Bénaságok vegyesen
Ha 16-bites adatot használsz, akkor kapod a prefixet (nehezíti a dekódoló feladatát).
A flag-ek nem mindig logikusan állítódnak (pl. szorzás).
Az egész valós mód teljesen felesleges.
Az FPU nem tud regiszterbe írni (eredményt pl. eax-be).
A kivételkezelés is rendkívül felszínes, majdnem minden ugyanazt a vektort (GP fault) használja).
Biztos pár dolgot kifelejtettem, de ennyi is elég.
Az újítások viszont jók. Az SSE nagyon jól sikerült, az SSE2 pedig majdnem leválthatja az FPU-t (csak tudományos számításoknál nem).
Ha elhagynánk ezeket, akkor a programozók munkája egyszerűbb lenne (sokkal könnyebb lenne jó compiler-t írni, könnyebb lenne optimalizálni). -
Pötyi
őstag
Hát például itt van a szomszéd téma:
Bővebben: link
Ők például egy nagyon jó feelingü játékkal játszanak. Hogy miért? Mert JÓ!
Amúgy nagyon sokan vannak, akik egyszerűen anyagilag nem állnak úgy, hogy lecseréljenek ezer éves könyvelőprogit például, vagy csak nincs kedvük lecserélni, mert bevált és jó. Akkor miért mondja nekik azt a piac, hogy igenis cseréld le? Csak mert nem lehet olyan vasat kapni újonnan, ami elég lenne ehez?
Egy cégnél pld. POS terminálokat programoznak (Shell benzinkutakra). A pénztárgép belsejében egy szabványos PC van. Vagy bankjegykiadó automata ugyanez. Hát ide minek P4? A processzor a gépidő 99 százalékában csak malmozik! -
L3zl13
nagyúr
Én használok DOS-os progit P4/Athlon XP-n.
Nem azért mert szeretem, hanem mert nincs más.
Rengeteg ilyen könyvelő, bérszámfejtő, számlázó stb progi van.
A számlázók nagy része egyedi fejlesztés. Nincs belőle újabb változat, csak ha megírja valaki. Az meg ugye pénz, problémák az átállás alatt stb.
Miért gyorsabb a MAC ugyanazon az órajelen?
Miért gyorsabb az Athlon ugyanazon az órajelen?
Eltérő architektúra és kész.
A MAC-et nem ismerem, de ott is ugyanaz a helyzet mint az Athlon vs P4 esetében.
Az athlon azonos órajelen nagyobb teljesítményre képes, viszont cserébe nem lehet vele ugyanazt az órajelet elérni, mint a p4-gyel.
A gyártó/fejlesztő cégek pedig sokszor dönteni kényszerülnek. Magasabb órajel, de kissebb órajel arányos teljesítmény, vagy alacsonyabb max órajel, de nagyobb teljesítmény azonos órajelen. -
aga
tag
Egyszer hallottam, hogy van valami olyan nagygép, illetve rá írt szoftver, ami valahogy így fut: a gépen fut egy emulátor, amin fut egy emulátor, amin fut egy emulátor......., amin fut a program. Mindezt pedig azért csinálják, hogy 100%-os bizonyosággal tudjanak dolgozni. Mert még mindig jobb, mint egy 99%-os kompatibilitással dolgozó új szoftver.
Bár az tényleg igaz, hogy a több mint 20 éves x86-ra már ráférne egy ráncfelvarrás! -
nn687
tag
na valamivel okosabb lettem, de végülis akkor miért gyorsabb a mac ugyanakkora órajelen 2.5x?(olvastam valahol), és ki használ manapság p4esen v athlonon dosos progikat? hisz minden programnak van újabb verziója, ki használ pl ma corel 5öt v 2es photoshopot? senki, akkor meg minek a kompabilitás??
-
L3zl13
nagyúr
Aztán meg egy két program mégsem működne ezen a csodás új architektúrán, vagy csak lassú lenne mint a tetű és a cégek meg milliókat vagy milliárdokat kidobtak a fejlesztésre mert az Intel elfelejtette tájékoztatni őket arról, hogy milyen következményei lehetnek az architekturális változásoknak...
Egyébként meg lásd Itanium. Ott is nagy architekturális váltás, emulációval biztosított kompatibilitás, és szar teljesítmény magas áron, vagy a szoftvert is cserélni kell egy lépésben. És a piac nem díjazza. Csoda ha az pl az AMD nem ugrott bele rögtön a dologba, és inkább a x86-ot fejlesztette tovább? -
maniac
senior tag
A legtobb user sztem szeretne, csak ugyebar mi van ha megse veszik meg mert azt mondtak neki hogy ez nem kompatibilis visszefele. Sztem azt kellene csinalniuk hogy a usereknek nem tudtara adni hogy uj architektura, biztos megvennek a kompatibilitast pedig szoftveresen megcsinalnak. Windows XP uj valtozataban, vagy linux alatt ki mit szeret. Akkor nem lenne bukta sem szvsz.
-
-
maniac
senior tag
a sok hulye is akarta a valtozast, hiszen erzik hogy vmi nem okes, csak az intel meg a tobbi gyarto lusta ahhoz hogy bevezessen egy uj architekturat, meg rendszert, amivel emulalni tudnak a regi procikat - es igy a kompatibilitast megoldani, de a problema az hogy uj technologiat behozni veszelyes dolog mert nagyot lehet bukni - ld. intel felt a 64bites proci otthonra szant bevezetestol! Olyan mint a jatekfejlesztes vagy filmkeszites. Csak jol bevalt semara epitett jatekot/filmet mernek kiadni es megcsinalni, mert nagyot bukhatnak rajta. Es itt dollarmilliardokrol van szo
-
maniac
senior tag
Ja egyebkent meg azt is akartam irni hogy meg anno '95-ben ugyebar az NT kernel mar regesreg letezett, de az MS kitalalta a Win9X-t amit ugyebar tobbszor leakartak allitani - fejlesztes kozben, valamint volt egy kijelentes hogy nem fogjak tamogatni a win95-t - mar a fejlesztes beta szakaszaban!!! Legjobb talan az lett volna ha NT magot hasznalnak fel a win95-be es akkor talan jobb lett volna az eredmeny.
-
maniac
senior tag
Zsakutca: A visszafele kompatibilitas itt a fo problema. Az hogy szar ezer eves programokat is futtatnia kell tudni, es elavult utasitaskeszletet kell tudnia hasznalni
Meg mindig ragaszkodnak a feladatok egymasutani elvegzesehez - PIV-ben ez a HT arra valo hogy parhuzamosan is tudja elvegezni, ezzel atvagva a Neumann-elvet, de legalabb gyorsabb
Hogy miert jobb a RISC processzor? Gyorsabb, egyszerusitett utasitaskeszlettel dolgozik - a mai processzorok belso magja RISC mag, a processzor ilyen utasitasokra alakitja at a CISC utasitasokat es hajtja vegre. Ugy tudom hogy gyartasa is konnyebb, a processzormag is egyszerubb.
Es hogy akkor megis miert nem terjedt el??? Mert az Intel-nek volt egy piaci benyomasa, es megmondta hogy IBM PC-be olcso proci keruljon (8086).
Azert az elegge erdekes hogy egy Amiga 1200 meg a mai napig tok okesan mukodik mp3 lejatszashoz, divx, xvid filmekhez, dvd-hez meg mindenhez
A megfelelo utat egyebkent en szemely szerint a Transmeta Crusoe (Source betui osszekeverve ugyebar )-ban lattam, de sajna elbukta valamelyest. A belso mag nem x86-os volt, a kompatibilitast egy pre-compile biztositotta. Egyebkent a masik megoldas amiben hittem a Unix/Linux/NT kernel, amelyek ugyebar elrejtik a hardvert a program elol, es igy a hordozhatosag is megoldhato lett volna. Milyen kiraly is lenne ha valami fasza PPC-rol nyomnam a dolgot, ami nagyon gyors, de kozben minden program amit megirnak ugyanugy futna a gepemen. Atvinnem haverhoz akinek x86-osa vagy barmilyen mas procija van, es ott is ugyanugy megy, nem kell portolni stb. Sajnos ez sem alakult ki, pedig nagyon remenykedtem benne
[Szerkesztve] -
eziskamu
addikt
Talán az a probléma az x86-os vonallal, hogy még most is benne van jó pár olyan üzemmód, ami csak ahoz szükséges, hogy a 20-éves 16bites programok is fussanak, pl a valós üzuemmód, lehet hogy nem így hívják, de ebben az üzemmódban a p4-es is csak 1mb memóriát+egy pár kilobájtos területet lát. Lehet hogy ezek nélkül a koloncok nélkül hatékonyabb, gyorsabb procit lehetne csinálni. Ja és úgy alakították ki eredetileg, hogy egymás után utasításonként hajt végre programokat, és nem eleve olyan programozásra ami növelné a párhuzamosságot, talán csak mostanában a p4-esek hypertheardingje, amúgy általános most már az, hogy a mai processzorok valójában párhuzamosan több speciális gyorsan végrehajtható utasításoka t(risc) hajtanak végre egyszerre, mely utasításokat az x86-os utasítások procin belüli átkódolásával kapnak, vagyis 1 bonyolultabb x86-os utasításból csinál több kisebb risc utasítást.
Új hozzászólás Aktív témák
- A firmware okozhatja a Windows 11 augusztusi frissítésével kapcsolatos SSD-hibát
- iPhone topik
- iPad topik
- LED világítás a lakásban
- Sorozatok
- Mikrotik routerek
- Yettel topik
- Elektromos autók - motorok
- Luck Dragon: Asszociációs játék. :)
- Törvényben kötelezné az USA a hazai AI igények elsődleges kiszolgálását
- További aktív témák...
- Dell Latitude 5330 i3-1215U 6magos! - 16GB 512GB 13.3" FHD magyarbill 1 év garancia
- Bomba ár! Lenovo ThinkPad T480s - i5-8GEN I 8GB I 256GB I 14" FHD I HDMI I Cam I W11 I Gari!
- HIBÁTLAN iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA - Kártyafüggetlen, MS3276
- Asus ROG Flow Z13 WUXGA 120Hz 2in1 Touch i9-12900H 14mag 16GB 512GB Nvidia RTX 3050Ti Win11 Garancia
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest