Új hozzászólás Aktív témák
-
#24
E.Kaufmann
veterán
ergoGnomik
#23
E.Kaufmann
veterán
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#23
ergoGnomik
tag
E.Kaufmann
#20
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.
-
#22
ergoGnomik
tag
Juhaszatti
#19
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.
-
#21
ergoGnomik
tag
Cythyel
#6
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...
-
#20
E.Kaufmann
veterán
ergoGnomik
#18
E.Kaufmann
veterán
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. -
#19
Juhaszatti
addikt
ergoGnomik
#17
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.
-
#18
ergoGnomik
tag
E.Kaufmann
#8
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.
-
#17
ergoGnomik
tag
Fiery
#2
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.
-
#8
E.Kaufmann
veterán
E.Kaufmann
veterán
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.
-
#7
Kotomicuki
senior tag
Fiery
#2
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
-
#5
tasiadam
veterán
Kotomicuki
#1
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.
-
#2
Fiery
veterán
Kotomicuki
#1
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). -
#1
Kotomicuki
senior tag
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övünk itt az ötletekkel és mindet lehurrogod ![;]](http://cdn.rios.hu/dl/s/v1.gif)
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é.
Új hozzászólás Aktív témák
- Autós topik
- Amazon Fire TV stick/box
- Nintendo Switch 2
- Bluetooth hangszórók
- Házimozi belépő szinten
- Akvarisztika
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Huawei P30 Pro - teletalálat
- Most Kína tiltotta ki a nemrég exportengedélyt kapott AI gyorsítókat?
- További aktív témák...
- Xiaomi Redmi Note 13 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- iPhone 13 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3113
- Samsung Galaxy Tab S8 / 8/128GB / Kártyafüggetlen / 12 HÓ Garancia
- Felsőkategóriás merev csöves Gamer PC-Számítógép! I9 11900K / RTX 3090 24GB / 64GB DDR4 / 1TB SSD
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest