- TCL LCD és LED TV-k
- Milyen billentyűzetet vegyek?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Soundbar, soundplate, hangprojektor
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Monitor hiba topik
- Azonnali VGA-s kérdések órája
- Mini-ITX
- Vezeték nélküli fülhallgatók
Hirdetés
-
A soknál is több pénzzel gyorsítaná fel a hazai chipszektort Kína
ph A China Integrated Circuit Industry nevű befektetési alap elsődlegesen a chipgyártáshoz szükséges berendezésekre fókuszálhat.
-
2024 - Alig egy nap múlva jön a Sony új State of Play előadása
gp Az előzetes tervek szerint több mint 30 perces lesz a műsor.
-
Poco M6 Plus néven újrázhat a Redmi Note 13R
ma A telefon feltűnt a HyperOS által támogatott készülékek listáján és a TÜV Rheinland is adott neki engedélyt.
Új hozzászólás Aktív témák
-
radi8tor
MODERÁTOR
Ez nekem kínai.
Hangolják össze jobban a drivereket a játékokkal.⭐ Stella
-
moli.hu
őstag
az elérhető gyorsulás nagyon függ az adott programkódtól, de a tapasztalatok azt mutatják, hogy két hetes munkával a kétszerestől kezdve akár a tízszeres gyorsulás is elérhető.
2 hetes munkaval?
-
con_di_B
tag
És erre mi szükség van az OpenCL mellett? Csak a reference cardot néztem át, de abban nem láttam semmit, amit abban ne lehetne.
-
vinibali
őstag
nagyon erősnek tűnik a kezdeményezés. kíváncsi leszek ha az FSA mellett teszi majd le voksát az új XBOX lesze-e még ennek létjogosultsága?
BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/
-
con_di_B
tag
LoL
Egy dologra egyébként jó lehet: meglévő C/C++/Fortran kódbázis HPC-sítésére. Viszont ha azok a kódok már eleve HPC-re vannak, akkor smemi szükségük ilyen megoldásokra, mert már eleve valamelyik natív környezetben lettek elosztott rendszerként lefejlesztve, ha meg most akarják átmókolni, akkor jobban járnának ha inkább újraírnák, csak még nem tudják.
[ Szerkesztve ]
-
flugi
tag
Amire ez hasonlít, az az MS AMP. Vagy a mi cuccunk: http://www.youtube.com/user/MrFlugi#p/a/u/0/31xKQ_9MN_k
Az a lényege, hogy ha a kódod olyan, hogy az algoritmus gyorsabban menne GPU-n, akkor a fordítóval elintézzük, hogy azon is fusson. Ez tényleg 2 heti meló.
Újraírni az algoritmust, hogy GPU barát legyen, az meg sok idő.
[ Szerkesztve ]
-
flugi
tag
majdnem pontosan így van, de szerencsére vannak magasszintű párhuzamosságot adó megoldások is, amiket könnyű lehet lecserélni. Például egy OpenMP alapú multithread megoldás triviálisan alakítható át az esetek zömében.
Egy socket szintű grid implementációt görgető rendszer meg nem fog tudni alkalmazkodni.
Nemrég dolgunk volt egy batárnagy fortran programmal. Nem kívánom senkinek.
-
siriq
őstag
Vegre valaki aki tapasztalabol beszel nem csak teoriak alapjan. Olyan konnyen leirnak az emberek mindent ugy, hogy kisem probaltak meg.
Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.
-
flugi
tag
furcsa módon, de igen, ha eleve alkalmas a kód. Ilyenkor a ciklusmag mérete irreleváns, a párhuzamosítási pont létezése a feltétel, és ilyen pontból kevésnek kell lennie, különben érdemi gyorsulás nem elérhető, tehát nem eleve alkalmas a kód.
Félreértés ne essék, eleve alkalmas kódból kevés van, de egy kellőképpen elegáns programban azért könnyebb találni gyorsítható részeket, mint egy asm betétekkel gazdagon díszített hackorgiát.
-
con_di_B
tag
Most csak egy szerencsétlen megfogalmazáson rágódsz. Az ő eszközükkel magának az "elemi forrásfájlnak" (magyarul amiből kernelt kéne fordítani) a hossza az ami nem igazán releváns, értelemszerűen, más jellegű kódkomplexitásra (pl. funkcionális) ez már nem igaz.
Nekem inkább az a problémám az elképzeléssel, hogy erre csak akkor lehet jó heurisztikákat mondani, hogy mit, hogy érdemes megírni/"lefordítani", ha már vannak helytálló best practices módszertanaink. Na ilyenek ma még nincsenek. Persze, rengeteg szép whitepaper volt/van, de a gyakorlatban minden ilyen elég könnyen be tud dőlni, elég egy driverfrissítés, amiben megoldanak valamit aminek eddig is gyorsnak illett volna lennie, csak eddig nem volt az... Vagy épp, hogy soha nem oldják meg...
-
flugi
tag
ha sok alkalmazást, sok komponenst akarsz felgyorsítani, az természetesen alkalmazásonként, komponensenként lesz 2 hét
Nem mellesleg nem akarsz h263 encodert optimalizálni, mivel szinte mindegyik tuningolt encoder függvénypointer tömbökben címezget, amit nem lehet megfogni pragmákkal.
A képnézegetőn nincs mit gyorsítani. Az effektek némelyikén lehet, hogy van mit. Ezek megvizsgálása, hogy lehet-e pragmázni, és rápróbálni a pragmákat, hogy gyorsabb lett-e, ez viszont megint a 2 hetes munkaidő alatt megvan mindenestül, persze effektenként (legyenek akárhány sorosak).
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen