Hirdetés
-
Magyarországon is megjelent a Honor Band 9
ma Fekete színben már megtalálható a Honor friss aktivitáskövetője a nagy elektronikai áruházakban.
-
Mullet MadJack teszt
gp A Hammer95 első játékában a mesterséges intelligencia találkozik a szintipoppal, a 80-as évek hajviseletével, és rengeteg vérontással.
-
Újabb robottaxis balesetekre derült fény
it Az USA biztonsági vizsgálatot indított a Waymo önvezető autói kapcsán, és újabb balesetekre derült fény.
Új hozzászólás Aktív témák
-
joghurt
addikt
Gépi tanulásban akad sok, bár ugye ez inkább szerveres meló (Xeon). Ott mondjuk 3 utasítás helyett 1 elég egy iterációhoz.
Az AVX-512 eldobásának inkább olyasmi okát gyanítom, hogy a gyakorlati megvalósításban nem ritka a downthrottling miatta, azaz a vegyes terhelés többi feladata lassabb lesz tőle.
Elég jó összefoglaló/körbetekintés olvasható róla itt.A tej élet, erő, egészség.
-
dokanin
aktív tag
válasz Petykemano #50 üzenetére
Lehet, hogy abszolút nem releváns idehozni a Phi-t, de a rengeteg gyenge mag bepaszírozása a nagy magok mellé nekem elég necces ötletnek tűnik.
.net fejlesztőként én azt látom, hogy ott abszolút az egyenlő teljesítményű magokra épül a parallel framework. Szóval ha én akarnám se tudnám támogatni a kicsi magokat. Viszont ha véletlenül bekeverednek a treadpoolba kicsi magon futó szálak is, akkor a szinkronizáció és a működési modell miatt a gyors magokat is vissza fogják fogni.
Mindenesetre kíváncsi leszek a gyakorlati tesztekre. -
Petykemano
veterán
Nem "gyenge mag"
Ahogy mondtam, elvileg a Gracemont mag IPC-je elég magas, valahol ott van, ahol a skylake. Attól az intel épp csak most kezdett elrugaszkodni. Elvileg a Golden Cove magok IPC-je "csak" ~33%-kal magasabb. Legyen 30-40%. [link]jól skálázódó több szálas terhelés esetén (ahol létjogosultsága lehet a 16+ magos DT/HEDT Ryzennek), a magok nem tudnak a turbó frekvencián ketyegni. De 1Ghz differencia azért biztosan lesz a két magtípus között még úgy is.
Tehát ha egy Golden Cove magot 1 egységnyinek veszünk (MT terhelés esetén turbó nélkül), akkor IPC alapján egy Gracemont 0.75 és mondjuk frekvencia szempontjából is 25%-kal kevesebbet ér el, akkor valahol 0.6 körül találunk egy Gracemont magot.
De az 1 Golden Cove magra is 2 szál jut a HT miatt, vagyis valójában a Golden Cove 1 szálon szintén csak valahol 0.6 - 0.65 körüli értékkel fog rendelkezni.Viszont 1 Golden cove mag (2x0.65) helyére elfér 4 Gracemont (4x0.6)
Az egész persze azon fog múlni, hogy az ütemező tudja-e ezt kezelni, hogy mikor érdemes egy programszálat a kis magra tolni. Az ezzel kapcsolatban megszólalok azt mondják, hogy a windows 11-ben elég jól sikerült megugrani ezt a kihívást.
Azt nem tudom, hogy .net esetén neked milyen kontrollod van/lesz arra nézve, hogy a programszálak milyen processzor szálakra ütemeződnek. De remélhetőleg kevés szálon futó program esetén lesz olyan okos az ütemező, hogy ne kutyulja, vagy okosan kutyulja a szálakat.
Egyébként a 8 magos cpu esetén ha a programod 8 szálnál többel dolgozik, akkor az mindenképp egy "melyik ujjamba harapjak" szituáció, nem? Ha keletkezik egy 9. szál, akkor az nagy eséllyel egy már amúgy foglalt mag második szálját fogja befoglalni.Mindenesetre biztosan lesznek problémák kezdetben. Csakúgy, ahogy a zen 4magos CCX felépítésével kapcsolatban is voltak.
Találgatunk, aztán majd úgyis kiderül..
-
tha_answer
őstag
válasz Petykemano #53 üzenetére
a dark silicon miatt ez a jovo
-
arabus
addikt
válasz Petykemano #53 üzenetére
Ismét egy flame keltő cikk a szerzőtől.
Bár minden próbálkozásán felül úgy látszik a gyengének nevezett magok igen szépen teljesítenek.
Xeon Platinum 8490H,8468H,Ryzen 7500F,Gigabyte B650M K,Xeon Phi,i9 7960X,i9 7920X,Xeon w2135,Gskill royal 4400,Gskill Trident Z,Pico 4,Red Devil 7900XTX,Asrock W790 WS,Fury Pro RDIMM 6000,Z590,Intel Cryo,Intel 11900F,Ryzen 5600,Radeon 7600,Radeon 6800...
-
E.Kaufmann
addikt
Ühüm, és melyiket is lehet kapni (jó, tudom, van mikor egyiket sem ), meg melyik tudta előbb? És melyiknek nem kell szórakozni többféle maggal, mert minden mag rendesen tud skálázódni fogyasztás ügyileg?
Még szép, hogy az intel be tudja érni az AMD-t, különben még nagyobb sz@rban lennénk PC buherátorok, ha nem lenne verseny.
Ugye nem azt akartad mondani, hogy sz@r az AMD mert beérték? :D[ Szerkesztve ]
Le az elipszilonos jével, éljen a "j" !!!
-
Darmol
senior tag
Most akkor arról beszélgetünk, hogy a PSP szerinted nem része az AMD prociknak, szerintem pedig igen?
Aki azt mondja "nem tudom elhinni az igazságot" az naiv. Aki azt mondja "nem akarom tudni az igazságot" az ostoba. Aki azt mondja "az igazság tilos" az gonosz. Aki azt mondja "én határozom meg az igazságot" az beteg.
-
joghurt
addikt
Mi köze a PSP-nek a CISC/RISC témához? Hogy egy ARM Cortex a5 felügyeli? Kb. annyira releváns, mint hogy az alaplapi Ethernet-vezérlőben, SATA-vezérlőben, vagy a tv távirányítójában milyen mikrokontroller ül.
Az AMD processzorok számítási teljesítményéhez a PSP miatt ott levő ARM magnak semmi köze, az az x86/AMD64 programok futtatásába nem dolgozik be, és ARM programot sem tudsz futtatni az AMD procidon (csak x86-os emulátorban ).A tej élet, erő, egészség.
-
S_x96x_S
őstag
> Igen. Szervereknél és munkaállomásoknál lehet jelentősége,
> mezei klienseknél nem,
> egyszóval a felhasználóknak nem fog hiányozni.ez az X86 fragmentációja miatt van - ami annyira komplex, hogy nem éri meg a vesződség a kis részarányú mikro optimalizációnál.
Eddig az Intel tudatosan visszatartotta az AVX-512 -öt a Consumer szinttől - és ennek az a következménye, hogy kevés fejlesztő építette be.De a Játékok Fizikai Engine-je ( physics engine library )- biztos profitálna egy AVX-512 -es targettel, de még a több CPU-s támogatás integrálásával is le vannak maradva a game-engine fejlesztők.
Bármi - ami komolyabb matematikát használ - ki tudná használni az AVX-512 -öt
De valami elindult az elmúlt évben
( https://lists.llvm.org/pipermail/llvm-dev/2020-July/143289.html )
és talán az "x86-64 Microarchitecture Feature Levels" hoz valami változást - consumer szinten is.x86-64-v1: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2
x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE
x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL
Jelenleg
- a GCC 11; LLVM Clang támogatás megvan,
- a Linux kernel-t okosítják ( 18 August 2021 )
- és jelenleg egyes linux disztribuciók - azon gondolkodnak, hogy melyik "feature levels" - támogassák - vagy ne támogassák.Jelenleg a sok program binárisát a kompatibilitás miatt
- csak a legrégebbi "x86-64-v1"
-re fordítják le .. és annyi ..És 1-2 év múlva a Windows is követni fogja ezt a trendet,
főleg ha tartani akarja a riválisokkal a tempót.Vagyis aki hosszabb távra beruház - az várhatóan 4-5 év múlva érezni fogja az eltérést
De aki csak 1 évre vesz gépet - annak felesleges erre optimalizálni.
Mottó: "A verseny jó!"
-
Darmol
senior tag
-
Pingüino
senior tag
válasz Petykemano #16 üzenetére
Erre memóriakoherens eléréssel, és alacsony késleltetéssel egy APU sokkal jobb. A kifejezetten sok szálon futó alkalmazásokat már rá lehet verni egy GPU-ra is. Több értelme van.
-
Pingüino
senior tag
válasz Petykemano #25 üzenetére
A koncepció csak egy dologra jó, mégpedig az Intelnek, hogy el tudja mondani, hogy magok számában, és az elérhető órajelben is ők a legjobban. Hogy előbbi csak a kis magokra vonatkozik, utóbbi meg a nagyokra, az már részletkérdés.
-
Pingüino
senior tag
válasz tha_answer #26 üzenetére
Az a felhasználás módjától, és a szoftveres optimalizációtól függ. Hiába jóval hatékonyabbak a RISC alapú processzorok, ha asztali környezetben olyan utasításkészletet használnak a szoftverek, amit a RISC alapú processzorok csak nagy energiabefektetés árán tudnak emulálni.
Magyarul nagy előrelépést lehetne elérni az ARM-re váltással, de ahhoz minden szoftvert arra kellene optimalizálni, ami irgalmatlan sok munka. -
Pingüino
senior tag
Erre lesz jó, ha az AMD-nek sikerül a memóriakoherens összeköttetés a különböző részegységek között, és akkor mehet egy processzorba x86-os mag, ARM-es mag, GPU mag, és különböző hardveres gyorsítók is. Aztán minden azon fut majd, amin neki ideális. De ezzel is ugyanaz a probléma, mint az egyszerű BIG.Little koncepcióval, hogy szoftver oldalról is erősen meg kell támogatni. Az lesz a neheze.
-
dokanin
aktív tag
válasz Petykemano #53 üzenetére
"Egyébként a 8 magos cpu esetén ha a programod 8 szálnál többel dolgozik, akkor az mindenképp egy "melyik ujjamba harapjak" szituáció, nem? Ha keletkezik egy 9. szál, akkor az nagy eséllyel egy már amúgy foglalt mag második szálját fogja befoglalni"
A .net parallel framework-je mindig annyi szálat ad egy feladatnak amennyi tényleges fizikai szál létezik. Természetesen ebbe bele lehetne nyúlni, de alapból így fut minden.
Szerintem a most megjelenő .net 6 is így működik még ha jól tudom.
És mivel a .net keretrendszerek régebbi verziói nem nagyon változnak, ezért az abban írt szoftverek egy 8+8 magos alder lake procin szerintem simán 16 szállal futnának neki minden ilyen feladatnak de ebben az esetben az összes szál bevárja egymást a művelet végén tehát a leglassabb szál sebessége a döntő.[ Szerkesztve ]
-
Petykemano
veterán
Elméletileg a GPU nyilván alkalmasabb lehet sokszálas throughputra.
Amiben nem értek veled egyet az az, hogy szerintem ahhoz viszont az egyes szoftvereket kellene átírni. Gondolom hosszútávon ez a cél, az Intel nemrég arra verte a nyálát, hogy náluk mennyi minden különböző célű részegység - CPU, GPU, FPGA, etc - megvan, míg a konkurenciáknál semmi.Szóval a GPU-s futtatásra való átírást a szoftvernél kell megoldani, míg a kis és nagy magok közötti megfelelő ütemezést el tudták intézni a MS-tal - akivel közös érdek, hogy ez jól menjen.
Azt a Kaveri óta várjuk, hogy megtörténjen a GPU-ra való terhelés offloadolás. Jó, én értem, hogy az AMD kis piaci szereplő, de az intel esetén generációk óta ott van minden asztali és notebook processzorban az IGP és mégis elég kevés, ahol GPU-ra való offloadolás létezik.
Hogy miért, azt én nem tudom, de azt gyanítom, hogy valami olyasmi van, hogy az IGP ugyan memóriakoherens, de túl gyenge ahhoz, hogy megérje vesződni vele, a dGPU már elég erős volna, de a memóriatartalom másolás/elérés/késleltetés túl nagy ahhoz, hogy megérje vesződni vele.
Arra is csak várunk, hogy legyen valami middleware, ami anélkül oldja meg a IGP-re való offloadolást, hogy a programot kifejezetten úgy kelljen megírni.
Az is álom, hogy - az AMD - majd a vektorutasítások CPU-ba való integrálása és implementálása helyett a az AVX-AVX2-AVX512 utasításokat offload-olja a GPU-ra, amiben a SIMD egységeket pont erre találták ki, nem csak valami "ritkán használt, hülye" kiterjesztés.Persze elméletben lehet, hogy igazad van, szuperszámítógépekben nyilván nem véletlenül használnak GPU gyorsítókat. De ilyen jelen viszonyok között valószínűleg egyszerűbb (profitábilisabb) volt gurítani egy 64 magos Threadrippert.
Egyébként az azért látszik, hogy az intel sem nyomott all-in-t azért. az ALder Lake egy elég óvatos próbálkozás, amivel leginkább az ütemező lesz tesztelve. Ha mégse jön be bármi okból, akkor tulajdonképpen bármikor nyomhatnak egy hátraarcot és építhetnek csak Cove magokból procikat. Azt gondolnám, hogy ha az Alder lake bukó lesz, akkor a Raptor lake utáni generációban még korrigálhatnak.
Találgatunk, aztán majd úgyis kiderül..
-
Pingüino
senior tag
válasz Petykemano #67 üzenetére
Erre lesz jó egy fejlesztői keretrendszer, ami átveszi a programozótól a processzor különböző részegységeire történő feladatelosztást. Úgy rémlik, volt róla cikk, hogy dolgoznak is valami ilyesmin, de nem igazán találom.
-
S_x96x_S
őstag
válasz Petykemano #67 üzenetére
> Az is álom, hogy - az AMD - majd a vektorutasítások CPU-ba való
> integrálása és implementálása helyett a az AVX-AVX2-AVX512
> utasításokat offload-olja a GPU-ra,előbb - utóbb megvalósul.
A OneAPI - https://www.oneapi.io/ ennek az ötletnek a szoftveres megvalósítása.
és az is lehet, hogy az újabb Rosetta emuláció ( Apple M1 ) már így emulálja majd a most nem támogatott vektoros utasításokat.
vagy ott van az AMD ROCm
és az LLVM -
ami kódot tud generálni a CPU-ra és a GPU-ra is.de ezek szoftveres megközelítések.
Mottó: "A verseny jó!"
-
kovcsrob
tag
Van valami különösebb oka, hogy sokan úgy tekintenek a CPU ra, mintha csak a felhasználó által indított egy darab alkalmazás futna rajta indulástól leállásig?
Jelen esetben van két magcsoport.
Az intel szerint egyforma utasítások kellenek, mert az ütemező nem tudja előre, hogy milyen utasítások lesznek egy szálban. Gondolom macerás lenne mozgatni a nem végrehajtható szálakat. (legalábbis ha jól értettem, amit írtak)
Szóval van két eltérő sebességű magcsoport, amin számtalan programszál fut. Rendszer kezelő dolgok, driverek, IO kezelés, felhasználói programok háttérfolyamatai... (és a böngésző is játék közben) minden "látszólag" egy időben.
Szóval jelenleg sincs X darab szálunk/magunk, amit használhatunk, a gép meg vár, ameddig a program végez. Tehát jelenleg sem tekinthetünk rájuk egyforma gyors magként. És jelenleg fizikailag sem egyforma gyorsak az eltérő órajelek miatt.
Akár még jól is elsülhet ha az alacsony prioritású folyamatok más magra állnak sorba, mint a magas prioritásó folyamatok. -
Petykemano
veterán
Nem teljesen értem az aggodalmad.
Jelenleg ha van egy 8 magos procid, és a parallel framework (PF) 8 szálat indít és egyenlően osztja el a terheket, akkor azok nagyjából egyenlő időben végeznek. Tételezzük fel, hogy 16 egységnyi feladatod van, akkor 2 egység idő alatt végeznek.Természetesen ha 16 magos procid lenne, akkor 1 egységnyi idő alatt lenne kész 16 szálon.
Az alder Lake esetében azt fogod tapasztalni, hogy 16 szálat indít a PF, ebből 8 szál egységnyi idő alatt lesz kész, a másik 8 pedig 1.5 egységnyi idő alatt. Az sem kizárt, hogy miután a nagy magokra ütemezett szálak végeznek, az ütemező a kismagokon futó szálakat átütemezi nagyjából 2/3 állapotban a nagy magokra és végeredményben mégse 1.5, hanem mondjuk 1.3-1.4 egységnyi idő alatt leszel kész.
Ez persze nem olyan gyors, mintha 16 nagy magból álló procid lenne, de az Alder lake tranzisztor és energiaigénye csak kb 10-11 nagy magnak felel meg. Ha 10 nagy magos procid lenne, akkor a 16 egységnyi feladatod 1.6 egységnyi idő alatt lenne kész.
Tehát összességében - ahhoz képest, amennyi helyet és energiát igényelnek a kismagok - jobban jársz.Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
OneAPi és ROCm.
Előtte HSA volt.Ne érts félre, nem azt mondom, hogy soha nem fog bekövetkezni, nyilván nem véletlenül csinálja az intel a GPU-kat és a OneAPI-t .
Biztos lesz olyan program, ami nagyon hamar használatba veszi majd ezeket.
De én úgy vélem, hogy big.LITTLE és a GPU offload közül előbbire könnyebb/gyorsabb általános szoftveres támogatást kieszközölni.Találgatunk, aztán majd úgyis kiderül..
-
tha_answer
őstag
válasz Petykemano #72 üzenetére
mozilla rust webrender
-
dokanin
aktív tag
válasz Petykemano #71 üzenetére
"Az sem kizárt, hogy miután a nagy magokra ütemezett szálak végeznek, az ütemező a kismagokon futó szálakat átütemezi nagyjából 2/3 állapotban a nagy magokra"
Na hát ez tűnik nekem sci-fi-nek. Egyszerűen nem tudom elképzelni az ütemező ezt mi alapján tudná eldönteni, meg aztán az is kérdés, hogy ez egyáltalán lehetséges-e.
De persze attól, hogy én nem látom mi a megoldás, még lehet. Majd kiderül. -
Tentalus
tag
válasz Petykemano #71 üzenetére
Az egész akkor érne valamit, ha a nagy teljesítményű magok hajtanák végre a 'fontos' -azaz időkritikus -feladatokat, a kisebbek a kevésbé fontosat.
Bizonyos esetekben ez előre megjósolható, a programozó beállítja a szál tulajdonságai közé,hogy ez 'fontos'. Móricka példa szerint pl. egy játékban az ellenség mozgása szál legyen 'fontos'. Ez így ok, kérdés, hogyan teszi meg ezt egy programozó? C++-ban lehetséges, de C#-ban? Javascript-ben? Ez a módszer nem működik a meglévő programokkal.
Sok esetben előre nem jósolható meg, melyik szál lesz időkritikus... pl. egy SQL szervernél melyik lekérdezés fut le 1 mp és melyik 30mp alatt? Elég ciki, ha a gyenge mag kapja a brutálisan bonyolult lekérdezést (amiben 1 millió rekordot kell rendezni) , az erős mag meg a könnyed 2 rekordot...Ilyenkor elvileg át lehet dobni az erős magra az éppen futó feladatot, csak mikor? Ki dönti ezt el? Magváltáskor nagy lehet a teljesítményvesztés, a teljes cache-t bukja az erős mag...
-
dokanin
aktív tag
Ráadásul a .net induláskor létrehoz egy csomó szálat a szálkészletben, amiket folyamatosan újrahasznosít, mivel nem éri meg szálakat létrehozni és megszüntetni minden feladatnál.
Így viszont megmondani sem lehet, hogy egy szálon mekkora terhelés lesz, mivel ez folyamatosan változik. Szóval, hogy az ütemező hogyan tudna helyesen dönteni kész rejtély. De gyanús, hogy sehogy. -
poci76
aktív tag
Abban a szimulátorban, amin dolgozom, az előző verzióban N egyenlő részre bontottam a feladatot, így elvileg kb. ugyanannyi idő alatt végeznek. Aztán rá kellett jönnöm, hogy nem jól gondolkodtam, mert simán lehetnek ebben a programban olyan programrészek, amelyek számításigényesebbek a többinél, így vannak feladatok, ahol 70-80% közé is visszaeshet a processzor kihasználtság az általam remélt >90% helyett (vannak nem párhuzamosítható részek, emiatt a 100% nem elérhető) egy 12 magos gépen.
Az új változatban olyan párhuzamos motort írtam, ami elvileg hatékonyan kezeli a viszonylag apró részekre bontott feladatot is. Itt a szál megnézi, hogy van-e még részfeladat az adott feladattípusból, amit végez, és ha van, kiveszi a feladattárolóból, majd végrehajtja. Így, amíg van feladat, addig minden szál dolgozni tud, és ha elfogyott, utána pihen, amíg nincs feladat. Sajnos még vagy egy év, mire komolyan tesztelni fogom tudni a rendszert. Minden esetre ez jól passzol a big-little procikhoz is.
Ami a hatékonyságot ronthatja az előző verzióhoz képest az az, hogy az N szálra bontott verzió sokszor a saját maga által létrehozott eredményen dolgozik tovább, míg az új motor ezzel nem foglalkozik, túl bonyolult lett volna, így itt nagyobb a cache hibák száma. Majd csak a tesztnél derül ki, hogy ez okoz-e érdemi lassulást.
-
joghurt
addikt
Ezt az ún. thread poolozást kb. minden valamire való környezet használja. Bár menet közben tudsz buzerálni a szálak paraméterein (prioritás, sőt: konkrétan magokhoz/magcsoportokhoz rendelés), alapvetően az oprendszer ütemezőjének a dolga, hogy ezt a meccset lejátssza. Persze, a saját szempontodból a saját szálad a legfontosabb, de rajtad kívül fut száz másik folyamat, aminek szintén van nagyon fontos dolga.
Ha van egy rakás lefuttatandó feladat, és ennél kevesebb processzormag (mindegy, milyen erőviszonyokkal), akkor az összes megemésztése kb. ugyanannyi ideig fog tartani - függetlenül attól, melyik mag melyik feladattal kezd. Az OS ütemezőjének meg remélhetőleg megvan az információja, hogy a vége felé (amikor már fogyóban a nagyon fontos dolgok), akkor az erős magokra ütemezze a nagyobb prioritású szálakat.
A Little.Big nem a számítási teljesítményt növeli, hanem lehetővé teszi a nagy teljesítményű magok lekapcsolását, ha azokra nincsen szükség (pl. zsebre rakott telefonnál).@Tentalus: Időkritikus dolgot nem írsz JS-ben, mert arra nem való. Ennyike.
A tej élet, erő, egészség.
-
joghurt
addikt
Érdemes lenne próbálkoznod N/2 és 2*N között más értékekkel is. Feladata válogatja, hol lesz az optimum. (És akkor még a HyperThreading-féle kavarásokról nem is beszéltünk, hogy most akkor ott igazából N vagy N/2 processzorod van. Amilyen feladatra anno mi használtuk, ott annyira kihajtottuk a végrehajtó egységeket, hogy csak a fizikai magokkal lehetett számolni.)
A tej élet, erő, egészség.
-
Tentalus
tag
Az OS ütemezőjének olyan információja egészen biztosan nincs, hogy mikor van egy szál a "vége felé".Ez jövőbe látás lenne. Annyit tud, mi történt előzőleg, az utolsó néhány milliszekundumban mekkora terhelést kaptak a magok.
Ha van egy 0-1% terhelésű erős magom, akkor arra érdemes rátenni a 100% terhelésű gyengét. Ez ok.
De ha van egy 100% terhelésű erős magom és egy 100% gyenge, nem fog az ütemező semmit se csinálni. Pedig bizonyos esetben érdemes lenne , pl. a gyenge magon fut a nagyfőnök milliós SQL lekérdezése. De ezt az oprendszer nem tudhatja.ui:
A Javascript is lehet időkritikus, például egy felhasználói felület esetében nagyon is számít, mennyi idő alatt fut le egy adatellenőrzés stb. De van képszerkesztő is JS-ben. -
joghurt
addikt
"Vége felé": Értsd: Magas prioritású szálból kevesebb maradt, mint magból.
Az, hogy JS-ben minden megírnak, nem jelenti azt, hogy az alkalmas eszköz rá, vagy az lenne a legalkalmasabb rá. Lehet, hogy könnyebb benne fejleszteni, de nem fog olyan gyorsan futni, mint egy optimalizált asm vagy C kód.
(Az UI interakciók pedig sosem időkritikusak. Kb. definíció szerűen.)A tej élet, erő, egészség.
-
Tentalus
tag
Az egy egyszerű eset,ha magas prioritású szálból kevesebb maradt, mint magból, a problémás esetekre (több szál,mint mag) nem látom a megoldást.
A JS erősen OFF itt, de az UI egyes elemei igenis erősen időkrikusak, próbálj ki egy rendszert,ami nem reagál egy gombra kattintásra, csak úgy 1-2 tized mp múlva és meglátod
-
Robitrix
senior tag
Amúgy valóban így van a XEON Phi gyakorlatilag egy 80 mag körüli speciális lebegőpontos társprocesszor volt.
-
Robitrix
senior tag
Na látod ez egy érdekes fejlesztés volna. Egy olyan fejlesztő rendszer, ami magától meg tudná mondani, hogy mikor majd fut a kód, akkor a program ágai milyen erőforrás igénnyel bírnak. Gőzöm sincsen ezt hogy lehetne mondjuk automatikusan eldönteni egy fordításkor. Azt el tudom képzelni, hogy olyan a fejlesztő rendszer, ahol maga a programozó tudja valamiféle forditói direktiva megadásával, hogy egy adott program szál vagy szubrutin stb. milyen erőforrás igénnyel bír. Mondjuk meglehetne adni hogy alacsony, közepes, magas az adott programrész erőforrás igénye, Aztán ez fordításkor bekerülne a kódba valamilyen formában aztán ezen infó alapján tudná a rendszer erőforrás ütemezője eldönteni, hogy mit kell gyors magra rakni és mit lassabb magra. Elvégre nyilván a programozónak van elképzelése róla, hogy a saját programjának Melyik programszála mennyi teljesítményt igényel.
-
Robitrix
senior tag
Hogy tovább bonyolódjon a dolog egy felhasználó programnak nem csak a rendszer folyamatokkal kell osztozni a a CPU magokon és szálakon, hanem akárhány egyéb felhasználói programmal is. Elvégre semmi nem garantálja mondjuk egy 8 magos CPU esetében, hogy adott pillanatban nem 6 felhasználó program akar rajta futni mondjuk 28 programszál igénnyel. Plusz még az operációs rendszer folyamatainak programszálai, amelyek amúgy is magasabb prioritással bírnak, mint a felhasználói programok.
-
Pingüino
senior tag
Itt nem erőforrásigényről van szó, hanem a teljesen eltérő felépítésű magokról. Hogy ha valaki szoftvert fejleszt, akkor ne kelljen megtanulnia külön CPU-ra, GPU-ra, FPGA-ra, meg egyéb speciális gyorsítókra programot írni, hanem a keretrendszer képes legyen amolyan univerzális fordítóként működni. De lehet, hogy az előző hsz-ben félreérthetően fogalmaztam.
-
Robitrix
senior tag
Mondjuk a fordító programban a megfelelő subrutin vagy programszál elejére beillesztett fordítói direktívával? Ami megmondja, hogy adott programág erőforrás igénye LOW, medium vagy HIGH. Aztán mikor elkövetkezik az adott programágnak a futása, akkor ezen infó alapján tud dönteni a rendszer erőforrás ütemezője, hogy mit tesz a lassabb magra és mit tesz a gyors magra. Mondjuk ha nincsen minősitve erőforrás igény szerint az adott program ág akkor automatikusan médiumnak tekinti a rendszer, aztán majd oda teszi, ahol éppen van szabad időszelet. Mondhatnánk azt, hogy a programozó trüközhetne is azzal, hogy a programjának minden szálának high minősítést ad, de ezzel lehet magával baxna ki. Mert lehet előállítja a kevés a fóka, de sok az eszkimó effektust. Legyen mondjuk egy 8 gyors és 8 lassabb magot használó proci. Fut a rendszerben több felhasználói program(az rendszer folymatokon kívül) aztán mindnek HIGH a minősítése, És akkor előállhat az a helyzet, hogy egyszerre 43 folyamat ácsingozik a 8 magon kapni egy időszeletet. Vagyis hibá adok HIGH minősítést a programágnak, ha túl sok az eszkimó és kevés a fóka. Közben ott ácsorog alig használva a 8 gyerek fóka. Jobban jár a programozó, ha a kis teljesítményt igénylő programágai kényelmesen lefutnak a kisebb magokon nem nővelve a marakodást a gyors magokért. Persze, hogy aztán van-e annyira "okos" az erőforrás ütemező, hogy abban az esetben ha túl nagy a tülekedés a folyamatok közt a gyors magért akkor képes legyen felül bírálni az előzetes minősítést és néhány folyamatot elengedjen futni a kihasználatlan gyengébb magokon. Hiszen a várakozás helyett még a lassabban futás is hatékonyabb. Szóval igen érdekes lesz az a erőforrás ütemező program, ami képes hatékonyan kihasználni egy hibrid proci lehetőségeit. Valami azt súgja nekem, hogy pont ezért lesz hirtelen a win 10-ből win 11. Hiszen eddigi infók alapján semmi indoka nincsen, hogy ne win 10 21H2 legyen a következő fejlesztés. Szerintem azért win 11, mert abban olyan erőforrás ütemező van már, ami képes majd hatékonyabban kezelni a hibrid procikat. Amúgy csinált már hibrid procit az intel 2019 nyarán. Egy 4+1-es proci volt 4 normál maggal és egy darab gyorsabb maggal. De a gyakorlatban akkor nem vált be a windows erőforrás ütemezője miatt. Csak a statsiztikia véletlenen múlt, hogy mikor találkozik őssze a nagy számítást igénylő programágak a gyorsmaggal. Csak 20% esély volt rá, hogy sikerül a gyors magon futni a sok számítást igényéó folyamatoknak. Cikkeztek akkoriban róla egy keveset, de túl nagy feneket nem keritettek a dolognak, mert nem igazán nőt a hatékonyság számottevően. Vagyis már akkor felmerült az igény egy hatékonyabb erőforrás ütemezőre, ami már igyekszik figyelembe venni egy hibrid proci lehetőségeit. Ezért lett szerintem hirtelen win 11 a win 10-ből.
-
Cefet
aktív tag
Vannak fenntartásait az Intel döntésével kapcsolatban...
De: " ő tuta' mitiná'... " -
tha_answer
őstag
igen itt jobban tudjuk mint 5000 phdst foglalkoztatoi paranoid ceg aki csak s reszvenyesek idiotasaga miatt tart ott ahol.
megsugom nektek, par generacio es notiban csak efficient corek lesznek. egyszeruen hatekonyabb adott sziliciumteruletbol es energiabol tobbet ad le.
notiban mire nem eleg ma egy skylake magja?
notiban egy tizeves sandybridge mindenre is eleg, es ott sem a kraftal lesz gond hanem a memorialimittel.
[ Szerkesztve ]
-
Robitrix
senior tag
ez szerintem nem ennyire egyszerű egészen más kódot igényel egy GPU-n futó program, mint egy CPU-n futó program. Meglehetősen más egy CPU és egy GPU müködése. Egy CPU esetében totál eltérő kódok futhatnak a magokon és szálakon egyszerre. Ezen túl egy GPU utasítás készlete egyszerűbb és primitívebb, mint egy CPU. Egy CPU gyakorlatilag sok száz féle utasítást tud végrehajtani(ma egy X86-os proci ismer kb. 800 féle CISC utasítást) A GPU utasítás készlet ismeri elemi egyszerű utasításokat és olyan utasítás fajtákat, amelyek grafikai műveletek végrehajtását támogatják. Ráadásul egy GPU gyakorlatilag több féle részre oszlik Vannak shader egységek rengetek, amelyek gyakorlatilag a poligonos képalkotás műveleteit tudják elvégezni a pixelekre, vannak texturázó egységek, RTX-es kártyákban tensor magok stb. Ráadásul mondjuk egy GPU-ban van van vegyük az én GTX 1660-amat 1408 darab shader egység. Egy RTX 3090-ben meg úgy 10500 darab körül. Viszont ezek az egységek nem szabadon programozhatok mondjuk 1408 féle algoritmusra. Ezek az egységek csoportokba vannak fogva. Ha jól tudom az egy csoportba tartó egységek csak ugyan azt az algoritmust tudják egyszerre végrehajtani csak persze mindegyik az adott kép pixelre számolja az adatot. Ha jól tudom valójában ezeket a csoportokat hivják az NVIDIA esetében CUDA az AMD esetében CU egységnek. Vagyis az egyben feladatra fogható végrehajtó csoportok. Az én kártyám esetében ha jól dereng az 1408 shader egység talán 22 csoportra oszlik. Ezért is nevezik például a VEGA 8-at 8-nak mert 8 végrehajtó csoport van benne. a VEGA 11-ben meg 11 darab. Amúgy simán keverik a fogalmakat mert néha CUDA.ként hivatkoznak a shader egységek számára. Azt azért hozzá tenném, hogy életemben nem programoztam még GPU-t így alapvetően hülye vagyok hozzá így ha nagy baromságot mondtam nem kell a fejemre olvasni.
Mindent összevetve azért nehezen tudok olyan forditó programot elképzelni, ami egy általánosan megirt programot képes mondjuk GPU-n futó kódra lefordítani. Vagy bármiféle hardveres gyorsítóra. Persze lehet, hogy egyszer majd tényleg születik univerzális forditó program, ami pikk pakk minden féle felületre képes kódot generálni. -
hokuszpk
nagyúr
válasz tha_answer #90 üzenetére
"mire nem eleg ma egy skylake magja?"
oke, _MA_ mindenre elég. de ez mindig ígyvolt, amikor a hw előreszaladt, akkor a fejlesztők előbb-utóbb találtak rá remek megoldásokat, hogy újra ott tartsunk, hogy kevés az erőforrás az aktuális csúcsvasban. Ne legyen így, de szvsz hamarosan ujra "utoléri" a szoftver a hardvert.
[ Szerkesztve ]
Első AMD-m - a 65-ös - a seregben volt...
-
Ezeken felesleges aggódnod. A .Net Task Parallel Library (TPL) amit konrétan felhoztál illetve álltalában egyéb .Net jóságok mutatnak a fejlesztő felé egy API-t, mint pld a Parallel.ForEach amit a programozó használhat és tudja hogy működni fog, többé-kevésbé jól.
Az hogy a motorháztető alatt hogyan működik ez, az a Framework dolga, a Framework készítői pedig pár év késéssel majd lekövetik a változó világot. Pld Ő
Ehhez hasonlóan pld a Garbage Collectort sem kell (kivételes helyzetektől eltekintve ) kézzel mikromanagelni. Pár alapszabályt betartasz és jól működik a háttérben, függetlenül attól, hogy a program mobilon, PC-n vagy szerveren fut.
Egyébként a szóba hozott Parallel Library is akkor működik jól, ha a feladatokat jól szét lehet szabdalni egymástól független részekre ahol is nincsen szinkronizáció és a szálak nem várnak egymásra. Ilyen feladatok esetén pedig a tipikus cél az időegység alatt elvégzett munka maximalizálása és nem az hogy minél hamarabb készüljön el egy-egy rész-feladat (throughput vs latency).
Ebben a konkrét kontextusban a Big.Little koncepció semmilyen törést nem fog okozni. Ha belegondolsz, a nagy magok közül is 1-2 maxra boostolgat, míg a többik pár száz Mhz-zel alacsonyabban futnak, mégsem okoz ez problémát a TPL-nek.
Programozói modell szintjén én pld nagyon egyszerű és elegáns megoldásokat is el tudok képzelni az alacsony késleltetést igénylő feladatok és a nem kritikus dolgok szétválasztására .Net-ben. Ezzel nem lesz probléma, inkább hogy a programozók kezdjék el használni illetve updateljék az öreg programjaikat. (Kb soha napján ) Illetve kíváncsi vagyok hogy pld a MS elhiszi-e azt hogy ennek a big little dolognak van-e bármi értelme.
[ Szerkesztve ]
-
hokuszpk
nagyúr
válasz tha_answer #93 üzenetére
az avx512 azert nemterjedt el, mert eddig csak a nagyobb Intel procikban volt. Átlag Béla procijában nemigazán. Most a 11 genben végre mindenhol engedélyezte az Intel, kezdhetett volna átmenni mainstreambe.
* közben eszembejutott, mire nem elég a Skylake.
Windows 11[ Szerkesztve ]
Első AMD-m - a 65-ös - a seregben volt...
-
hokuszpk
nagyúr
válasz tha_answer #96 üzenetére
ez valoban szörnyű.
de sose becsüljük alá az Indiai "szoftvermérnökök" leleményességét !Első AMD-m - a 65-ös - a seregben volt...
-
tha_answer
őstag
az avx mandatoryt ugorjuk mar meg....
-
dokanin
aktív tag
Csak arra lennék még kíváncsi, hogy egy programozó miért fáradna azon, hogy bizonyos feladatokat a kicsi magokon futtasson? Nehezen tudok elképzelni egy projectet, ahol ez szempont lehet. Mi értele lenne ebbe erőforrást tennie a cégeknek? Nem nyernek ezzel semmit. Még a több mag kihasználása sem kap prioritást sokszor pedig ott tényleg lehet nyerni.
Én már csak azért sem hisznek abban, hogy a kicsi magokkal nem lesz semmi gond, mert a korai ryzeneken már az is tök sok teljesítményvesztést okozott, ha nem azonos ccx-en futottak a szálak.
-
S_x96x_S
őstag
> Én már csak azért sem hisznek abban,
ezek a negatív kisugárzások ..
Gondold erősen, hogy működni fog !
https://www.youtube.com/watch?v=wELAtDTaqnwMottó: "A verseny jó!"
Új hozzászólás Aktív témák
- Xeon E3 1230 V3 LGA 1150 processzor i7 4790 i7 4770 teljesítménnyel
- Intel I9 14900KS 24mag/32szál - Új - Eladó! 250.000.-
- Quad Core AMD Phenom II X4 945 (HDX945WFK4DGM) processzor
- Beszámítás! Intel Core i9 11900KF 8mag 16szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i9 9900K 8mag 16szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Alpha Laptopszerviz Kft.
Város: Pécs