Új hozzászólás Aktív témák
-
#131
Balala2007
tag
Bici
#96
-
#130
Balala2007
tag
Balala2007
#89
Balala2007
tag
válasz
Balala2007
#89
üzenetére
5, Joggal lehet bizni abban, hogy a teljes single es double IEEE 754-et implementaljak, az osszes INF-eivel es NaN-jaival, es kerekiteseivel, ahogy a Pentium 1 (P54C) ota szokasos, es nem hagynak ki belole ezt-azt egy kis tranzisztorsporolas miatt ("grafikanak jo lesz"). Ha valaki mar vegigjatszotta, hogy a kod teljesen pontos legyen az osszes reasszociativitassal (a + b + c != a + c + b) es egyeb nyugokkel, ez nem hatrany.
6, Bar eleg kamikazenak tunik igy az LRBni kukazasanak masnapjan ilyet irni, de akkor is: Mivel az AVX512F mar kozositett a Skylake Xeon-nal, jo esellyel innentol ez az x64 kanon resze, es nem fogjak kivagni csak mert valami uj jutott eszukbe. -
lenox
veterán
válasz
kisfurko
#128
üzenetére
De a cache nem csak egy mágikus valami, ami varázsütésre működik. A cache méretével arányos a késleltetése, ennek függvényében akár a miss/hit ratio.
Ez igy van. Tehat ha nem vigyaznak akkor gyenge lesz. Nyilvan csak akkor szennyezik be egymas sorait, ha mar nem fernek el egy magasabb szinten. Szoval nem mindegy a regiszterek/l1/l2 cache aranya. Ugyhogy kivancsian varom a VPU felepiteset.
-
"Nem vilagos szamomra, miert pont a cache-eken rugozol ennyit. Bizd ra a CPU es alaplap gyartokra, hogy hatekonyan megoldjak a cache koherencia fenntartasat, hidd el, lesznek ra otletek, eddig is voltak"
De a cache nem csak egy mágikus valami, ami varázsütésre működik. A cache méretével arányos a késleltetése, ennek függvényében akár a miss/hit ratio. Ha több szál tök más dolgokon dolgozik, akkor beszennyezik egymás cache sorait, csökken a hatékonysága. A koherencia sem a fán terem, hanem elküldik egymásnak az adataikat. Ha n processzor ugyanarra a line-ra ír, akkor van ám traffic rendesen. Persze ezt elkerülheted, de ez rögtön egy korlát.
Tisztában vagyok azzal is, hogy van cache a GPU-kban is, de azok nem full koherensek, mint az x86-é."A szamitasi savszelessegre gondolsz? Vagy melyikre?"
Nyilván a memória sávszélességre, mert vagy 20-30 éve az a szűk keresztmetszet."Szerintem valamit nagyon felreertesz. A GDDR5 a memoria savszelesseg miatt kell a dGPU-khoz, nem a kesleltetes alacsony vagy magas szintje miatt."
Te értetted félre, mert a GDDR5 sávszélessége nagy, de nagy a késleltetése, ezért alkalmatlan CPU-hoz, de a GPU-nak ez mindegy. A sávszélesség mindenkinek mindig jól jön."Oke, fejtsd ki kerlek, hogy _Neked_ miert jelent problemat 8-rol 288 szalra felugrani."
Ha teszemazt mindnek növelnie kell egyazon számlálókat, változtatni akármiket, akkor kevés szál esetén nyugodtan csinálhatsz egy read-modify-write-ot, sok szál esetében azonban mindegyik szál egy csomót fog állni emiatt.Tekintve, hogy az x86-ban előbb voltam profi, mint bármi másban (a 6502 kivételével), biztos velem lehet a probléma
Én szeretem, ha könnyen megjegyezhető a mnemonic (magamban ki lehet ejteni), ha van sok regiszter, és nem folyton a stack-re, vagy máshova kell pakolásznom értékeket, valamint, ha nem 3 utasításban lehet csak megfogalmazni azt, amit másban eggyel. -
LordX
veterán
Azért, mert a szálak közötti szinkronizáció 100+ szál felett már több időt vesz el, mint 8 szál esetében. Máshogy párhuzamosítasz, ha "kevés" szálad van, mint ha "sok", relatíve a feladatok számához, mert más ütemezési/szinkronizálási gondolkodásmód (~algoritmus) jobb eredményt.
Kevés szál esetében az egyik legjobb megoldás egy közös job pool használata, mert gyakorlatilag zéró az overheadje, és ha elég hosszú a feladat, akkor ritkán fog valaki várni arra, hogy kapjon új jobot, mert egy másik szál épp fogja a lockot (és ezt lehet vadítani több diszkrét ütemezővel, feladat típusonként, stb., amivel lehet skálázni nagyságrendileg 32-64 processzorig, ahol elkezdesz kifutsz a lehetőségekből).
200+ szál esetében ugyanezzel a kóddal több szál végez egy adott időtartam alatt, de közben egy feladat nem lett hosszabb, és ezért folyamatosan éheznek a végrehajtók. Valami más módszert kell használni, de az meg több overhead, ami meg gyengébben működik 8 szálas gépen.
És akkor még fel se merült, hogy mi van, ha a feladatok között is szinkronizálni kell, dependencia vagy közös adatstruktúra miatt.
Az említett feladatban egy gráfot kellett bejárni, és minden csomópontban jóféle mátrixműveleteket kell végezni. Egyik hardveren az volt a jó, ha párhuzamosan járom be a gráfot, másikon az, ha a mátrixokat parallelizáltam, felcserélve meg jól belassult a kód.
Szóval Ilyen esetben nem az van, hogy szar volt a régi kód, hanem igenis optimalizálva volt a régi rendszerhez.
nem nezek ki senkibol ilyen megoldast
Tényleg hülyén néz ki, de simán csinálnak ilyet: Ha van egy Xbox 360-as játékod, ami a 3 processzorból egyik AI-t számol, másik fizikát, harmadik meg grafikát, és fel se merül, hogy mást csinálj, mert ez a hardver, gyakorlatilag nullára redukáltad a context switchek számát, minden proci cache-ében folyamatosan az van, amin dolgozni kell, tiéd minden erőforrás.
Ez után átportolod XBoxOne-ra, és.. nézel okosan az 5 kihasználatlan magra, amíg nem kezded el újraírni a különböző feladatokat többszálúra. Visszarakod az X360-ra, és egyből 20%-al esett az FPS, mert megnőtt a context switchek ideje és a cache trashing... -
lenox
veterán
válasz
kisfurko
#121
üzenetére
Aham, csak a többezer szállal nincs szükség behemót cache-re, annak minden hátrányával együtt.
Igy van, nagy regiszterfile kell helyette. Nyilvan ott nincs cache koherencia problema. De ez legyen az intel baja. Ha csinalnak egy chipet, akkor engem az erdekel, hogy az mit tud, az kevesbe, hogy konnyu vagy nehez volt-e nekik megcsinalni. Meg amugy a fix meretu regiszterfile es local memory az azert szab olyan korlatokat, ami az inteles megoldasban nincs. Szoval valamit valamiert.
-
Fiery
veterán
Egyebkent ezekbol az eredmenyekbol is latszik, hogy mennyire ki van szolgaltatva az OpenCL fejleszto az OpenCL drivernek es OpenCL compilernek: oriasi teljesitmenybeli nyereseget vagy veszteseget tud jelenteni egy OpenCL driver frissites, ugyanazon a vason. Persze ilyen nagy kulonbseg fokent a CPU driverre jellemzo, de ha megnezzuk, hogy az AMD-fele CPU driver mire kepes, akkor ott azert mar elgondolkozik az ember, hogy jobban jarna, ha utananezne az AVX-nek
-
Abban én is egyetértek, hogy a CPU-ra írt dolgoknak ez egy jó platform lesz, én csak azt nem hiszem, hogy ez ringbe szállhat az nvidia és AMD megoldásaival.
Úgy is nagy az L2 cache sávszélessége, hogy két mag osztozik rajta 4-4 szállal? Cikkben nem volt ilyesmi, annyira meg nem keltette fel az érdeklődésemet, hogy utánaolvassak még. -
Fiery
veterán
válasz
kisfurko
#121
üzenetére
Nem vilagos szamomra, miert pont a cache-eken rugozol ennyit. Bizd ra a CPU es alaplap gyartokra, hogy hatekonyan megoldjak a cache koherencia fenntartasat, hidd el, lesznek ra otletek, eddig is voltak
"Aham, csak a többezer szállal nincs szükség behemót cache-re"
Ugye tudod, hogy a GPU-kban is van cache?
Nem olyan nagy, mint a CPU-kban, de 1-1,5 MByte L2 cache a dGPU-kban teljesen tipikus, es akkor me'g nem beszeltunk a mindenfele skalar, vektor meg egyeb L1 cache-ekrol.Egyebkent meg nem tok mindegy, mekkora a cache? Ha le tudjak gyartani hatekonyan, ha nem fogyaszt amiatt sokat a cucc, akkor kit zavar a cache merete? Vagy szerinted mondjuk a Kaveri attol lesz jobb iGPU-ban a Haswellnel, hogy ott nincs annyi cache a prociban?
Nem attol, hanem a GCN2-tol."Sok adatnál pedig csak a sávszélesség számít"
A szamitasi savszelessegre gondolsz? Vagy melyikre?
"Ezért is van GDDR5 a GPU-k mellett, mert a késleltetés nem olyan fontos, mint a CPU-knál."
Szerintem valamit nagyon felreertesz. A GDDR5 a memoria savszelesseg miatt kell a dGPU-khoz, nem a kesleltetes alacsony vagy magas szintje miatt.
"Gondolom a stacked RAM-ot is azért rakja rá, kerül amibe kerül, mert másként labdába se rúgna. És ha a többiek is odarakják? Akkor megint nudli lesz."
Hajra, rakjak ra masok is a GPU-ra. Kar, hogy az AMD es az nVIDIA mar evek ota csak beszelnek errol, es senki se csinalta me'g meg. Az nVIDIA legutolso tervei szerint a Maxwell utani Volta architekturanal vezeti be a stacked RAM-ot, valamikor 2016-2017 magassagaban.
"Már hogy a túróba lenne ugyanaz a szinkronizáció? Itt nem csak fork/join jellegű dolgokra kell gondolni."
Oke, fejtsd ki kerlek, hogy _Neked_ miert jelent problemat 8-rol 288 szalra felugrani.
"Amennyiben a mazochisták vannak többen, nem is fogom
"Volt egy filozofikus gondolatokat gyakran hangoztato kedves osztalytarsam, aki szerint ha a jelenleg abnormalisnak tekintett nepcsoport kerul tobbsegbe, onnantol ok lesznek a normalisok, es a mostani normalisok lesznek az abnormalisok
Szoval minden csak relativ. Egy feketeoves x86+SSE+AVX kodernek meg az ARM idegen, es azt tartja mazochistanak, aki azon a platformon kodol... -
Fiery
veterán
CPU: Core i7-4770
OS: Windows 8.1 64-bit
Driverek: minden frissA perjel elott a single-precision floating-point Julia fraktal benchmark eredmenye lathato, a perjel utan a double-precision floating-point Mandelbrot fraktal benchmark eredmenye.
Nativ x86+AVX kod: 124.4 FPS / 66.08 FPS
AMD OpenCL CPU driver (SSE2/AVX, 1348.4): 12.31 FPS / 10.93 FPS
Intel OpenCL CPU driver (3.0.1.10878): 51.92 FPS / 28.69 FPS -
"Azok azert szulettek meg, mert jobb teljesitmeny/fogyasztas mutatoval mukodtek/mukodnek, mint ha ugyanazt nativ x86-bol oldanad meg. Ki lehetne hozni 5 TFLOPS-ot x86-bol is, siman, csak mondjuk 1000 Watt lenne a CPU TDP-je, ami nem feltetlenul mukodne, nem tudnad lehuteni De ugyanugy tudná hozni azt a szamitasi kapacitast, mint a GPU-k."
Én azt hittem, ennek a játéknak az az értelme, hogy hogyan lehet olcsóbban többet kihozni a hw-ből, illetve fizikailag megvalósítható-e. Elméletben csak egymás mellé kell rakni, oszt jónapot, de valahogy össze is kell ezeket drótozni. Ha meg sok cache van, akkor ott valami igen durva busz kell, hogy tudjanak egymással csereberélni. Ez az, ami nem jött össze már az elején, és mindenki kíváncsian várja, van-e erre megoldás. Vajon a giganagy stacked RAM gyógyír-e? Ha igen, mennyivel lesz ez drágább, mint más? Stb."Azert kell a tobbezer szal a GPU-knal, mert csak igy tudjak eltuntetni a kesleltetest. Az x86-os CPU-knal ezzel nincs gond, ott mas trukkokkel oldjak meg a vegrehajto egysegek folyamatos eteteset."
Aham, csak a többezer szállal nincs szükség behemót cache-re, annak minden hátrányával együtt. Sok adatnál pedig csak a sávszélesség számít, tök mindegy, hogy mennyi egy valaminek a késleltetése. Pont ez volt a nagy ötlet az egészben! Ezért is van GDDR5 a GPU-k mellett, mert a késleltetés nem olyan fontos, mint a CPU-knál. Örülne az intel akkora sávszélességnek. Gondolom a stacked RAM-ot is azért rakja rá, kerül amibe kerül, mert másként labdába se rúgna. És ha a többiek is odarakják? Akkor megint nudli lesz."x86-on, pl. Knights Landing, nincs szukseg tobb ezer szalra. De egyebkent ha Te kodolod le az egesz szinkronizaciot, akkor hidd el, nem olyan nagy kulonbseg par szal vagy par szaz szal. Ha 1-nel tobb teljesitmeny orientalt szalad van, akkor mar szinkronizalni kell; ha pedig egyszer megcsinalod azt rendesen, onnantol mar majdnem mindegy, hogy hany szalra bovited a kodot."
Már hogy a túróba lenne ugyanaz a szinkronizáció? Itt nem csak fork/join jellegű dolgokra kell gondolni."Ez egyeni preferencia kerdese, ne vetitsd le mas fejlesztokre"
Amennyiben a mazochisták vannak többen, nem is fogom -
Fiery
veterán
Intel CPU, Intel OpenCL CPU driver volt, igen.
"Dehogynem"
Konkret peldak? Ha fizetnenek erte, hidd el, gyorsabban menne az AVX terjedese
A mostani lassu terjedes epp azt mutatja, hogy lustak a cegek, nem foglalkoznak a dologgal, van jobb dolguk. De ha fizetne erte valaki nekik, hirtelen nem lenne jobb dolguk -
Fiery
veterán
Fejtsd ki bovebben, hogy miert kellett ujrairni a kod 95%-at, mert el nem tudom kepzelni, mit csinaltal rosszul, hogy 8-rol 288-ra nem tudtad boviteni konnyen a meglevo tobbszalu kododat
Hacsak nem az volt, hogy:int thread1,thread2,thread3,thread4,thread5,thread6,thread7,thread8;
Ilyen esetben tenyleg nehez ugy 
Csak poenkodok, nem nezek ki senkibol ilyen megoldast De tenyleg erdekelne, hogy a meglevo tobbszalu kodot miert olyan nagy kaland 36-szor tobb szalra atvinni. Mert gondolom nem az AVX-512-es reszre utaltal, az me'g elegge a jovo zeneje ahhoz, hogy me'g nem foglalkoznak vele tul sokan (erdemben).
Egyebkent csinaltam epp nem reg tobbszalu OpenCL keretrendszert, szinkronizacioval, max. 16 szalra, +1 vezer threaddel. Es tudom, hogy ez nem 288 szal, de barmikor, par perc alatt at tudnam rakni 288-ra, ha epp az lenne az igeny. Csak azert 16 szal, mert ennyi OpenCL GPU device-ot tamogat a kod, nincs ennel tobbre szukseg.
-
LordX
veterán
Az AVX vs OpenCL 2x gyorsulást min mértétek? Intel processzor, Intel OpenCL CPU driver? Volt egy mérésem, amin az AMD CPU drivere gyorsabb volt, mint az Intelé, Intel processzoron, bár az nem ma volt
Nem fognak fizetni egyik szoftver cegnek sem azert, hogy nativ AVX-et hasznaljon SSE2 vagy OpenCL helyett
Dehogynem -
lenox
veterán
válasz
kisfurko
#113
üzenetére
Azert futtatnak sok szalat, mert ezzel fedik el a memory latency-t. Intelnel meg prefetch van. Nekem is ugy tunik, hogy konnyebb gpu-ra irni a parhuzamos kodot, ha mar ki van talalva az algoritmus. Viszont nem minden algoritmus illeszkedik jol ra. Egy mostani intel magra a legtobb algoritmus jol tud illeszkedni, cserebe a parhuzamos kodok nem olyan gyorsak, mint gpu-n. Elvileg az utobbin probalnak javitani, kerdes, hogy a kesleltetesre kihegyezett kodoknal ez mekkora visszalepest fog jelenteni. Illetve engem az motival, hogy xeon phit probalgassak, hogy nagyon nagy az aggregalt level2 cache bandwidth, tehat ha egy tile processinget akarna az ember eloadni, akkor arra alkalmasabb lehet, mint ugyanezt gpun megcsinalni.
-
"A nativ kod akár 2x gyorsabb tud lenni, ha nativ AVX-et hasznalsz, es nem OpenCL-t. Legalabbis a mi mereseink ezt mutattak, meghozza egy baromi egyszeru kodon, ahol az OpenCL compiler jo munkat tud vegezni a vektorizacioval."
Ez akár az intel béna fordítója miatt is lehetett.
Nézd, én nagyon szeretek assemblyben optimalizálni, de az embernek is vannak korlátai. Itt 16 lanen kell összefabrikálni a műveleteket. Lehet, hogy egy egyszerű példát kézzel könnyű optimalizálni, de megnézném, mennyi idő alatt születik meg egy fél képernyőnyi C-szerű kód, ami durván lehagyja a compilert. -
Fiery
veterán
válasz
kisfurko
#113
üzenetére
"Biztos, hogy skálázódik a magok számával?"
Ha rendesen van megirva a szoftver, ha parhuzamosithato a feladat, akkor persze. De ugyanez igaz OpenCL-re ill. CUDA-ra is: rendesen kell megirni, hogy igazan hatekony legyen, hogy lemosson barmi mast; es nem art, ha a feladat sok-sok szalra parhuzamosithato.
"nem elég több CPU odapakolása, mert akkor nem születtek volna meg az nvidia és az ATI/AMD megoldásai!"
Azok azert szulettek meg, mert jobb teljesitmeny/fogyasztas mutatoval mukodtek/mukodnek, mint ha ugyanazt nativ x86-bol oldanad meg. Ki lehetne hozni 5 TFLOPS-ot x86-bol is, siman, csak mondjuk 1000 Watt lenne a CPU TDP-je, ami nem feltetlenul mukodne, nem tudnad lehuteni
De ugyanugy tudná hozni azt a szamitasi kapacitast, mint a GPU-k."Szerinted hobbiból futtatnak többezer szálat? Vagy azért, mert így lehet csak ezt a párhuzamos teljesítményt hozni?"
Azert kell a tobbezer szal a GPU-knal, mert csak igy tudjak eltuntetni a kesleltetest. Az x86-os CPU-knal ezzel nincs gond, ott mas trukkokkel oldjak meg a vegrehajto egysegek folyamatos eteteset.
"Egészen más pár szálat szinkronizálni, mint több ezret."
x86-on, pl. Knights Landing, nincs szukseg tobb ezer szalra. De egyebkent ha Te kodolod le az egesz szinkronizaciot, akkor hidd el, nem olyan nagy kulonbseg par szal vagy par szaz szal. Ha 1-nel tobb teljesitmeny orientalt szalad van, akkor mar szinkronizalni kell; ha pedig egyszer megcsinalod azt rendesen, onnantol mar majdnem mindegy, hogy hany szalra bovited a kodot.
"Ha ez ilyen egyszerű lenne, akkor már rég lennének 16-32 magos processzoraink."
12 magos mar van, sot, 16 magos is, ez utobbit epp az AMD keszitette
Plusz, ezekbol lehet 8 db-ot is berakni egy dobozba, az mondjuk 128 mag. Es azt is meg lehet hajtani x86 koddal, minden gond nelkul."Én már jópár processzort programoztam assemblyben, és messze a legnagyobb kínszenvedés az x86 volt, ezen belül is az MMX/SSE."
Ez egyeni preferencia kerdese, ne vetitsd le mas fejlesztokre
-
Lehet, de hatékony lesz? Biztos, hogy skálázódik a magok számával? Ezért írtam, hogy nem értitek, hogy nem elég több CPU odapakolása, mert akkor nem születtek volna meg az nvidia és az ATI/AMD megoldásai! Szerinted hobbiból futtatnak többezer szálat? Vagy azért, mert így lehet csak ezt a párhuzamos teljesítményt hozni? Megjegyzem, nem csak a GPU gyártók jutottak erre a (sokezer szálú) megoldásra. Egészen más pár szálat szinkronizálni, mint több ezret. Egészen más pár processzor cache-ét koherensen tartani, mint sokét (biztos, hogy nem lineárisan nő a sávszélességigény). Ha ez ilyen egyszerű lenne, akkor már rég lennének 16-32 magos processzoraink.
Az intrinsices dologra meg csak annyit, hogy eléggé befolyásolják az emberek teljesítményét a munkakörülmények, jelen esetben, hogy mennyire könnyű megjegyezni, megtanulni, alkalmazni valamit. Én már jópár processzort programoztam assemblyben, és messze a legnagyobb kínszenvedés az x86 volt, ezen belül is az MMX/SSE. Persze, aki sose látott mást, annak ez nem zavaró, lassan beleszokik. ARM, meg Motorola 68k után nincs kedve az embernek x86-ozni. Miután láttam az Altivec/VMX-et, meg a DirectX shader assemblyjét, soha többé nem akartam látni SSE-t. Néha megfordult a fejemben, hogy titokban így próbálják kifejezni az intel mérnökei a frusztrációjukat -
lenox
veterán
Gondolom ezt inkabb ugy erted, hogy hamarabb jut el az ember opencl-ben mukodo kodig, mint avx-szel. Mar ha nem az az elso probalkozas
. Mert amugy nyilvan azonos, vegtelen mennyisegu ido alatt a nativ kodnal nem lesz gyorsabb az opencl-es. De az elso oraban mondjuk lehet, hogy az opencl verzio mar fut, kiprobalhato, az avx meg kesobb lesz kesz. Magam reszerol gyorsabban leirom, hogy a=b+c cudaban is meg opencl-ben is, mint simd-ben, mivel ott joval tobb karakter. -
Abu85
HÁZIGAZDA
Egy zseni programozónak azért nem okoz nehézséget gyorsan megtanulni egy új programnyelvet. Nekik csak úgy rááll az agyuk erre. Megvan az érzékük hozzá. Az átlag programozók pedig nem fognak egyikre sem ránézni, számukra vannak egyszerűbb alternatívák, de nem is akarnak világmegváltó kódokat írni. De átlag szinten is egyszerűbb az OpenCL, mint a vector intrinsics.
Az Intelt csak az érdekli, hogy használják a hardvert. Az, hogy miképp teszik ezt mellékes. Pontosan ezért csináltak OpenCL támogatást az új lapkákra. Ők is tudják, hogy OpenCL-lel egyszerűbb kihasználni az AVX-et, aminek gyorsabb terjedés lehet az eredménye. Ha így tetszik a világnak, akkor használják így. Nem különösebben zavarja őket, sőt.
-
Fiery
veterán
"Ha azonos időmennyiséget nézel, akkor az OpenCL-en gyorsabb kódot tudsz írni."
Ez azert nagyban fugg attol is, hogy kinek mi a meglevo tudasa. Egy fejleszto, aki SSE2-ben mar profi, es OpenCL-t me'g csak messzirol latott, sokkal hamarabb vegez a nativ AVX koddal, mint ha ugyanazt OpenCL-en akarna megoldani. Azt azert hiba lenne feltetelezni, hogy minden fejleszto ert az OpenCL-hez -- mint ahogy azt is, hogy nativ AVX-hez vagy SSE2-hoz ert.
A nativ kod akár 2x gyorsabb tud lenni, ha nativ AVX-et hasznalsz, es nem OpenCL-t. Legalabbis a mi mereseink ezt mutattak, meghozza egy baromi egyszeru kodon, ahol az OpenCL compiler jo munkat tud vegezni a vektorizacioval.
"Nem hiszem, hogy az Intelt érdekli a natív AVX."
Bocs, de ez nagyon fura kijelentes pont toled, aki ert ezekhez a dolgokhoz. Miert erdekelne az Intelt a nativ AVX kod? Ok megcsinaltak, megcsinaljak, ami a dolguk, implementaljak az AVX-et a CPU-ikban, a tobbi mar nem erdekli oket. Ha akarja valaki, akkor hasznalja, ha nem, akkor csinal amit akar. Nem fognak fizetni egyik szoftver cegnek sem azert, hogy nativ AVX-et hasznaljon SSE2 vagy OpenCL helyett
-
Abu85
HÁZIGAZDA
Ha azonos időmennyiséget nézel, akkor az OpenCL-en gyorsabb kódot tudsz írni. Mivel a fejlesztők ma nagyon időre dolgoznak, így nem hatja meg őket, hogy lényegesen több erőforrás befektetése mellett esetleg van esély rá, hogy natív kód gyorsabb lesz az OpenCL-nél.
Ma azt kell nézni, hogy van a kódra x hónapod és ennyi idő alatt miben tudod megírni gyorsabbra. Vagy van egy megcélzott teljesítmény és miben tudod azt hamarabb elérni. Ilyen igények mellett az OpenCL a jobbik alternatíva. Ha viszont az idő két keze nem szorongatja a torkodat, és kvázi mindegy, hogy mikor készül el az alkalmazás, akkor érdemes rámenni a natív kódra.Nem hiszem, hogy az Intelt érdekli a natív AVX. Ha az OpenCL használja az erőforrást, akkor az már elég.
-
"Azok tudjak igazan csak megerteni, hogy milyen hulyeseg a GPU, akik abban az idoben is jatszottak, amikor nem voltak me'g GPU-k"
Mondjuk en C64-en kezdtem, amellett a Sinclairek, illetve utana a PC-k mindent CPU-bol csinalo megoldasa tunt hulyesegnek (illetve nagyon latszott, hogy milyen komoly hendikeppet jelent ez).
-
Fiery
veterán
"Nem véletlenül állt rá az Intel az OpenCL-re."
Tobbek kozt azert alltak ra, mert plusz egy opcio a fejlesztoknek, raadasul mas platformokrol is vissza tudnak magukhoz edesgetni igy fejlesztoket
De mig masoknal az az egyetlen opcio (meg a CUDA, de az nem sokban kulonbozik az OpenCL-tol), addig az Intelnel me'g mindig ott van a nativ x86 programozas is, mint lehetoseg."Vannak nyűgjei, de a tapasztalatok azt mutatják, hogy kevesebb erőforrás befektetésével van vele gyorsabb eredmény, mint a natív kóddal."
Marmint ugye nem a nativ AVX kodot hasonlitod az OpenCL-en keresztul meghajtott AVX koddal?
Mert furcsa lenne, ha a nativ AVX kod lenne a lassabb "mert biztos nem az a jövő, hogy egy kezeden meg tudod számolni a valós AVX-es alkalmazásokat."
Az SSE is igy, docogosen indult... Me'g 3 eve sincs, hogy megjelent az elso AVX-capable vas (Sandy Bridge), es az elejen a telepitett Windowsok jelentos resze (pl. WinXP, Vista, Win7 SP0) nem is tamogatta az AVX-et. Nem mintha vedeni akarnam az AVX-et, de ido kell annak is, hogy beinduljon. Amin egyebkent az OpenCL nem segit, hiszen igy nehezebben novekszik a nativ AVX optimalizalt szoftverek szama
Megjegyzem, ha a HSA optimalizalt mainstream szoftverbol is csak 10-20 db lesz 2016-ban, akkor arra is azt fogod mondani, hogy "biztos nem ez a jovo" ? -
Abu85
HÁZIGAZDA
Ma már ki akarja már ezt kitanulni? A fejlesztőktől gyorsan kell az eredmény, mert a projektben áll a pénz és azt viszont akarják látni. Nem véletlenül állt rá az Intel az OpenCL-re. Vannak nyűgjei, de a tapasztalatok azt mutatják, hogy kevesebb erőforrás befektetésével van vele gyorsabb eredmény, mint a natív kóddal. Mivel ma ez számít, így eldőlt a dolog.
Ők is azért építik bele az AVX-et, hogy használják a fejlesztők, mert ma csak elfoglal xmillió tranyót és ennyi. Fel kell tenni a kérdést, hogy a mai pénzügyi viszonyok mellett a rendelkezésre álló erőforrást mivel egyszerűbb kihasználni, mert biztos nem az a jövő, hogy egy kezeden meg tudod számolni a valós AVX-es alkalmazásokat. -
Fiery
veterán
Az OpenCL sok esetben szerencsejatek, nagyjabol fifty-fifty eselyekkel. Azt hiszed, hogy egyszeruen lehet vele nyerni, de valojaban ha rendesen meg akarsz valamit csinalni, akkor eleg sok meloba, eleg sok tanulasba, kutatasba kerul, es me'g akkor sem garantalt a siker, hiszen a(z AMD/Intel/nVIDIA OpenCL-) compiler barmikor elgancsolhatja a kododat egy idiota compiler bug miatt. Persze ha mazlid van, ha 19-re lapot huzva kijon a 21-ed, akkor nagyot lehet vele szakitani -- bar akkor is leginkabb csak AMD vagy nVIDIA GPU-n nyersz vele sokat
Ezzel szemben a nativ x86 -- legyen szo SSE-rol, AVX-rol, XOP-rol vagy AVX-512-rol -- ezerszer konnyebben kiszamithato. Ha kitanulod a szakmat, akkor a papiron (az AMD ill. Intel optimization guide-ban) leirt dolgok ugy fognak mukodni es nem maskepp. Nem kell driver bug fixre varnod a kododdal, hogy rendesen mukodjon, es nem fog elhasalni a kod, ha jon egy uj x86 architektura. Persze mindekozben nem eleg gyors, ez a hatulutoje
-
Fiery
veterán
A fejlesztok az elejen minden ujdonsagra kopkodnek, mert nyug nekik uj dolgokat megtanulni, szetboritani a meglevo, jol mukodo szoftvereiket. Az SSE-re is pruszkoltek a nepek az elejen, aztan az SSE2 megjelenese utan par evvel meg mar eleg sok szoftverben benne volt az optimalizacio, kisebb-nagyobb sikerrel. Az AVX-nek is kell 4-5 ev, mire elterjed, es az AVX-512 se lesz igazan nepszeru (a mainstream PC vonalon) 2018-2020 elott. Mar ha egyaltalan nepszeru lesz
-
Fiery
veterán
Ha valakinek mar meglevo CUDA implementacioja van, akkor -- sok esetben -- neki is a kompatibilitas lesz az elsodleges szempont, es maradni akar a CUDA vonalon, ha egy mod van ra. Ugyanez igaz az x86-os vilagra is, meg persze majd a HSA-ra is: ha valaki elindul a HSA vonalon, csinal egy baromi jo implementaciot, egy nagyon jol mukodo HSA-optimalizalt szoftvert, akkor majd o is igyekszik a HSA-n belul maradni, hacsak nem lesz egy nagyon jo erv valami mas megoldas mellett.
Az nVIDIA szerintem sajat HSA-szeru megoldast fejleszt, nem fognak belepni a HSA Foundation-be. De ez csak az en megerzesem. Meg persze mar reg beleptek volna, ha komolyan gondolnak a dolgot
-
Abu85
HÁZIGAZDA
Erre szokta mondani az Intel, hogy van OpenCL is a világon. Annak struktúrájával jóval egyszerűbb programozni ezeket az AVX féleségeket. Az a baj, hogy a fejlesztők erre vagy azt mondják, hogy anyád, vagy kipróbálják és rájönnek, hogy az Intel nem is ajánl nekik hülyeséget. Csak aztán nem az algoritmus és a hardver kihasználása lesz a nyűg, hanem az OpenCL egyéb hülyeségei. Klasszikus csöbörből vödörbe.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
dezz
nagyúr
Ez így van, de sokszor HPC területen is már eleve GPGPU-s rendszereket kell megújítani. Ez a teslás hír pl. még 2009-es: [link]
(#100) Bici: Az AMD és az Nvidia igazából nagyon hasonló utat járnak, csak az egyik x86 alapon, a másik pedig ARM. Illetve, az AMD is kacsingat az ARM felé. Azt is valószínűsítem, hogy idővel az Nvidia is átveszi a HSA-t.
-
Fiery
veterán
Kezdjuk ott, hogy C-ben, sot Delphiben is lehet akarhany szalra optimalizalt kodot kesziteni, es megoldani a szinkronizaciot kozottuk. Nem raketatudomany, hidd el. Aztan ugye ne felejtsuk el azt sem, hogy a tobbszalu processzorok kora nem most kezdodott, hanem ugy 10 eve
Ha pedig azota egy adott szoftver mar elrugaszkodott az egyszalu korbol, es mondjuk 4 vagy 8 szalat mar kezel, akkor onnan felmenni 288 szalig ezerszer kisebb melo, mint egy egyszalu szoftvert tobbszalura optimalizalni. A HPC szegmensben pedig nem hiszem, hogy tul sok egyszalu teljesitmeny orientalt szoftver lenne mind a mai napig Az meg hogy egy intrinsicet hogy hivnak, nem igazan ertem, miert lenyeges. Ennyi erovel abba is bele lehetne kotni, ahogy a Win32 API hivasokat hivjak, azok kozott is vannak cifrak. Egy fejleszto szamara az elnevezesek teljesen irrelevansak, nem az dont el barmit is.
-
Fiery
veterán
-
Fiery
veterán
"Abban sem vagyok biztos, hogy a CUDA, OpenCL, HSA bonyolultabb és időigényesebb, mint nekiállni AVX-512-őzni és saját magunknak managelni a szálak tömegét."
Azt ne felejtsd el, hogy a HPC piacon nem ritkan egy meglevo szoftvert, meglevo Xeon/Opteron farmot kell atallitani egy gyorsabb rendszerre, ahol hamarabb vegzi el a feladatot a farm. Ha pedig van egy meglevo szoftvered, ami mondjuk mar eleve tobbszalu es SSE2-re vagy AVX-re optimalizalt, akkor mondjuk a 8 szalrol 288-ra valo atallas es az AVX-512 implementalasa nem olyan nagy melo, mint mondjuk az egeszet atvinni CUDA-ra vagy OpenCL-re, mikozben az osszes vasat is cserelned kell, hiszen a meglevo vasakon nem fut a GPGPU-s szoftvered, vagy legalabbis nincs ertelme futtatni, mert tul lassu.
Sokan azt felejtik el, hogy a x86 eddig is azert tudott olyan sikeres lenni (legyen szo AMD vagy Intel platformokrol), mert biztositja a meglevo szoftverekkel a visszamenoleges kompatibilitast. Ha pedig van egy fentebb reszletezett kesz HPC megoldasod, akkor mar a Knights Landing erkezese elott megkezdheted a felkeszulest (pl. Intel SDE-vel) a Knights Landing-re valo atallasra, kiegeszitheted a meglevo szoftvert, mikozben az tovabb futtathato gond nelkul a meglevo vasakon. Aztan ha megjon a Knights Landing, csak kicsereled a vasat a szoftver alatt es megy minden tovabb, csak gyorsabban. Ezt ilyen "egyszeruen" nem tudod megcsinalni, ha at kell vinned az x86-os szoftveredet CUDA-ra vagy OpenCL-re -- raadasul ott egyaltalan nem ilyen konnyen kiszamithato es szimulalhato a szoftvered viselkedese egy jovobeni architekturan (pl. Maxwell, GCN3, stb).
Nyilvan abban igazad van, hogy adott esetben egy Xeon Phi-s (mostani Xeon Phi vagy majd a Knights Landing) megoldas nem kinal annyi teljesitmenyt a gyakorlatban, mint mondjuk egy aktualisan legdurvabb Tesla vagy FirePro. Viszont, valahol az x86-os Xeon/Opteron szerverek es a Teslak/FirePro kozott helyezkedik el teljesitmenyben a Xeon Phi, az x86 elonyeit kinalva. Az Intel se eroltetne ezt az egesz dolgot, ha nem lenne erre kereslet. Sokszor nem feltetlenul a leggyorsabb vas az idealis, hanem a sima atallas a meglevo megoldasrol valami ujra, gyorsabbra.
Ha az x86 annyira nem szamitana a HPC piacon, ha annyira fuggetlen lenne az a piac az architekturatol, akkor az Itanium sokkal nagyobb sikert tudott volna elerni, fuggetlenul az AMD64 kesobbi megszuletesetol.
A hatszel kapcsan arra gondoltam, hogy a PC-piacon a CPU-piac 1/5-et uralo AMD probal radikalis valtozasokat bevezetni, ami nem lesz konnyu, mert a gyartok inkabb arra mennek, amerre a piac tobbseget uralo Intel megy. Ez nem az en reszrehajlasom, ez sajnos teny. Nem jo dolog ez, de ez van.
A mobil/ultramobil szegmensben pedig a Google tamogatasat kellene megszerezni, pl. RenderScript --> HSAIL compiler kereteben, de felo, hogy a Google sem akar egyuttmukodni senkivel, hanem inkabb megcsinaljak maguknak ugyanazt
-
#96
Bici
félisten
Balala2007
#89
válasz
Balala2007
#89
üzenetére
Értem, köszi!
AMD oldalon nincs véletlenül hír AVX512 támogatásról?
-
Az a baj, amit látszólag az intel se próbál megérteni, hogy itt egy teljesen más szemlélet kell, ez nem arról szól, hogy minél több magot rakunk egymás mellé. Itt baromira nem oszt, nem szoroz az, hogy x86, mert más kódra van szükség. A legtöbb x86-on, C-n felnőtt embernek fogalma sincs a többszálú programozásról (max. annyi, hogy csinálok sok szálat, akkor biztos gyors lesz). Elhiszem, hogy assemblyben, kézzel hatékonyabban meg lehet csinálni a kódot, na de elég kemény lesz majd ennyi magot rendesen szinkronizálni, kézzel, figyelve a durva fogyatékosságaira a rendszernek. Nem olcsó dolog, nem véletlenül vannak magasabb szintű nyelvek. Ha meg ehhez is valami keretrendszert kell venni, hogy ne kelljen mindenkinek ezzel szívnia, akkor ugyanott vagyunk, azaz mégsem, mert az intelnek a kisujját se kellett megmozdítania.
Aztán azt se mondhatod, hogy a csuda vpfnglgmdsdf nevű intrinsicekkel könnyebb programozni (legalább adnának értelmes neveket azoknak a nyomorult utasításoknak, de biztos ez is része az x86 érzésnek ) Vagy az intel C compilere tud párhuzamosítani? Szerintem elég durva assemblyben a 16 lane-t maszkolgatni stb.
Azt lehet tudni, hogy az AVX mittudoménhány tartalmaz-e cache-eléssel kapcsolatos utasításokat?
Ja, nyugodtan oltsatok le, ha hülyeségeket beszélek, mert sose programoztam HPC-t. -
dezz
nagyúr
Azért egy komolyabb projektnél, ahol a számítási teljesítmény a döntő, nem egészen úgy állnak hozzá, mint manapság a játékfejlesztésben. Ha éppen CUDA vagy OpenCL kell a jó eredményekhez, akkor az.
Az Intel persze arra apellál, hogy a projektvezetők beérik majd fele teljesítménnyel, csak ne kelljen túl sok újat tanulni (még pénzt is képesek erre "áldozni", lásd egyes megtámogatott distributed computing kliensek, amik még véletlenül sem futnak GPU-n, hiába kisebb így az elérhető számítási erőforrás pl. gyógyszerkutatáshoz).
Van itt a körünkben egy komoly CUDA fejlesztő: Lenox, kérdezzük meg őt... (Meg ott van a korábban említett ismerősöm is, ő sem sokat panaszkodott.)
Abban sem vagyok biztos, hogy a CUDA, OpenCL, HSA bonyolultabb és időigényesebb, mint nekiállni AVX-512-őzni és saját magunknak managelni a szálak tömegét.
Nem mondom, hogy nem tud adott esetben előnyt jelenteni az x86 alapon maradás, de nem mindenhol fő prioritás.
Nyilván, hogy ismered a HSA Foundationt. Nem is neked linkeltem, hanem csak szembe állítottam a meghatározó piaci szereplők sorának a HSA Foundationban aktív részvételét a hiányzó hátszélről tett kijelentéssel. Persze, lassan őrölnek ezek a malmok, de sosem állnak le. (És felmerül, ki is folytat itt szélmalomharcot, az AMD, vagy éppen az Intel...?)
Egyszerűen csak megállapítottam, hogy eléggé az Intel szemszögéből figyeled a dolgokat. Szerintem ez sem rosszabb, mint amikor a HSA-ról folytatott eszmecsere közben kedélyesen leamdfanoztál néhányunkat... (Mert szerintünk nem egy kis semmiség a HSA, amit az Intel fél kézzel lenyom egy 2 nap alatt implementált koppintással.)
Na ja, mert a nagy GPU-kból is APU lesz addigra.
-
Sir Ny
senior tag
"Akár hogy is nézem, elég komoly elfogultságot vélek felfedezni a szavaidban"
Mar megint jossz a szemelyeskedessel. Nem tudsz leszokni errol? Olyan rossz szokasod, mint masnal a drog. Ne haragudj, de nem fogok lesullyedni a szintedre, inkabb hagyjuk ezt a vonulatot, es maradjunk szakmaiak, ha nem problema.
Az a mondat, akárhogy is nézem, a szavaidra vonatkozott, és nem rád.
-
Fiery
veterán
"Kérdés, hogy a komolyabb projektekben nekik van-e meghatorozó szerepe vagy a tehetségesebb és nagyobb tudású kollégáiknak."
Sokszor nem a tehetseg meg a tudas a donto, hanem a fejlesztesre szant eroforrasok es fokent az ido szukossege. Az x86-ot (legyen szo pl. C-rol, assemblyrol) pedig sok fejleszto ismeri mar most is, mig az OpenCL-be, CUDA-ba me'g sokan bele sem kostoltak -- a HSA pedig a jovo zeneje, es az is fokent OpenCL alapon lesz meghajtva.
"A CUDA-s fejlesztéseket nem nevezném bénázásnak"
Kerdezz egy komoly CUDA fejlesztot, mennyi workarounddal, fejvakarassal, kinlodassal jar az, hogy CUDA-n keresztul meghajts egy Teslat mondjuk. Nyilvan sok minden megoldhato, csak -- ahogy Balala is irta -- fejlesztokent sokszor ki vagy szolgaltatva a bugos drivereknek, bugos compilereknek, API overheadeknek es tarsaiknak. Ha mindezeket bevallalod, nyilvan az OpenCL-lel es a CUDA-val is szep eredmenyeket lehet elerni, mint ahogy majd a HSA-val is, csak epp kerdes, hogy ki fog ezekkel molyolni a profiknal (HPC), amikor ugyanazt egyszerubben, direkt programozassal is el fogjak tudni erni. Hidd el, az sem veletlen, hogy sok HPC feladatra me'g mindig nem hasznalnak Teslat, CUDA-t vagy ugy altalaban GPGPU-s megoldast, hanem inkabb megoldjak brute force alapon, x86-os Xeon (vagy epp Opteron) farmokkal ugyanazt a feladatot.
"Az elkészülés hamarosan meg lesz és szerintem a hátszél is megvan"
Koszi, de ismerem a HSA Foundation weblapjat es a tagjait is
A hatszelhez viszont konkret termekek (vas) kellenek, PC-n is (januarban jon a Kaveri, tudom, csak tudjanak eleget gyartani belole), mas piacokon is. Vas nelkul a legtobb fejleszto nem foglalkozik a HSA-val, ha pedig a PC-piac hanyatlasat nezzuk, akkor a mobil es fokent az ultramobil piac me'g fontosabb lenne, de oda me'g be se jelentettek semmit (tudom-tudom, lesz mobil Kaveri, de me'g mindig csak 1 konkret vasrol beszelunk), se szoftveres, se hardveres vonalon -- hacsak le nem maradtam valamirol "Akár hogy is nézem, elég komoly elfogultságot vélek felfedezni a szavaidban"
Mar megint jossz a szemelyeskedessel. Nem tudsz leszokni errol? Olyan rossz szokasod, mint masnal a drog. Ne haragudj, de nem fogok lesullyedni a szintedre, inkabb hagyjuk ezt a vonulatot, es maradjunk szakmaiak, ha nem problema.
"FLOPS-ban komoly lemaradása lesz a Knights Landingnak a AMD-s (és nvidiás) dGPU-kkal szemben"
1-2 evig lesz igy, mert utana mar nem lesz dGPU...
-
#89
Balala2007
tag
Bici
#84
Balala2007
tag
mi az, ami versenyképessé teszi ezt a processzort, az AMD/nV megoldásaival szemben?
Nekem ezek tetszenek:
1, Ekkora teljesitmeny eleresehez nem kell semmilyen plusz SW reteg/driver, nem kell OpenCL/CUDA/HSA/Mantle/stb., nem kell varni a kovetkezo driver verziora, amiben talan javitanak ezt vagy azt. Nincs AVX512 driver, ahogy nincs AVX vagy SSE se. Ha egyszer a kernel fel van keszitve a bovitett context switch-re, (amiota van korrekt CPUID level 0000000D, ez nem szabad gondot okozzon) akkor onnantol csak rajtad mulik;
2, Ugyanugy uralhatod a vasat, mint minden mas CPU eseteben, es nem vagy kiszolgaltatva mindenfele jottment API bugjainak es egyeb nyugjeinek;
3, Nincs para, hogy akkor most kozos vagy kulon a cimtartomany, mert a kerdes fel sem merul;
4, Az ingyenes Intel SDE-vel mar most lehet az AVX512 kodok helyesseget tesztelni. -
dezz
nagyúr
"Nezzuk a masik oldalrol a dolgot: az Intel meg akarja szuntetni a GPU koprocesszor jelleget, es inkabb a CPU-val akarja megoldani ugyanazokat a feladatokat, a jol megszokott "langyos pocsolya" x86 keretein belul."
Naná és már mióta, hiszen ők az x86 piaci befolyásának fenntartásában érdekeltek.
"Ennek hidd el, sokkal tobben orulnek"
Na igen, mint tudjuk, a kóderek többsége középszer (és lusta). Kérdés, hogy a komolyabb projektekben nekik van-e meghatorozó szerepe vagy a tehetségesebb és nagyobb tudású kollégáiknak.
"mint annak a benazasnak, ami a GPGPU piacot mind a mai napig jellemzi."
A CUDA-s fejlesztéseket nem nevezném bénázásnak. A PC-s mainsteam az, ahol nehezebben veti meg a lábát a dolog, ezen viszont a HSA könnyen változtathat.
"Amin -- adott esetben -- a HSA tudna valtoztatni mar jovore, csak annak elobb el kene keszulnie, es jelentos iparagi hatszelet kellene kapnia."
Az elkészülés hamarosan meg lesz és szerintem a hátszél is megvan: [link]
Akár hogy is nézem, elég komoly elfogultságot vélek felfedezni a szavaidban...
(#87) Bici: Ez így elég erős túlzás, ne hidd el... A dGPU-k HSA nélkül is "meg vannak" és - mint azt még Fiery is elismeri (ennyire nyilvánvaló tényt nehéz is lenne tagadni) - FLOPS-ban komoly lemaradása lesz a Knights Landingnak a AMD-s (és nvidiás) dGPU-kkal szemben.
-
Fiery
veterán
Jelen allas szerint a Knights Landing jobb (elmeleti) teljesitmeny/fogyasztas mutatoval rendelkezik, mint barmi mas a HPC piacon. 200 Wattbol me'g senki sem hozott ki 6 / 3 TFLOPS-ot (SP / DP). Teny, hogy mire a Knights Landing megjelenik, addigra velhetoen lesz egy csomo mas megoldas is, ami ugyanezt tudni fogja. A konnyebb programozas mindenkepp a Knights Landing mellett szol, de ha addigra a HSA is elterjed, akkor mar nem feltetlenul lesz ilyen egyertelmu a helyzet. Plusz, jatekra egyaltalan nem biztos, hogy barmilyen szinten is mukodni fog a MIC -- ez majd a Skylake-nel talan kiderul.
-
Köszi!
Akkor az eredeti kérdésemhez visszatérve: Ha eltekintünk az intel piaci befolyásától, akkor mi az, ami versenyképessé teszi ezt a processzort, az AMD/nV megoldásaival szemben? Azok addigra feltehetően jóval nagyobb elméleti számítási teljesítmény/fogyasztás aránnyal rendelkeznek majd.
Könnyebb programozás? Jobb feljesztő eszközök? Kevesebb olyan eset lesz, ahol beesik az intel megoldásának a teljesítménye? -
Fiery
veterán
"Bőven? Amikor a raszterizálthoz is kevés tud lenni? Főleg 4K-ban"
Melyik jatekhoz keves a Hawaii XT full HD-ban? (full HD-rol volt szo) Ami, marmint a Hawaii XT egyebkent nincs is egeszen 6 TFLOPS, raadasul nincs near memory-ja sem, nem hogy 16 GB-nyi on-board memoriaja
Persze mire a Knights Landing megjelenik, addigra a 6 TFLOPS mar nem is lesz nagy szam a dGPU-k kozt, legfeljebb a socketelt megoldasok kozt lehet eros. -
lenox
veterán
Az lehet, hogy az x86 specifikus terület 2% alatt van, de vajon mekkora területtöbletet jelent, hogy itt CPU magok vannak?
Nem tudom, de igazabol amiatt lenne ez erdekes, hogy hany feldolgozo kerul egy magba, es itt egy modulba 64 lesz, es lesz 36 modul, itt latok analogiat egy gpuval. Persze nyilvan nagyobb lesz egy modul, mint egy CU.
-
dezz
nagyúr
Hát, ez nem lesz semmi. De hogy pontosan mi lesz, azt majd meglátjuk.
(#56) Fiery: "A ray-tracinget be lehet vetni hagyomanyos, raszterizalt grafikaval egyutt is, a latvany egyes elemeit ray-trace-elve. Ilyen esetben eleg boven a megcelzott 6 TFLOPS."
Bőven? Amikor a raszterizálthoz is kevés tud lenni? Főleg 4K-ban.
"Talan 720p full real-time ray-tracing-re is eleg lehet"
Ray-tracing és ray-tracing között igen nagy különbség tud lenni. Egy kezdetleges szinthez bizonyára elég lesz, de az látványra kevés manapság.
"A kepminoseg "butitasa" egyebkent kicsit maskepp mukodik a ray-tracing-nel, ott szemcsesedik a kep, ha durvabbra veszed a letapogatast"
Amire gondolsz, az a backwards ray-tracing (path-tracingnek is hívják). A hagyományosnál a pixelek irányából követik visszafelé a sugarakat (de mivel ez volt az eredeti algoritmus, a lámpától követés a backwards
). Így minden pixelre jut egy. Amit itt butítani lehet, az a rekurziós mélység tükröződésnél/fénytörésnél, árnyékok jósága, különféle élethűséget növelő hatások, stb.A LuxRender féle backwards ray-tracingnél eleve nagyon sok sugarat kell indítani, hogy valamirevaló képet kapjunk a végén - cserébe igen élethű tud lenni. 6 TFLOPS-tól nem nagyon hatódik meg.
(#60): Végső soron az fogja eldönteni a kérdést, melyik megoldás lesz a hatékonyabb. Nem pedig az, hogy melyik a kényelmesebb, vagy simán csak szokványosabb.
(#70): Pedig az AMD-s Close to Metal (CTM) pont ezt tette lehetővé. Egy ismerősöm pedig Nvidiára kódolt szintén shader ASM-ben még úgy 6 éve.
(#67) lenox: Az lehet, hogy az x86 specifikus terület 2% alatt van, de vajon mekkora területtöbletet jelent, hogy itt CPU magok vannak?
-
De ezt okkal nem teszik mások, mert ha nincs rá szükség, akkor minek korlátokat emelni.
Az x86 kompatibilitás miatt viszont muszáj ez, különben nem futnak a régi programok. Ha nem futnak a régi programok, akkor minek ragaszkodni ehhez az, elnézést, de halom trágyához? Alkalmatlan az alatta levő hardver leképezésére, se nem programozó, se nem compiler barát. -
#75
Balala2007
tag
LordX
#40
Balala2007
tag
viszont ekkor a mai Xeon Phi-vel lehetetlen
Elvileg nem lehetetlen, az LRBni MVEX-e, es az AVX512 EVEX-e komplementerek, igy garantaltan nem akadnak ossze.
Mas kerdes, hogy gyakorlatilag mit implementalnak, a korabban emlitett c't cikk szerint az LRBni kihal, ugyhogy a Tianhe-re meg a tobbi vaskereskedesre fejlesztett cuccok mennek a levesbe. Azt sajnalom, hogy az LRBni nem minden otlete megy tovabb az AVX512-be, pl. a VPADCD egesz erdekes lenne.
-
Fiery
veterán
-
Nem tudom, mennyi nem x86 processzort láttatok, de ha jól emlékszem pl. a PowerPC nem biztosítja a cache koherenciát implicite, mint az x86. Az nem természetes, hogy ha te kiírsz egy értéket a RAM-ba, akkor az az is lesz, valamint abban a sorrendben íródik ki, ahogy te utasítottad. Ezt külön kérni kell. Az x86-on ez a régi cache nélküli verziókkal való kompatibilitás miatt szükséges volt, ezt nyögi most, mert ha kéred, ha nem, a cache mindig koherens, ez pedig többlet sávszélességet igényel. Nem tudom, az AVX-nél van-e ilyen irányú módosítás (egy jó ideje nem érdekel az x86), de régen nem volt ilyen feature. Persze, hogy ez teljesítményben mit jelent, azt nem tudom, de azt olvastam, hogy a Larrabee-nél erre panaszkodtak, valamint most is meg volt említve, hogy a szálaknak nem árt beférni a cache-ükbe.
-
Én már a C64-es időkben is játszottam, de mégis nagyon szeretem a koprocesszorokat. Ez szimplán filozófia kérdése. Nekem jobban tetszett, hogy ugyan kicsit gyengébb volt a 6502, mint a Z80, de mégis köröket vertek a játékok C64-en a Spectrumra a spéci chipek (VIC, SID) miatt. Ugyanez megvolt az Amigával is. Volt GUS-om, és ugyan a Voodoo vonatra nem ültem fel (anyagi okok miatt), de később a Rivára már igen
Nekem egy nagy trauma volt először PC-zni, ahol még egy nyamvadt képernyőidőzítést se tudtál csinálni, max. pollozni tudtad, hogy van-e visszafutás. Semmi hw, ami helyetted megcsinált volna bármit is, mindent neked kellett leprogramozni. Manapság, persze van mindenféle API, de az intel nem arról híres, hogy bármilyen API-t írjon, tehát, ha rajtuk múlik, megint dolgozhatnál éjjel-nappal. Ami mindenre jó, az semmire se jó igazán. A fix hw mindig is kevesebb energiát igényelt, szóval én nem hiszek ebben a minden CPU dologban (akkor az intelnek se lenne GPU-ja a processzoraiban, hanem csak egy framebuffert olvasna, mint a VGA kártya).
Az x86-os langyos pocsolyával meg ugyanaz a bajom, mint VaniliásRönknek, vagyis hogy semmi előnye, viszont gúzsba köt mindenkit, mert nem szabadon licenszelhető (és emellé még undorító az egész utasításkészlet és az architektúra ).Szerk: egyébként elérhető a VLIW és a GCN leírása az AMD oldalán. A Perf Studio, vagy mi volt a neve, disassemblálta a shadereidet. Azt persze nem tudom, hogy valamivel közvetlenül assemblyben tudnál-e kódolni rá, én csak grafikáztam.
-
#71
Fiery
veterán
VaniliásRönk
#68
Fiery
veterán
válasz
VaniliásRönk
#68
üzenetére
No offense, de szerintem valamit nagyon felreertettel
A cache koherencia egyaltalan nem architektura fuggo, es a cache merete sem a koherencia miatt erdekes vagy lenyeges. Plusz, a stacked RAM-ot nem az Intel talalta fel vagy talalta ki, hogy be kellene vetni, hanem az AMD es az nVIDIA utitervein mar hosszu evek ota ott van, csak nem tudjak vagy nem akarjak bevetni egyelore. Az nVIDIA 2016 kornyekere, a Volta architekturahoz igeri jelenleg a stacked RAM-ot. -
Fiery
veterán
Kizart, hogy az osszes GPU-n futo szamitasi reszt assemblyben írná barki is. De ha me'g igy is lenne, mert mondjuk egyedileg az AMD kiadta nekik monduk a GCN assembleret, akkor sem igaz ez nagy altalanossagban a GPU-kra. Eleve nem publikus az architektura, nem publikus az ISA, semmi sem publikus. De me'g ha meg is hajtod kvazi direktben, assemblyben, a thread kezeles es az utemezes akkor sem mukodik ugy, mint egy CPU eseteben, es a memoria eleres, cache koherencia sem ugy mukodik, ahogy azt a fejlesztok az x86-on megszoktak.
-
#69
lenox
veterán
VaniliásRönk
#68
lenox
veterán
válasz
VaniliásRönk
#68
üzenetére
Ha nyug van a cache koherenciaval, akkor nagyobb cache kell? Ha nem x86 lenne, hanem arm, akkor nem lenne nyug?
Ha a 16 gb cachekent mukodik, az miert rosszabb, mint ha ramkent? Nekem ugy tunik, hogy az csak jobb lehet.... -
#67
lenox
veterán
VaniliásRönk
#65
lenox
veterán
válasz
VaniliásRönk
#65
üzenetére
viszont x86 alapokon erőltetni alapvetően butaság
Miert erdekes, hogy x86 vagy nem x86? Az intel szerint mar a mostani xeon phiben is 2% alatt volt az x86 specifikus terulet, szoval nagy koltsege nincs, akkor miert ne lehetne akar x86 is?
A cache-es gondolatmenetet nem annyira ertem. Nyilvanvaloan el kell latni a chipet adattal, ha elol akarnak lenni teljesitmenyben, akkor jo sokkal, arra celoznak, hogy 500 GB/sec felett legyen ez a sebesseg. Ezt ugy megcsinalni, hogy el legyen vezetve az alaplapon egy csomo memoriamodulhoz az nem annyira konnyen megoldhato, szoval tok logikus, hogy kifele csak egy lassabb busz van, de emelett 12 GB-os Teslakkal kell kuzdeni, szoval 500 GB/sec-kel is elerheto kell legyen jo sok GB, igy oldottak meg. Ertem, hogy esetleg draga, de milyen megoldast tudsz, ami 16 GB-nyi nagyon gyors memoriat biztosit, illetve megfeleloen bovitheto? -
Crucio
aktív tag
"Mig egy klasszikus GPU eseteben a GPU nativ architekturaja es gepi kodja el van rejtve a fejlesztok elol, ergo me'g ha akarnak, akkor sem tudnak direktben programozni."
Abu többször is írta hogy az EA Sports ASM-ben írja a következő generációs Fifa kódját. Akkor ezt most nem értem. Az is lehet, hogy én értettem félre.
Nem kötekedni akarok -
#65
VaniliásRönk
nagyúr
Fiery
#60
VaniliásRönk
nagyúr
Nem igazán van a dolognak másik oldala. A MIC-nek általában véve biztosan vannak előnyei, ahogy hátrányai is, viszont x86 alapokon erőltetni alapvetően butaság (ha eltekintünk attól, hogy így megint ki lehetne rekeszteni az AMD kivételével minden konkurenst), ezért tartom az AMD heterogén megközelítését az x86 mellett életképesebbnek. Ez az iteráció is mutatja a 16GB cachével meg a 200W-os TDP-jével, hogy továbbra sem sikerült ezt normálisan kivitelezni, hiába a dollármilliárdok és az évek. Ezen az sem változtat, hogy 384GB RAM-ot lehet mellérakni, csak hogy ne nézzen ki olyan bután a 16GB cache.
Persze ha úgy nézünk a dologra, hogy ami az Intel alvégén kipottyan, az (a NetBurst kivételével) csak arany lehet, akkor akár előremutató megoldásnak is tekinthetjük. -
lenox
veterán
Oke, de tovabbra sem ertem, hogy ez mekkora valtozast fog hozni jovore. Szerintem minimalisat.
Az igazan nagy otletek mindig ugy szuletnek, hogy 5-10 evre elore gondolkozol.
Hat en a magam reszerol ilyen szinten nem vettem reszt a technologia alakitasan, ugyhogy hiaba gondolkozom elore. A hp workstationt tervezni hivott evente 2-3 napra, meg az nv fejlesztett par featuret (de leginkabb driver featuret), illetve az early access programokban tobb helyen benne vagyok, szoval bugokat szoktam kuldozgetni, de chip tervezesnel nem kerte meg senki a velemenyem, nem tudom sokan vannak-e a ph-n akiknek igen. Az amd prezentaciot en is meghallgattam 2006-ban, de nem volt semmit kezzel foghato, hasznalhato benne. Ugyhogy akkor clusterunk volt, gpu processinget fejlesztettunk, meg Altixon futottunk meg. Aztan ugye jott a g80... Ezek a kezzel foghato dolgok. Ma ott tartunk, hogy egyelore egy ket processzoros gepet se tudna a hsa, es amugy ha egy szokasos ws-t nezunk, akkor 2x12 intel maggal es mondjuk 4 eros gpu-val kellene versenyben lennie. Mar ugy ertem, hogy a Knights Landing kapcsan nem gondolkozom tabletben meg telefonban, csak olyanban, amihez kell kakao.
-
And01
aktív tag
Mondjuk nekem elsőre az jön le:
Vélhetően masszív gyártási költséggel az Intel legyárt egy lapkát,
amit megjelenésekor a saját processzorai (szerverekben processzorfürtök)
is könnyen felülmúlhatnak akár alacsonyabb gyártási költséggel, és fogyasztással!
Ez így kissé harmatosnak tűnik, de még sok víz lefolyik a Dunán mire piacra kerül! -
Fiery
veterán
Kinek mi a low-end... Az AMD a mainstream desktop es mobil piacon veti be a HSA-t eloszor, es onnan mennek lefele (ultramobil cuccok, tabletek, telefonok) es felfele (szerverek) majd. A HSA mint koncepcio amugy sem AMD-only, barki mas is beszallhat. De mivel az AMD a HSA zaszlovivoje, es varhatoan ok keszulnek el eloszor a PC-s HSA implementacioval, igy rajtuk a vilag szeme
"Ha nem a parton van az ember, hanem a suruben, akkor nem az az erdekes, hogy 5-10 ev mulva mivel lehet majd toppon lenni"
Az igazan nagy otletek mindig ugy szuletnek, hogy 5-10 evre elore gondolkozol. A HSA otlete sem most jott, hanem 2006 tajekan, amikor felvasarolta az AMD az ATI-t. Ugyanigy, a MIC is kb. akorul fogant meg, csak kicsit sanyaru sorsa volt eleddig
A paradigma valtasokhoz idonek kell eltelnie, utol kell hogy erje a technologia az otletelest. Addig meg van viszonylag hasznalhato GPU-ja az Intelnek, es viszonylag hasznalhato x86 CPU-ja az AMD-nek -
lenox
veterán
Hogyan tudna a HSA valtoztatni barmin jovore? Ugy ertem a low endben lehet, hogy lesz valami, de az tul sokat nem er, max koncepciojat tekintve.
Azok tudjak igazan csak megerteni, hogy milyen hulyeseg a GPU, akik abban az idoben is jatszottak, amikor nem voltak me'g GPU-k.
Ezzel nem ertek egyet. En jatszottam mar a gpuk elott, irtam elobb az mmx majd kesobb az sse kodokat, es nyomtam le a vetelytarsakat. Ha nem a parton van az ember, hanem a suruben, akkor nem az az erdekes, hogy 5-10 ev mulva mivel lehet majd toppon lenni, hanem hogy a kovetkezo iteracioban mit mutatsz a usereknek, amivel jobb vagy az ellenfeleknel. Ha 2-3 ev utan uj hw platformra kell valtani, az nem zavar senkit, keszulni kell ra, de attol meg az aktualisat nem lehet kihagyni.
-
#60
Fiery
veterán
VaniliásRönk
#58
Fiery
veterán
válasz
VaniliásRönk
#58
üzenetére
Nezzuk a masik oldalrol a dolgot: az Intel meg akarja szuntetni a GPU koprocesszor jelleget, es inkabb a CPU-val akarja megoldani ugyanazokat a feladatokat, a jol megszokott "langyos pocsolya" x86 keretein belul. Ennek hidd el, sokkal tobben orulnek, mint annak a benazasnak, ami a GPGPU piacot mind a mai napig jellemzi. Amin -- adott esetben -- a HSA tudna valtoztatni mar jovore, csak annak elobb el kene keszulnie, es jelentos iparagi hatszelet kellene kapnia.
Azok tudjak igazan csak megerteni, hogy milyen hulyeseg a GPU, akik abban az idoben is jatszottak, amikor nem voltak me'g GPU-k. Amikor a CPU szamolt mindent, es mukodott minden ugy is. A GPU csak azert jott letre, egyfajta kenyszeru (es mellesleg, atmeneti) kompromisszumkent, egy bena koprocesszorkent (mert a GPU se mindig volt programozhato), mert a CPU segitsegevel lassabban lehetett ugyanazokat a feladatokat megoldani. De ahogy minden mas is konvergal a CPU foglalatba, ugy a GPU is eleri a vesztet, es integralodik a CPU-ba. Ez aztan lehet heterogen integracio (AMD APU), vagy homogen (Intel MIC). Az ido -- es foleg a piac -- majd eldonti, hogy melyik a jo megoldas. Ha a multbeli esemenyekbol indulunk ki, akkor azert eleg jol meg lehet tippelni, hogy melyik vonulat lesz a nyero
-
Fiery
veterán
A Xeon Phi a Teslak es FirePro-k ellen indul a HPC szegmensben, ahol letkerdes a minel jobb DP lebegopontos teljesitmeny. Ha lesz desktopon hasonlo megoldas (pl. a Skylake utan 2 generacioval), annal -- ha ugy akarja -- az Intel is korlatozhatja a DP teljesitmenyt. De szerintem nem fogja, hanem egyszeruen letiltja a nem-tul-izmos peldanyoknal (Celeron, Pentium) az AVX-512-t ugy ahogy van, es kesz.
Az megint mas kerdes, hogy ki honnan tamad: az Intel sem igy tervezte az elejen ezt a bohockodast, ez jol latszik az LRBNI dobasan is. De ha mar idaig eljutottak, most mar megprobaljak a legjobbat kihozni a cuccbol
-
-
Fiery
veterán
Ez egy erdekes kerdes. A ray-tracinget be lehet vetni hagyomanyos, raszterizalt grafikaval egyutt is, a latvany egyes elemeit ray-trace-elve. Ilyen esetben eleg boven a megcelzott 6 TFLOPS. Talan 720p full real-time ray-tracing-re is eleg lehet, de ott az is nagy kerdes, hogy mik a jatekosok elvarasai. Ha valaki peldaul a kepminoseget hajlando kicsit bealdozni a 60 FPS okan, akkor mukodhet a ray-tracing mar par ev mulva is -- de kerdeses, hogy ha a kepminoseget eleinte kicsit be kell aldozni, akkor mi ertelme van egyaltalan ray-trace-elni
A kepminoseg "butitasa" egyebkent kicsit maskepp mukodik a ray-tracing-nel, ott szemcsesedik a kep, ha durvabbra veszed a letapogatast, es ezzel lehet sok eroforrast megsporolni.A ray-tracing ellen dolgozik egyebkent az a teny, hogy a grafikai felbontas brutalisan megnott az utobbi idokben: nem olyan reg me'g orultunk volna egy 576p (DVD felbontas) real-time ray-tracingnek, manapsag meg mar a full-HD tunik minimumnak. Es mire a Knights Landing megjelenik, addigra meg mar a 4K monitorok is megfizethetoek lesznek... A sokszorosara novelt felbontast pedig nem igazan tudja a szamitasi teljesitmeny lekovetni, plane ugy, hogy eleve behoznivaloja van a PC-nek ezugyben -- hiszen a real-time ray-tracing mindig is "tul sok" volt az epp aktualis PC generacionak az epp aktualisan elvart felbontason...
-
-
Azért azt mindketten tudjuk, hogy a P4 már indulásakor elég gázos volt, csak a presztízsvesztés elkerülése miatt tolták végig, amíg nem lett más. Ez pedig a P4 előtti architektúra továbbfejlesztése volt.
Az AMD, szerintem is ezt az utat fogja bejárni, hiszen nála nem fontos (nem megy ) az x86 teljesítmény. Nekem ez szimpatikusabb, mint az intel féle irány.
Ugyan semmi tapasztalatom nincs benne, de úgy gondolom, hogy a párhuzamosítható feladatok csak egy részhalmazát fedi azon feladatok köre, amik alá elég csak még több CPU-t rakni. Pl. grafikai feladatok se ilyenek, ezen durván el is hasalt a Larrabee. Ha majd megjelenik, azért remélem lesz valaki, aki összehasonlítja az akkori nvidia processzort ezzel valami globális illuminációs dologgal. Csak abban is (szoftver) jóval előrébb van az nvidia. -
Fiery
veterán
A Knights Landing-nek meg lesz azert az a nagy elonye, hogy ha az OpenCL tamogatassal nem vagy elegedett, akkor programozhatod direktben is, mint ahogy most is teszed mondjuk egy tobbszalu x86 szoftver eseteben. Mig egy klasszikus GPU eseteben a GPU nativ architekturaja es gepi kodja el van rejtve a fejlesztok elol, ergo me'g ha akarnak, akkor sem tudnak direktben programozni.
Manapsag is letezik jo nehany tobb szalra, tobb x86-magra optimalizalt szoftver. A Knights Landing-nel "csupan" annyi a kulonbseg, hogy nem nehany szálat kell meghajtanod, hanem 288-at
De ha elrugaszkodik valaki az egyszalas megoldastol, es kiizzad magabol egy korrekt tobbszalu keretrendszert a programjahoz, onnan mar mindegy, hogy 4 vagy 288 szalat akarsz hasznalni. Es bizonyos felhasznalasi modoknal (pl. ray-tracing) kifejezetten jobban fekszik a programozoknak a tobbszalu x86, mint az OpenCL. -
Fiery
veterán
Egyszer mar megtortent az Intelnel az, hogy egy teljesitmeny orientalt, de menet kozben zsakutcanak bizonyulo architekturat (P4/NetBurst) levaltott egy alacsonyfogyasztasu, kifejezetten mobil eszkozokbe tervezett architektura (Banias/Dothan/Yonah); majd a "kicsibol" felfejlodott ismet egy teljesitmeny orientalt, de immar joval energiahatekonyabb architekturaba (Conroe --> Nehalem). Miert ne tortenhetne meg ez ujra? Raadasul, a pillanatnyi konvergencia nem zarja ki annak a lehetoseget, hogy ne inditson az Intel ismet egy uj mobil architekturat a Goldmont megjelenese utan par evvel, stb. stb.
Az en szemelyes sejtesem egyebkent az, hogy az AMD is a(z alacsonyfogyasztasu) Jaguar/Puma architekturat szánja a jovobeni teljesitmeny orientalt APU-iba is, es hosszutavon dobni fogja a Bulldozer architekturat. De ez tenyleg csak sejtes, semmi konkretum nem tamasztja ala -- egyelore
-
#48
kisfurko
senior tag
Meteorhead
#44
válasz
Meteorhead
#44
üzenetére
Valószínűleg ez is csak tessék-lássék OpenCL támogatást fog kapni, hogy meg lehessen mutatni, hogy ezt is tudja. Ez nem az a cég, ami máshoz idomulna, meg szoftverekkel bajlódna. Megmondják, hogy itt van az ISA, lehet programozni. Lesz sok magod, írhatod rá az x86-os kódot, a többi (szinkronizáció stb.) a te feladatod. Én, sajnos ennél többet még nem láttam tőlük.
Ez az én személyes véleményem, de ne legyen igazam! -
Olyan szépen hangzik ez a Goldmont, mint az egy Windows
Ezért vannak ilyen jól meg együtt már több, mint 30 éve
A vezetőknek biztos ez lenne a legegyszerűbb, de kétlem, hogy ugyanaz optimális egy hordozható eszközbe, mint egy teljesítményorientált gépbe. Persze, lehet csak ugyanúgy hívni, és akkor a managerek is örülnek, meg a mérnökök is -
-
#45
Fiery
veterán
Meteorhead
#44
Fiery
veterán
válasz
Meteorhead
#44
üzenetére
Nyilvan SVM-capable lesz a Knights Landing, maskepp nem sok ertelme lenne "CPU socketesiteni". Ha nem lenne SVM-re kepes, akkor ennyi erovel maradhatna PCIe gyorsitokartyan is, ott a TDP kerete is tagabb maradhatna peldaul, konnyebb lenne ott etetni
Megjegyzem, a Knights Landing eseteben nincs is igazan ertelme SVM-rol beszelni, hiszen -- az eddigi informaciok alapjan -- ez egy homogen, 72 magos "sima" x86 processzor lesz baziszeles SIMD vegrehajto egysegekkel. Fogj egy mostani Bay Trail tablet procit, vedd vissza kicsit az orajelet, szorozd fel 18-cal (4 helyett 72 db x86 mag), es hajitsd ki belole az elavult GPU-t. Ez lesz a Knights Landing elvileg. Ugyanugy elerheti majd mind a 72 mag a teljes, max. 384 GB-nyi rendszermemoriat, mint akarmelyik mostani x86 CPU.
-
#44
Meteorhead
aktív tag
Meteorhead
aktív tag
Én még arra lennék kíváncsi, hogy például OpenCL alatt a 16GB on-die memória lesz a __global és a maradék meg marad host memory (esetleg SVM-mel el lehet érni, ha kell az egész), vagy csak lesz egy veszett nagy L4 cache, amit nem igazán lehet kihasználni, mert ez annyira más a többi cucchoz képest, hogy erre senki nem fog algoritmust tervezni...
(Én az előbbi verziónak jobban örülnék)
-
Fiery
veterán
A mai Xeon Phivel (Knights Corner) nem lesz binarisan kompatibilis a Knights Landing. De senki, me'g az Intel sem igerte, hogy megtartjak az LRBNI-t. Az AVX-512 tulajdonkeppen az LRBNI-t valtja fel, es egyuttal kozos platformra hozza a mostani SSE-s es AVX2-es architekturakat (Silvermont, Haswell) es a Xeon Phi-t. Idovel majd kikopik a Haswell is, es velhetoen a Goldmont-nal egyetlen architektura marad csupan, a telefonoktol az asztali es szerver procikon at a Xeon Phi-ig.
-
A sávszélesség kiherélésére gondoltam, ahogy már megjegyezte más is. Szerintem baromi drága lesz az az on-chip memória, akkor már minek kell kiherélni a kártyát?
A c++-szal meg nem lesz valami fényes a teljesítmény. Ha meg már bekerülnek az intrinsicek, akkor már nem c++, nem is hordozható, újra kell írni.
Egyébként, félreértés ne essék, jó lenne minden processzorhoz ilyen mennyiségű on-chip memória, csak nem mindegy, mennyiért árulják. Vajon ad-e ez akkora előnyt, hogy kompenzálja a magas árat? -
#40
LordX
veterán
Balala2007
#31
LordX
veterán
válasz
Balala2007
#31
üzenetére
A kérdés, hogy mivel kompatibilis binárisan. Nekem úgy tűnik, standard x86-al igen, mint az általad mutatott kép is állítja (NHM = Nehalem, SNB = Sandy Bridge, HSW = Haswell...), viszont ekkor a mai Xeon Phi-vel lehetetlen, mert az viszont nem az.
-
#37
lenox
veterán
Balala2007
#36
lenox
veterán
válasz
Balala2007
#36
üzenetére
Hat csak azt, hogy ezek mind extensionok, ezektol meg vagy binarisan kompatibilis lesz, vagy nem. De ha az lesz, az csak jo.
-
#36
Balala2007
tag
lenox
#34
Balala2007
tag
Nem ertem, hogy ezen mit nem latni, de teszek egy kiserletet:
NHM: (Nehalem) SSE
SNB: (Sandy Bridge) SSE + AVX
HSW: (Haswell) SSE + AVX + AVX2
KNL: (Knights Landing) SSE + AVX + AVX2 + AVX512F + AVX512CD + AVX512ER + AVX512PF
Future Xeon: (Skylake Xeon) SSE + AVX + AVX2 + AVX512F + AVX512CDKompatiblis = felcserelheto. KNL-nel nem kell semmit ujraforditani a *mukodeshez*. A max. teljesitmenyhez kell az AVX512, de ezzel nyavalyaval elunk evtizedek ota, aktualisan az AVX2 kodok hianya miatt nem tunik a
HSW nagy dobasak a *Bridge-ek utan.A Knights Ferryben meg a Knights Cornerben csak x86 + x87 + x64 + LRBni volt, de ennek ugy latszik vege.
-
#34
lenox
veterán
Balala2007
#31
lenox
veterán
válasz
Balala2007
#31
üzenetére
Ebbol nem tudom, hol latszik. Xeon Phi-nel is az a mondas, hogy kompatibilis, de nem binarisan, ujra kell forditani a kodot hozza.
-
stratova
veterán
Szerintem egy ilyen lapkánál - Knights Landing - nem az egy szálas teljesítmény a kérdés, de lehet hogy tévedek. Az világos hogy a Core lényegesen jobb egy szálon, ezt nem vitatta senki.
Z3770 <7.5 W TDP 4/4
i3-4010U 15 W TDP 2/4Arra vonatkozóan, hogy Anand tesztjében melyik rendszer mennyit evett kizárólag CPU terhelésnél, nem láttam adatot. Core i3-nál közrejátszhat az erősebb IGP is.
-
bunevo
tag
A "Knights Landing", mint termék szerintem nem fogja megrengetni a 2015-2016-os processzorpiacot, viszont mint kézzelfoghatóan működő koncepció, jelentős hatása lehet majd a 2020-as processzorokra bármely szegmensben, és ezáltal az intel akkori pozíciójára.
8/16 GB memória az IC-n! legjobb! legyen eccer ugyanez TeraByte-tal, terminátor bácsi örülni fog
Intel +1, pedig már azt hittem nincs válaszuk a Kaveri által mutatott egészen más de szintén szükséges irányra.
Nincs állóvíz szerencsére.
-
#26
VaniliásRönk
nagyúr
VaniliásRönk
nagyúr
Ha nem megy ésszel...
-
lenox
veterán
Nekem egy kartya 16 GB-nyi 500 GB/sec sebessegu es 64 GB-nyi 38 GB/sec sebessegu memoriaval az meg nem annyira kiherelt, de lehet, hogy felreertettem valamit.
Amugy az eleg jol el tudja adni, hogy c++ lefordul ra. Szerintem az x86 mar nem annyira erdekli a usereket, meg ha jol ertem nem lesz binarisan kompatibilis. -
2015-ben majd az engineering sample-ok jönnek, szerintem, ha jól megy nekik.
Nekem csak egy kérdésem van: mégis ez mennyibe fog kerülni? 8/16 GB memória az IC-n?! Talán az nvidia és az AMD is hozni tudná ezt a teljesítményt 2015-ben a jelenlegi architektúra csiszolásával, nemhogy majd az újakkal. És gyanítom, hogy olcsóbban. Azt se értem, miért kell kiherélni a kártyás változatot. Ja, de, akkor nem kell a kutyának se, nem kell a kártyatervezéssel, gyártatással bajlódni A 200 W-os fogyasztás miatt, persze "sima" alaplapba be se lehet tenni, de ez is legyen másnak a baja.
De nem baj, ha most nem, majd legközelebb végre csak eladja az, hogy ez x86 Igaz, hogy ennek a hatékony kihasználásához külön programot kell rá írni, de hát ez x86, értitek... -
stratova
veterán
-
#10691584
törölt tag
Nincs mit "leboxolni" csupán nem értetted. Te azt kérdezted OTHON mire jó. Nem otthonra tervezték/szánják (meglepne, ha boltban is forgalmaznák egyáltalán; kizártnak tartom) teljesen más a felhasználási terület, a programok és jó drága is lesz. Ezekből "parkokat" építenek majd és láncba kötik.
-
#13
LordX
veterán
Meteorhead
#7
LordX
veterán
válasz
Meteorhead
#7
üzenetére
Értelmezhetetlenül lassú.
Van benne egy in-order Silvermont (azaz.. egy Saltwell?), úgyhogy kb. annyi lehet az IPC-je, mint egy első generációs Atomnak, ami 1.66 GHz-en is tetű lassú volt, ez meg 1.2 GHz (A 200W -> 100W redukció kb. kijön abból, hogy mindent feleznek benne.) És e mellé még grafikát is számoljon? Egy felezett ilyen cucc még talán a HD5100 teljesítményét se adja ki nyers erőben..
Szerintem ennek semmi keresnivalója desktopon, amíg Atom alapon rakják össze a magokat, és nem az aktuális Core alapján.
-
#06658560
törölt tag
És? Ez legjobb esetben 2015 elején megjelenik, HPC-be, ahova szánják, minimum egy év, de inkább több, mire átlagbéla gépére leérjen. Akkor miért most kell agyalni azon, miért is lesz ez jó átlagbélának?
#6 Jester01: Nem, ebbe az irányba intel hamarabb indult el mint az AMD.
#10Thrawn: akkor ne csak kíváncsi légy, pláne, hogy informatika iránt érdeklődő vagy: minden olyanra lehet használni, ami masszívan parhuzamosítható. Tömörítés, kódolás, stb.
-
#8
Balala2007
tag
Balala2007
tag
Ez az info honnan van?
két darab VPU [...], melyek a módosított Silvermont magokkal ellentétben nem out of order, hanem in order logikát használnak
1, A Silvermont csak az egesz utasitasok koreben out-of-order, a nem egesz (x87, MMX, SSEn) muveleteket szigoruan veve in-order hajtja vegre azzal a kivetellel, hogy ha az egyik pipe-ban kisebb kesleltetesu, fuggetlen muvelet van, akkor azt soron kivul vissza tudja vonni (az Intel ezt decouplednek, fuggetlenitettnek hivja a doksikban);
2, Ebben a c't cikkben egyertelmuen OoO FPU-rol van szo, es minden egyeb info pontosnak tunik benne;
3, Sztem nem illik a koncepcioba se: a kis kesleltetes erdekeben bevetik az on-package memoriat, a 4x hyperthreadinget, az utasitaskeszletet kulon bovitik scatter/gather prefetchekkel, akkor pont ez maradna ki? -
#7
Meteorhead
aktív tag
Thrawn
#3
Meteorhead
aktív tag
Peidg látod, én pont az ellenkezőjét gondoltam.
Valaki tudna mondani egy hozzávetőleges számot arról, hogy egy 95 és egy 45 wattos TDP értékbe beszorított verzió (asztali és notebook felső kategória) nagyjából mennyivel lenne lassabb soros végrehajtásban a jelenlegi megoldásoknál és mennyivel grafikában?
Ha jól értelmezem, akkor az irrgalmatlan vektor feldolgozó mennyisége miatt ennek a nyers shader kapacitása nem lenne rossz, egyedül a fix funkciós dolgok hiányoznak, de azokat jól-rosszul lehet emulálni. (Persze itt is minden a jól-rosszul pontos természetén múlik) Ugye erről beszélt az Intel a vékony szoftveres illesztőprogrammak kapcsolatban, ami csak egy nagyon vékony driverként funkcionál és pont az ilyen dolgok vannak implementálva benne.
Ha a 72 mag helyett lenne 36 magos variáns asztali, és mondjuk 18 magos variáns notiba, ahol a nyers teljesítmény mondjuk csak fele és negyede lenne, akkor már az IGP szerepét is simán be tudná tölteni, de rohadtul bírnám, ha notebookon a 18 mag 72 szálán tudnám fordítani a Qt-t, tekintve hogy a fordítás mindigis IO intenzív feladat volt inkább, mintsem munkás.
Szóval én nagyon bírnám ha az Intel Mesa-ba tolt rengeteg munkája ott térülne meg, hogy a Knights Landinghez ugyanúgy megcisnálják a nyílt forrású OpenGL illesztőt (ami jelenleg is 4.2-nél tart már Haswellen), és rájönnek hogy ha linuxon működik a cucc, akkor áthozzák asztali és notebook frontra is.
Igazából a user experience szempontjából szerintem ha bármelyik mai processzor soros teljesítményét lefeleznénk, akkor sem változna számottevően. Egy SSD sokkal de sokkal többet nyom a latba, mint a GHz-ek. Egyedül a DX és GL rajzolási parancsai miatt kell az irrgalmatlan soros teljesítmény. Intelnek már csak ezért is jönne jól Mantle, mert így nem kellene a konzumer fronton olyan irrgalmatlan erős soros végrehajtásra játszani, hanem lehetne párhuzamosítani.
-
stratova
veterán
Lehet ekkora lapkát még Intelnek is problémás lenne 14 nm-en jó kihozatallal legyártani. Ha nem tévedek korábban szóltak hírek Broadwell (14 nm) gyártása körüli problémákról.
Azt meg kell hagyni, ahhoz képest hogy milyen fogyasztása van, már Silvermont sem rossz (Fiery hasonlította össze nemrég).
Plusz, ezekbol lehet 8 db-ot is berakni egy dobozba, az mondjuk 128 mag. Es azt is meg lehet hajtani x86 koddal, minden gond nelkul.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- iPhone-t használók OFF topikja
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Nothing Phone (3) – tervezett kaotika
- gban: Ingyen kellene, de tegnapra
- BestBuy topik
- Hardcore café
- Fotók, videók mobillal
- Gyúrósok ide!
- Sorozatok
- Autós topik
- További aktív témák...
- GYÖNYÖRŰ iPhone 13 mini 256GB Red -1 ÉV GARANCIA - Kártyafüggetlen, MS3405
- Fém, összecsukható és kihúzható fotó állvány eladó
- BESZÁMÍTÁS! MSI B450 R5 5600X 16GB DDR4 512GB SSD 1TB HDD RX 5700 XT 8GB ZALMAN S3 TG Chieftec 600W
- Bomba ár! Dell Latitude E7270 - i7-6GEN I 8GB I 256GB SSD I 12,5" HD I HDMI I CAM I W10 I Gari!
- BESZÁMÍTÁS! GIGABYTE A520M R5 5600X 16GB DDR4 512GB SSD RX 6600 8GB Zalman N4 Plus FSP 400W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest