Új hozzászólás Aktív témák
-
Kisgépkezelő
senior tag
Volt azért a Zennél is elég kalandozás. Azon a Zen vágányon is az a frissen fejlesztett Infinity Fabrikettel fűtött mozdony húzta őket végig, vagy miafene.
De bérgyártóért is egészen Koreáig kalandoztak, a saját korábbi gyáraik helyett.
Hogy pont ez e az a projekt amibe az Intelnek fektetnie kell, azt nem tudom, de valamibe kéne, ha tényleg akkora a gebasz mint ahogy a sajtóhírekből látszik. -
tasiadam
veterán
Csak ha senki sem fektet energiát a portolásba, ahogy a korábban felsoroltaknál sem történt, akkor az ARM esetében sem lesz. Amióta megvan az ARM-es win, meg azon snapdragon SoC-k, nem igazán repdesnek az ARM-es CPU-k senkitől laptopba, Linux alatt meg már limitálva, de adott az ARM support. De ugye az is kiderült, hogy az ARM specifikus taskoknál jobb, mint az x86, amúgy meg nem. És ennek a szoftveres optimalizálás a hiánya.
-
Ribi
nagyúr
ARM nem x86-hoz képest élte ezt át, hanem attól kvázi külön, mobil platformon. Szerintem nem szabad összehasonlítani.
Amúgy ezt az összevonós dolgot amióta processor van nem sikerült megcsinálni, mert kvázi nem is lehet. Van sok mag, írjunk egy programot ami sok magra jó, vagy írjunk egy köztes réteget ami mágiával a nem práhuzamosítható dolgokat párhuzamosítja? Hajrá. Esetleg HW réteget csináljunk ami mágikus módon párhuzamosít. Hajrá. Vagy írjunk eleve olyan programot ami jól párhuzamosítható. Hmm.
-
hokuszpk
nagyúr
ajaj, a történelem során amelyik hwnek a kihasználásához szoftveres optimalizáció szükségeltetett, az valahogy sose lett nagy siker ; lásd Itanium, Transmeta Crusoe, Bulldozer
-
válasz
ergoGnomik #23 üzenetére
Olyan hangulatromboló vagy
Jövünk itt az ötletekkel és mindet lehurrogod
Mondjuk van egy legfeljebb 20 soros assembly kód, és le van szűkítve, hogy milyen utasítások támogatottak (ha nem támogatott utasítást tartalmaz, nem próbálja szintizni). Ez is napokba kerülne? Első körben bizonyos megszorításokkal kezdenék bevezetni, ami, ahogy fejlődik a technika, oldják felfele, meg a marketingeseknek is lesz már mit mondaniAmúgy nagyon hasonlítasz arra a kollégára, aki itt érvelt a szervnyomtatás ellen, hogyaszondja a természetes szelekció meghágása és a végén kiderült, hogy buszsoför, aki utálja a nyugger utasokat
-
ergoGnomik
tag
válasz
E.Kaufmann #20 üzenetére
És olyat hallottál már, hogy egy FPGA program szintetizáció esetenként órákig (napokig) fut? És közben 100%-ra terheli a processzort. Az szerintem nem lesz a hatékonyság záloga semmilyen szinten.
-
ergoGnomik
tag
válasz
Juhaszatti #19 üzenetére
Öööööööööö és? Ez magyaráz vagy cáfol valamit? Különösen abban a szövegkörnyezetben, hogy az AMD szükségből vagy szórakozásból épített rossz architektúrát volt eredetileg az ellentmondásom alapja.
-
ergoGnomik
tag
hiába 128bitesek voltak a lebegő pontos számítások, mivel a program nem mondta meg az FPU-nak, így az egész 265bit-es FPU dolgozott a 128b széles utasításokon
Ha a program nem mondja meg egy utasításról, hogy az 128 bites, akkor az nem utasítás. Érthetetlen, hogy mire gondolsz. Az utasítás kódja egyértelműen meghatározza, hogy milyen erőforrásokon milyen művelet fog végrehajtódni. Ha az ütemező nem volt képes két 128 bites lebegőpontos utasítást párhuzamosan ütemezni, vagy maga a lebegőpontos egység nem volt képes két független 128 bites utasítást párhuzamosan végrehajtani, az az AMD sara, nem a programoké.
Az talán igaz, hogy adott esetekben külön kódutat használva a Bulldozer család processzorain jobb többszálas lebegőpontos teljesítmény is elérhető lett volna. De ki szeretné ha a cége a piac kevesebb mint ötödéért (vagy tizedéért) fordítana optimalizálásokra pénzt és időt? Ha kapitalista lennél és a te vállalkozásodban állna elő a menedzsment ilyen költségpazarló ötletekkel, páros lábbal rúgnád ki őket.
A 265 egy szép szám, csak nem ide. Gondolom félreütöttél, de azért átolvashattad volna küldés előtt. Nem verseny ez, ha hamarabb elküldöd nem nyered meg vele az internetet...
-
válasz
ergoGnomik #18 üzenetére
Ha van pl valami ciklusmag, ami akár percekig terheli a CPU-t, akkor szerintem lenne bőven idő mind felismerni, mind konfigolni rá az FPGA-t. Igaz így max a hosszabb távú energiahatékonyságot lehetne elsőre javítasni, de mondjuk laptopban az se utolsó szempont. Más kérdés, hogy rá kellene feküdni de izibe
Esetleg valami minimális OS és szoftver támogatást hozzá, hogy ne kelljen teljesen átírni egy programot, csak lehessen jelezni a programban azokat a részeket, amit érdemes FPGA-ra átfordítani. De még így se kell az, hogy a programozó meg a fordító csináljon fából vasparipát. -
Juhaszatti
addikt
válasz
ergoGnomik #17 üzenetére
Jó azért Kellert úgy "bérelték fel", hogy ő már az Athlon 64 megalkotásánál is ott volt, és a Zen idején csak visszatért.
-
ergoGnomik
tag
válasz
E.Kaufmann #8 üzenetére
Nem véletlenül. Ez már megint utasítás ütemezés szoftverben a hardver helyett. A hibrid FPGA-CPU feldolgozást nyugodtan el lehet felejteni. Sosem (vagy legalábbis belátható időn belül biztosan nem) fogod tudni elég gyorsan és dinamikusan konfigurálni az FPGA-t. Akkor meg felesleges az erőlködés.
-
ergoGnomik
tag
eldobják a különutas kalandozásokat (pl. Bulldozer)
Gondolod az AMD-nél úgy voltak vele, hogy ugyan eléggé mélyen benne ülünk már így is a trutymóban, de azért dobunk egy használhatatlan kísérletet, hátha még mélyebbre süllyedünk? Vagy esetleg ez csak azért született, mert a rendelkezésre álló kevés pénzből és mérnöki erőforrásból ezt látták egy lehetséges előrevezető iránynak, amit ki tudtak sajtolni magukból? Természetesen rosszul látták, de addigra már elveszítettek annyi tudást és tapasztalatot, hogy nem volt aki észrevegye milyen mély lesz ez a csapda. A Zenhez meg fel kellett bérelniük Jim Kellert, maguktól nem ment volna a "csodatétel".
-
-
40641
csendes tag
Hát pedig mi sem bizonyítja jobban a kétségbeesést mint amikor olyan dolgokat is levédetnek már amiről anyám is megmondja, hogy nem lesz belőle semmi. Miért? Esetleges tulajdonosváltáskor/tőkebevonáskor/akármi az is beárazódik, hogy nem n hanem n+1 szabadalommal rendelkeznek.
-
Alaaf Pi
senior tag
Egyébként a fejelsztés kódneve watermelon volt eredetileg?
-
Itánium szagot érzek
Amúgy tetszenek az érdekes módszerek, de most felvehetnének egy-két jó programozót, meg pár matematikust, akik értelmes fordítót is készítenek hozzá, mert még a szintén nem túl jó teljesítményt biztosító nyílt forrású VLIW fordítók is jobbak voltak, mint az intel sajátjaAmúgy ez egy lépés szerintem a dinamikus hibrid FPGA-CPU alapú feldolgozás felé, ha jól értem.
-
Kotomicuki
senior tag
Persze, üzleti magasságokban, ahol igény (és minden más is adott) lehet a speciális megvalósításra, ott esetleg, de az asztali szinten...
Azonkívül ez is egy kényszerű (nem is túl sikeres) ötlet, amit a gyártástechnológiában bekövetkező gyengélkedésük tett "szükségessé" és nem a piac igényelte, mert egynemű magokkal uú lefedhettek volna számos területet:
- teljesítmény az asztalihoz/munkaállomásokhoz
- takarékos a mobilokhoz/laptopokhoz/pasziánszhoz
Ahogy azt addig is tették - meg mindenki más is teszi - , legfeljebb előbb - még időben? - kellett volna előállniuk az igazi, mélyebb okokkal......amiket azóta sem akaródzik nekik megszüntetni.
...netán időben felkeresni a TSMC-t, mint áthidaló megoldást a mindvégig csak számolatlanul a lefolyóba szórt profit kontójára.
Tehát, a felemás magosítás is beleillik abba a sémába, ami az utóbbi évtizedekben jellemzi a kékeket. Pont azóta, hogy profitorientálttá lett a hajdan a mérnöki szemlélettel csúcsra érő cég - jó, akkor sem volt minden kerek (pl. az 1kB környéki memóriakezelések kezelése, RAMBUS, x86-64, stb.), de ennyire bedőlésgyanússá se vált a cég, egy pillanatra sem.
-
Cythyel
senior tag
a Bulldozer is azért bukott meg, mert nem mentek utána a szoftveres optimalizálások, így az osztott ALU/FPU egyben működött, kvázi a 4 modul 8 mag (integer), csak 4 magosként működött játékok alatt, hiába 128bitesek voltak a lebegő pontos számítások, mivel a program nem mondta meg az FPU-nak, így az egész 265bit-es FPU dolgozott a 128b széles utasításokon és nem bontódott 2*128b szélesre az 1-1 modul FPU-ja... szal nem volt rossz a Bulldozer arch, a szoftverrel nem mentek utána a fejlesztők
-
tasiadam
veterán
válasz
Kotomicuki #1 üzenetére
Ha jól tudom, végig nem olvastam egy a magyar összefoglalót, de a royal core ez lett volna, csak az by design tudta volt ezt, míg ez inkább szoftver.
-
Fiery
veterán
válasz
Kotomicuki #1 üzenetére
Ez azért nem ilyen egyszerű. A kis magoknak pl. sokmagos szervereknél nagy hasznuk van, még ha egy asztali Raptor Lake esetében kevésbé tűnnek izgalmasnak.
De amúgy meg az ilyen kalandozásokból az jól látszik, hogy az Intel nincs még eléggé elkeseredett helyzetben. Az AMD-nek is kellett a csődközeli helyzet ahhoz, hogy feltegyék magukat a Zen vágányra, és eldobják a különutas kalandozásokat (pl. Bulldozer). -
Kotomicuki
senior tag
Jelen helyzetében pont egy ilyen, kellően bizonytalan projektre van szüksége a kékeknek, amikor ennél sokkal sikeresebb és már működőképesektől is megszabadultak az "optimalizáció" jegyében.
Ahelyett, hogy pl. az eltérő magdizájnokat kukáznák már végre, amik önmagukban nagyobb kavarodást képesek okozni, mint megoldani...Természetesen, egy jól működő, fénykorát élő kékségnek tucatszám kéne ilyen - de ennél azért "komolyabb", (kevesebb igényből is) megvalósíthatóbb - tervezetekkel rendelkeznie..., de azok az idők már (rég) elmúltak.
De ebből is látszik, hogy milyen kétségbeejtő a helyzetük és, hogy ennek ellenére semmit/semmin sem változt(att)ak...
Új hozzászólás Aktív témák
- HP ZBook Firefly 14 i7-1165G7 32GB 1000GB Nvidia Quadro T500 4GB 14" FHD 1 év garancia
- Samsung Galaxy S24 FE / 8/128GB / Kártyafüggetlen / 12Hó Garancia
- Bomba ár! Fujitsu T936 Convertible: i5-6G I 8GB I 256SSD I 13,3" FHD Touch I Cam I W10 I Gari!
- AKCIÓ! Lenovo ThinkPad X13 Gen 5 üzleti notebook - Ultra 5 135U 16GB DDR5 512GB SSD Intel Win11
- SzinteÚJ! HP Elitebook 860 G10 i7-1355U 16GB 512GB 16" FHD+ Gar.: 1 év
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest