- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Milyen cserélhető objektíves gépet?
- Projektor topic
- Azonnali processzoros kérdések órája
- Lenovo Legion és IdeaPad Y széria
- VR topik (Oculus Rift, stb.)
- iPad topik
- Autóhifi
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- ThinkPad (NEM IdeaPad)
Hirdetés
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
-
A virágcsokor mellé hardvert is ajándékozhatunk anyák napján
ph A héten desktop PC-k, monitorok, gamer kiegészítők és házak vannak a kirakatban.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Ú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.
-
#52
dokanin
aktív tag
Petykemano
#50
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. -
#53
Petykemano
veterán
dokanin
#52
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..
-
#54
tha_answer
őstag
Petykemano
#53
tha_answer
őstag
válasz
Petykemano
#53
üzenetére
a dark silicon miatt ez a jovo
-
#55
arabus
addikt
Petykemano
#53
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...
-
#56
E.Kaufmann
addikt
arabus
#55
E.Kaufmann
addikt
Ühüm, és melyiket is lehet kapni (jó, tudom, van mikor egyiket sem
![;]](//cdn.rios.hu/dl/s/v1.gif)
), 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, SSE2x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVEx86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VLJelenleg
- 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
-
#62
Pingüino
senior tag
Petykemano
#16
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.
-
#63
Pingüino
senior tag
Petykemano
#25
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.
-
#64
Pingüino
senior tag
tha_answer
#26
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.
-
#66
dokanin
aktív tag
Petykemano
#53
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 ]
-
#67
Petykemano
veterán
Pingüino
#62
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..
-
#68
Pingüino
senior tag
Petykemano
#67
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.
-
#69
S_x96x_S
őstag
Petykemano
#67
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. -
#71
Petykemano
veterán
dokanin
#66
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..
-
#72
Petykemano
veterán
S_x96x_S
#69
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..
-
#73
tha_answer
őstag
Petykemano
#72
tha_answer
őstag
válasz
Petykemano
#72
üzenetére
mozilla rust webrender
-
#74
dokanin
aktív tag
Petykemano
#71
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. -
#75
Tentalus
tag
Petykemano
#71
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
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. -
#90
tha_answer
őstag
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. -
#92
hokuszpk
nagyúr
tha_answer
#90
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 ]
-
#95
hokuszpk
nagyúr
tha_answer
#93
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...
-
#97
hokuszpk
nagyúr
tha_answer
#96
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...
-
#98
tha_answer
őstag
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.
-
Robitrix
senior tag
Talán, hogy elkerülje a kevés a fóka, de sok az eszkimó szitut. Ha sok a futásra váró program szál és nem jut alá elég mag és szál, akkor lesznek várakozó programágak. Természetesen azt is tudni kell mindenkinek, hogy amikor írja a programot nem tudja milyen hardveren fog futni a program. És a programnak osztozni kell más felhasználó programokkal: aha van egy 4 gyors 4 lassú magos gépem és az összes programszál a gyors magra vár, akkor a 4 gyors magon tumultus lesz. Írok mondjuk egy 6 párhuzamos programágat használó programot. ebből 2 programág nagy teljesítményt igényel 4 meg csak keveset. HA a 4 kisebb igényű mag is a a gyors magra kerül, akkor elveszik az időszeletet a gyors teljesítményt igénylő ágaktól. Miközben ott áll kihasználatlanul 4 lassabb mag, ami alig csinál valami. Prsze nem csak az említett program fut a gépen. Így ott fog tolongani mondjuk a 4 magért egyszerre 41 folyamat. vagyis a 4 fókára les a 41 eszkimó.... Minnél nagyobb a tülekedés a 4 magért annál kevesebb fóka darab jut egy eszkimónak. Amit nyerne teljesítményt a lassabb igényű programágak gyors magon futásával lehet simán elveszti a tülekedésben. Sokkal jobban járhat, ha a kis igényű program ágakat inkább ráküldi a lassab magokra. Hiszen akkor több teljesitményt tud szerezni a gépen. 4 gyors mag < 4 gyors + 4 lassabb mag. vagy képzelj egy egy égő házat a faluban. odamegy 30 ember oltani de csak 15 darab nagy vödör van, ami mondjuk 15 literes. Ha ott ácsorog 15 ember és arra vár, hogy hozzájusson egy fordulóra a 15 literes vödörhöz az rossz hatékonyság. De ha van 15 kisebb vödröm, akkor azt is a kezükbe nyomom és a 30 vödörrel már több vizet képesek a tűzhöz hordani. Tehát vélhetően jobban járok, ha kihasználom a lassabb magok teljesítményét is, mint ha folymatosan csak a gyors magokra próbálok spekulálni.
-
poci76
aktív tag
válasz
Robitrix
#101
üzenetére
A hozzászólásodból az látszik, hogy egyáltalán nem tudod, hogy működik egy számítógép és a rajta futó programok. A sokszálú programoknak két tipikus változata létezik. Az egyik a nem számításigényes programoké, a másik a számításigényes programoké.
A nem számításigényes programok, pl. egy böngésző, elindítja a szálakat, ezek csinálnak valamit, azután aludni mennek, és egész addig alszanak, míg a megfelelő esemény fel nem ébreszti őket. A Task Magagerben meg lehet nézni, hány ezer programszál fut egyszerre a Windowsban minden probléma nélkül, miközben a proci terhelése legfeljebb pár százalék, az is azok miatt a szálak miatt, amelyek csinálnak is valamit. Alapból egy alvó szál lényegében nulla terhelést okoz, nincs eszkimó-fóka probléma.
Ritkán fordul elő, hogy több teljesítményigényes programot futtatunk egyszerre, tehát általában egy teljesítményigényes program van, ami saját magával versenyez az erőforrásokért. A programozó el tudja dönteni, hogy hány programszálat futtat, és egy-egy szál milyen feladatot végez. A programozó tehát feltételezheti, hogy az ő programja az egyetlen teljesítményigényes program, ami fut. Ha a legnagyobb számítási teljesítmény elérésére törekszik, akkor annyi szálat indít a számításigényes feladatra, ahány szálat a processzor kezelni tud (ezt le tudja kérdezni). Ennél többet felesleges, úgysem tud egyszerre futni mind, ha kevesebbet futtat, akkor pedig nem használja ki a lehetőségeket. Nem a legjobb megoldás, ha a számítási feladatot N egyenlő részre osztja, ahol N a szálak (magok) száma, mert nincs beleszólása abba, hogy az oprendszer melyik programszálat melyik magon futtassa, ill. hogy melyik szál működését mennyi időre szakítsa meg, hogy közben más feladatokat futtasson, így egyforma magokból álló rendszeren sem fognak egyszerre befejeződni a részfeladatok. Célszerű a feladatot kisebb részekre bontani, és ha egy szál készen van az aktuális részfeladatával, akkor kéri a következőt, így kevés lesz az üresjárat, és lehetnek gyönge és erős magok is a rendszerben.
Amúgy a számításigényes feladatok sok esetben nem bonthatók úgy N részre, hogy a számítás kezdetétől a végéig nyugodtan dolgozik a szál, mert jellemző, hogy egy-egy rész számítási eredménytől függ a következő rész, ilyenkor meg kell várni az összes szálat, hogy elkészüljön a részfeladattal (azaz szinkronizálni kell a szálakat), és utána dolgozhatnak tovább a következő részen.
-
Robitrix
senior tag
Ennél sokkal bonyolultabb a dolog. egy programnak simán lehetnek olyan programágai, amelyek sok számítást igényelnek más párhuzamosan induló program ágak meg alkalmanként csak kisebb rész feladatokat oldanak meg. Egy átlagos program terhelése olyan, hogy van egy tipikus főága, ami összefog mindent és jórészt az dolgozik folymatosan. Ilyenek például a játék programok. Mondjuk van egy fő program ágam, ami jórészt végzi mondjuk egy személyes nézetű lövöldözös játékban viszi a játékos nézetét. Aztán a játék közbeni események mondjuk feltünik egy ellenség a játékos nézetében eki erre rátúzel egy rakéta vetővel. Ekkor mondjuk elindul egy párhuzamos programág, aminek dolga kiszámolni a lövés lefolyását, a találat jellegét és köftwekezményét. Közben a fő programágon folyhat tovább a játékos személyes tevékenysége. Aztán mondjuk a lővés eredményeként egy látványos találatban darabokra robban az ellenség. Lehet, hogy egy millió számítás elég a kiszámolásához a löövésnek és mivel nem fog folymatosan lőni a játékos így a lövász számoló párhuzamos programág csak időnként fog keveset számolni és elindulni. Mig a játékos mozgását és nézetét számoló fő programág szinte folymatosan fut ás számítások 1000 milliárdjait fogja elvégezni. Aztán mondjuk van egy párhuzamos programág, ami mondjuk a hálózatos kommunikációt kezeli. Az se fog azért megszakadni a folymatos terhelésben. Aztán lehet egy programág, ami a zenét kezeli. Aztán még egy, ami mondjuk a felhasználói interfészt kezeli. vagyis figyeli, hogy mit végez a játékos a egérrel, billentyűvel vagy kontrolleren. stb. Simán elképzelhető, hogíy egy játékprogram teljes számitási teljesitményét egyetlen program ág viszi akár 80-90%-ban. A mardék 10-20%.on osztozik a többi 5 legfeljebb egyszerre futó program ág. Így lesznek olyan pillanatok, mikor éppen 6 magot vagy szálat használ a program más pillanatokban csak 3-4 mag kell csak neki. Szóvel egy program számításainak szét osztása igen csak hullámzó és egyenlőtlen lehet a feladattól függően. Ráadásul egy játék programban igen csak sok a feltétles és a véletlenszerű események okozta feladatok. A játékos döntése, hogy feltünő ellenségre rátüzel egy rakéta vetővel és bummmmmm vagy rálő egy pisztollyal puk-puk vagy úgy dönt inkább elmenekül. És akkor nincsen lövés és nem indul egy találaot és következményét kiszámoló programág, mert nem történik meg a indulást kiváltó esemény. Egészen más jellegű feladat ahol mondjuk valami nagy mennyiségű adatot kell feldolgozni, és hasonló algoritmus fut a szétosztott adatokon. Ilyen lehet mondjuk egy tömörités, videó renderelés, titkosítás. De pont ezt látjuk egy cinebench futása közben. Ha 4 magom van akkor 4 kis négyzetben számolja a képet egyszerre, ha 64 mag 128 szálam van akkor meg 128 kis négyzetét számolja egyszerre a képnek. Ilyen programokban a párhuzamosan futó programágaknak nagyjából egyenletes a terhelése, hiszen ugyan azt az algoritmust futtatom nagyjából 4 vagy 128 példányban a hardvertől függően. De a programok döntő része távolról se ilyen ott különféle számítási igény jelentkezik a magokon és szálakon egy adott pillanatban. Vagyis a legtöbb programban ki lehetne használni az eltérő magok teljesítményét adott pillanatban. Már amennyiben a rendszer feladat ütemezője képes arra, hogy optimálisan képes legyen egymással összehozni a gyors magokat a a nagy számítási igényű programágakkkal és hogy azokról levegye az igéynt a kisebb számítási igényű programágakat a lassabb magokkal.
-
Robitrix
senior tag
Az, hogy a programozó hány párhuzamos programágat futtat az részben attól függ hány programágat készit fel egyáltalán párhuzamos futásra és a feladat jelege alapján egyáltalán melyik aza a program ág, ami logikailag futhat egy másik mellett. A dolgot gyakran a házépítéssel szokták példának hozni. Ott is vannak olyan folymatok, amelyek ok-okozati összefüggésben vannak egymással. Amig a ház beton alapját öntöm éppen addig nem rakhatom fel párhuzamosan a tetőcserepeket, mert nem hogy a tető váza sincsen még kész de még a falak se állnak. De mondjuk ha már áll a ház nagyjából akkor rakhatom a tetőre a cserepeket, miközben egy másik munkafolyamatban párhuzamosan szerelik bent a házban a villany és egy másik helysigben meg már rakják lefele a padlót. A tipikus számítógép program persze nem ilyen ott a részfeladatok közt ok-okozati összefüggés van. Egy rész folymat futása egy másik folymat eredményére épül vagy annak tevékenysége váltja ki. Korábbi példa alapján nem igen indithatok el egy lövés következmények kiszámolását végző program ágat addig, amig meg se történik még a lőves.
-
-
#106
nyunyu
félisten
Petykemano
#50
nyunyu
félisten
válasz
Petykemano
#50
üzenetére
A Xeon Phi célja x86 alapon egy olyan gyorsító megvalósítása volt, amilyen célra máskülönben mondjuk inkább GPU-kat használnak.
Xeon Phi az nem az Intel mindenkitmegverünk GPUja volt, ami mire megjelent volna, már rég elhúzott az Ati+nV páros, így inkább áttervezték x86 kompatibilisre, hogy némi marketinggel be tudjanak húzni némi zsét a supercomputing piacról az amúgy erősen bukta projektjükkel?
Hello IT! Have you tried turning it off and on again?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), 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?
).
Písz. 
Új hozzászólás Aktív témák
ph Miután az Intel bevezette az utasításkészletet a Tiger és Rocket Lake-ben, kivágja az utódnak szánt Alder Lake-ből.
- Nothing Phone 2a - semmi nem drága
- Ennyibe kerülnek a Huawei Pura modellek Európában
- Az NVIDIA szerint a partnereik prémium AI PC-ket kínálnak
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- Autós topik látogatók beszélgetős, offolós topikja
- Mindent megtudtunk az új Nokia 3210-ről
- Fűnyíró topik
- Milyen cserélhető objektíves gépet?
- Projektor topic
- Fotók, videók mobillal
- További aktív témák...
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- PROFESSZIONÁLIS Delid / Relid AMD Ryzen Processzorokhoz, garantált minőségben! (CSAK AM5!)
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest