- Samsung Galaxy Watch8 - Classic - Ultra 2025
- iPhone topik
- Xiaomi Watch 2 Pro - oké, Google, itt vagyunk mi is
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Fotók, videók mobillal
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy Z Flip5 - ami kint, az van bent
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Gyönyörű képeken csillog a Magic V Flip2
Hirdetés
Új hozzászólás Aktív témák
-
mzso
veterán
"Persze, lehet ilyet csinalni, csak azt nem latom, hogy mennyire eri meg, ugy ertem eleg kis resze lehet a usereknek akik amd apu + amd dvga komboval nyomulnak."
Tyúk/tojás. Ha az AMD egy pár egyébként konzol exklúzív fejlesztő alá tol egy kis pénzt, hogy ugyan már egyúttal portolják PC/mantle/hsa-ra is a kódot és megszaporodnak az ilyen címek akkor az AMD APU+VGA PC-k száma is megugorhat. Aztán vagy portolják DX-re is a fejlesztők vagy nem.
Én legalább is így járnék el az AMD helyében. (Amellett hogy jól összehaverkodnék a Valve-val a Steam Box ürügyén)
-
Zoli0726
aktív tag
Nem, egyelőre csak ő kritizál engem, egy olyan kódról ami rossz, bár sosem látta
Peak/peak nem jön ki? Kész, mivel minden kód pont ugyanazokat a műveleteket hajtja végre, mint a peak számolás, float összeadást + szorzást, ezért lehetetlen, hogy ennél jobb arányt kapjak.
Tény, hogy az opencl-es kód megkérdőjelezhetően optimális cpu-n, viszont semmiképp sem érzem úgy, hogy irreleváns dolgot mondtam volna, tekintve, hogy a linkelt algoritmusokban is volt 33x-os gyorsulás is.
Egyszerűen azok a feladatok a gpu-nak feküdtek, ha annyira, hát annyria. Ha baki lett volna benne, már rég észrevették volna, mivel amint mondtam, mi nem aknakeresőt írunk. Ezzel együtt nem kicsit nagyképűen azt állítod, hogy az velem együtt az összes munkatársam is béna, és te mennyivel jobb vagy csak azért, mert a gpu egy feladatban, aminek sem az elméletét sem az implementációját nem ismered, el tudott húzni ennyivel. Ezzel együtt leszarozod a computebench dolgozóit is, mert nekik 33x-os teljesítménytöbblet is kijött, amiben ha másfélszeres overhead van, még úgy is kijön amiről beszéltem.
Ezzel én ezt a latolgatást befejeztem, amint az látható úgy sem fogunk megegyezni.Azt, hogy nem láttál gpu-t egyáltalán nem neked szántam. Nem te írtad, hogy egy corei7-t sosem lehet gyorsabb mint egy kaveri. Az oda volt címezve, de ezt már mondtam egyébként is.
-
-
Zoli0726
aktív tag
Csak olvasok, írni nem írok, miféle hülyeség lenne már, hogy 2 work-item ugyanarra a helyre írja az eredményét. Természetesen az olvasás is úgy van megoldva, hogy eltoltan olvassák a work-itemek a tömböt, hogy ne legyen adathozzáférési probléma. Az eredmény elfér egy változóban is. Szinkronizálva nincs, de kb 0 az esélye, hogy ugyanabban az időben ugyanazt az adatot próbálná meg olvasni két work-item. Annyira azért nem gyakoriak az olvasások a sok számolás miatt. Ahhoz valakinek a 256 közül nagyon be kellene gyorsítani. Nem vizsgáltam ilyen szempontból a dolgokat, de ha 1-2 fennakadás még lenne memória olvasás miatt, annyit a szink is rontana.
Egyébként én nagyon úgy érzem, hogy elkanyarodtunk arról, hogy nem csak a cpu/gpu peak a lényeg, hanem az adathozzáférés, ami gpu esetében jobb. -
Zoli0726
aktív tag
Tényleg nem érted, de lehet, hogy én fogalmaztam érthetetlenül.
Vannak adataim, minden work-item-nek végig kell magát zongorázni rajtuk. Egyszerűen, csak annyit csinálok, hogy a globálisból a lokálisba másolom, és ott zongoráztatok, mivel belefér. Bekerülnek lokális tömbökbe. Tehát a teljes tömbön végig kell menni minden work-itemnek. Viszont ahhoz túl nagy, hogy minden work-itemnek odamásoljam a teljes tömböt, egy köztes megoldás az, hogy akkor a lokálisba másolom, bár közösködni kell, de onnan mégiscsak gyorsabb az elérés, mint a globálisból. A cpu kód meg természetesen nem akkor optimális mint a gpu, de senkit nem érdekel, mikor optimális az opencl kód cpu-n ha úgyis a gpu-n akarom futtatni. A feldolgozásnál ettől függetlenül nem befolyásolják egymást a work-itemek, így értem a függetlenséget, tehát nincs szükség szinkronizációra. Remélem így már világos. -
-
Zoli0726
aktív tag
Nagyon egyszerűen. Szinkronizációra nincs szükség, az adatok egymástól teljesen függetlenek. Ahogy az eredmények is. Lokális memóriát úgy használok, hogy az adatokat a globálisból a lokálisba másolom, és attól kezdve local id-val idexelek. Illetve a változók is lokális memórában tömbök, így függetlenül elérhetik őket a work itemek. Szerencsére belefértek a keretbe. Ez egy bevett szokás:
http://www.openclblog.com/2011/03/is-your-local-memory-really-local.html?m=1 -
mzso
veterán
Ez alól kivétel lehet az AMD pénzelt konzol port. Az lehet eredetileg közös mem címtérre optimalizált, meg eleve valami Mantle szerű API-ra készül.
Gondolom viszonylag egyszerűen, kevés energiával lehetne protolni desktop APU-kra és mantle API-ra (És opcionálisan a grafika részét dVGA-n (is) számítani). Ahhoz képest, hogy újra kéne írni az egészet Directx-re és csak CPU-n futó algoritmusokra. -
Zoli0726
aktív tag
Nem azt jelenti, hogy így össze kell szorozni, hanem azt, hogy valszeg nálam ennyit jelentett, de igazoltam is, mennyit jelent a lokális memória használata a fenti linkben, amiből az következik, hogy sokat, tehát elérhető Velük az a teljesítmény amiről itt szó van. Tehát nem minden a gpu peak/cpu peak. Azzal a CPU kóddal meg az égvilágon semmi baj nincs, hidd el ülnek még mellettem a munkahelyen olyanok, akik már akkor,programoztak, amikor én még csak a kallofdjutit ismertem a gépen, nem találtak benne kivetnivalót. Nem mentem át assembly-be optimalizálni,de logikailag korrektül volt felépítve, azóta meg ha csak lehet gpu-zunk. Inkább nekem kellene a te kódjaidat megnéni, ha számodra ezek az, eredmények Ennyire hihetetlenek. Persze nvidia openclben le van maradva mint a borravaló, a cuda meg király, de kevésbé gyors.
-
Zoli0726
aktív tag
Csak a te kedvedért:
https://compubench.com/compare.jsp?config_0=13875409&config_1=13503874
Egyébként te mint gpu programozó tudhatnád, hogy nem csak számítási teljesítményben erősek a gpuk, hanem az adat elérésében.
Ez is nagyons sokat jelent. Gpu\cpu 10x +adatelérés 2,5, meg is van, amit a fenti link is,igazol.
Nem is értem miért próbálod azt mondani, hogy csak a gpu számít, és mindegy lenne ha 7970 mellett ddr3 van. A memória sávszélességét és késleltetését vedd figyelembe.
De te egyébként mindent csak megcáfolsz, a saját szabadon kívül meg semmit nem tudsz alátámasztani. Mint mondtam, ha konkrétan alá tudod,támasztani, hogy amit mondtam kivitelezhetetlen, akkor hallgatlak, addig viszont a trollkodásodra nem figyelek tovább. -
Zoli0726
aktív tag
Azt bizonyítja, hogy az opencl-es megvalósítás nem volt jobb, mint a c, mégis gyorsabban lefutott a gpu-n, igazából a kódrész szinte teljesen megegyezett, valszeg az optimalizáció nem tud olyan jó lenni opencl-ben mint a g++ -Ofast.
Igazad van, apu-nál már majdnem ugyanaz a zero copy, mint az egységes címtér. Ettől függetlenül a bemenő buffert akkor is létre kell hozni, csak mutatókból fog állni.
Miféle normál feladat nem lesz ilyen mértékű gyorsulás? Nem értelek. Mi a csuda az, hogy normál feladat? És ki beszélt itt normál feladatról? Úgy hangzott mintha én egy aknakeresőn próbáltam volna ki? Nem ott. Arról, hogy más környezetben mekkora lesz a gyorsulás egy szót sem mondtam, viszont azt elismertem, hogy feladat válogatja és az függvény szinte gpu-ra lett kitalálva.
Sikerült egy jó gpu-s kódot írni, és még én vagyok a béna, biztos elrontottam valamit
, a 975/7750M elméleti teljesítménye, illetve a fentebb linkelt alogritmusok is azt bizonyítják, hogy igenis elérhető ilyen mértékű gyorsulás, ezek után vagy bizonyítsd be, hogy nem, nem érhető el, vagy akkor magadat minősítsd. -
Zoli0726
aktív tag
Nyilván mindenki szar, csak te vagy király, én meg abban lelem örömömet, hogy fórumokon összehazudozzak mindenfélét, meg szar c kódot írok. Nem birom az ilyet. Mint ahogy szerinted a zero copy = azonos címtér, másolgassad csak a mutatóidat és hivatkozzál a ramba a pci buszon keresztül, mikor még az is drámai gyorsulást hoz, ha nem a vramot, hanem a lokális memóriát használod.
Ugye tudod, hogy opencl-t cpu-n is lehet futtatni, gondolod nem próbáltam ki, de igen, kipróbáltam, és még rosszabb eredményt kaptam cpu-val. Egyébként sem az a proci volt, amit belinkeltem, hanem egy i7 975 extreme, de gondoltam, ha lúd hát legyen kövér. Erre te elosztottad a 72-t 3mal..., törődj bele, hogy más is lehet sikeres, nem csak te.
Egyébként meg naná hogy lehet 40+x-es gyorsulás, csak a 7750m helyére egy desktop gpu kerül. 7970-nel jóval több is. -
Zoli0726
aktív tag
[Link]
Aha, melyik algoritumsban is volt gyorsabb a core-i7 a szekvenciális kívül? Ja, hogy semelyikben
Az viszont tény, hogy az egy nagyon jól párhuzamosítható rész volt, 0 szinkronizálás, sok-sok szál.#216 Már megint ezzel jössz, fogd már fel, hogy nem csak az felhasználó, aki a gépe előtt a facebook-ot nézegeti. Az ilyen felhasználó nem fog belőle profitálni, ők a szuperszámítógépből, meg a cudá-ból meg a 64 bitből sem profitálnak, mégis megszülettek ezek a dolgok, és hasznosak és elterjedtek.
És már azt is leírtam 2 hozzászólással feljebb, hogy miért nem mindig jó a dvga, és lehet hatékonyabb egy huma-s apu
-
Zoli0726
aktív tag
"i7től szerintem a valós használatban sohasem lesz gyorsabb a Kaveri APUk bármelyike."
A személyes stílus erre vonatkozott.
A kaveri apu nagyobb számítási teljesítménnyel rendelkezik mint a leggyorsabb i7, ezt a programozó vagy kihasználja vagy nem, de ez már az ő sara.
Pont ez a hozzáállás ment anno a munkahelyemen. Sokrészecskés szimulációnál egy lépés tette ki a futási idő 95%-át. Futott is vagy 3 napig corei7 extreme-en. Én meg gondoltam egyet, és megírtam a függvényt opencl-ben, és a kis laptopomon elindítottam, láss csodát, 3 óra alatt megcsinálta. Ekkor mondta mindenki azt, hogy hoppá! Mégiscsak megérné kiszakadni a 10 éves programozási módszerek alól és valami újat tanulni.
Ezért érdemes akkor dobálózni az ilyesmivel, ha már kipróbálta valaki.
Nyilván mint minden, ez sem mindig jön be. Egyrészt vannak olyan esetek, amikor nem érdemes vele foglalkozni, pl word, total commander, nagyjából mindegy min fut, nem kell várakozni. Sok számolást igénylő dolgoknál viszont már fontosak ezek a dolgok, persze előfordul, hogy nem lehet párhuzamosításhoz nyúlni, de ilyenkor a készítők ezt már jól átgondolják, illetve a játék, ahol kritikus, hogy a képkocka időben a képernyőre kerüljön. Azért az is túlzás, hogy egyedül a bf használ ki négy magot
Ott Dirt3 stb, vagy grid2, far cry, cryengine, tomb raider, asassins creed, metro. Az meg hogy van egy skyrim aminek őskori motorja van felcicomázva, vagy egy cod, ami őskori grafikát vonultat fel crysis3 gépigénnyel már nem az apu hibája. -
sad_Vamp
őstag
i7től szerintem a valós használatban sohasem lesz gyorsabb a Kaveri APUk bármelyike. Másrészt az AMD dGPU-k nagy része is már GCN-es.... szóval az intel+AMD-s konfigok sem maradnának kakában ha netán über revolúció készülne (de nem fog, mert az intel ezt tűzzel (azaz pénzel) vassal akadályozni fogja).
-
sad_Vamp
őstag
Sokkal jobb nem lesz.... talán 5-20%okról lehet beszélgetni többről biztosan nem szeritnem. De azért ne mond azt, hogy nem különbség az, hogy régi motort pofozzák hozzá a nextgenhez, vagy eleve úgy írják meg a motrot hogy lehető legjobban fusson nextgenen. Ez utóbbiak lehetnek(nem lesznek, csak esetleg lehetnek) gyorsabbak apukon dVGAval, mint sima procikon... ezt szerettem volna mondani.
-
Sinesol
veterán
Nincs itt bukfenc,nem is szamit a cpu mivel inkabb hsa apu kell /nem a grafika miatt az igp hanem szamolni cpu helyett/
Kaveriben a gpgpu besegit nextgen alatt i7be meg mezei x86 van buta igp-vel, persze ez csak nextgen alatt igaz, ott a jelenlegi i7 egy idöjarasszimulació, fizika, vagy fejlett ai szamolasa mellett meghalna, a kaveri viszont a fejlett architectura miatt gpgpuval nevetve megoldaná...de még nem tartunk itt hiaba adott a technika...de a jövö mindenkeppen, az intel is erre fejleszt... -
Sinesol
veterán
Hat ha lennének igazi nextgen cimek akkor pedig ez lenne a helyzet, a kaveri+r9 erösebb joval mint egy i7+r9. Igazabol Egy jol megirt cim mellett az i7 köpni-nyelni nem tudna, a kaveri igp resze megalázná az i7et, lehet el se indulna i7 mellett annyira keves lenne teljesitmenyben egy nextgen cim alatt.
Mas kerdes hogy az intel arra jatszik hogy ilyesmi ne fordulhasson elő, ezert nincsenek programok gamek stb és ne is legyenek amig nincs inteles alternativa....
Fejlödes szempontjabol ez nem tul jo hiszen van egy top technologia de parlagon hever....masreszt viszont jo mer vga csere elég egy upphoz cput meg evek ota nem kell cserelni XD
Mindketten írtok egy példaprogramot a másiknak meg át kellene gyúrni, hogy gyorsabb legyen. Vagy mittomén, nem értek a lovakhoz 
, a 975/7750M elméleti teljesítménye, illetve a fentebb linkelt alogritmusok is azt bizonyítják, hogy igenis elérhető ilyen mértékű gyorsulás, ezek után vagy bizonyítsd be, hogy nem, nem érhető el, vagy akkor magadat minősítsd. 
Új hozzászólás Aktív témák
Hirdetés
- Bomba ár! Lenovo ThinkPad L390 - i7-8GEN I 16GB I 512SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- HIBÁTLAN iPhone 13 Pro 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3023, 90% Akkumulátor
- GYÖNYÖRŰ iPhone 12 mini 64GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS2955
- Samsung Galaxy Book2 Pro 360 i7-1260P 16GB 512GB OLED touchscreen, GARANCIA: 1ÉV
- Eladó Új állapotban lévő Xiaomi Redmi 13C 4/128GB / 12 hó jótállás
Állásajánlatok
Cég: FOTC
Város: Budapest