- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen notebookot vegyek?
- Azonnali informatikai kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Audiokultúra - Hi-Fi-ről hifisen
- E-book olvasók
- Magyarországra is megérkezik az LG új okosmonitora
- Samsung LCD és LED TV-k
- AMD vs. INTEL vs. NVIDIA
- Azonnali alaplapos kérdések órája
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Saját Redmi Note 13 Pro+ a világbajnok focicsapatnak (és indiai rajongóiknak)
ma Argentína nemzeti válogatottjának mezével díszítik az új Redmi különkiadást.
-
Premier előzetesen a Gray Zone Warfare
gp A mai naptól hivatalosan is elrajtol a játék korai kiadása PC-n.
Új hozzászólás Aktív témák
-
atti_2010
nagyúr
Miert, annak lesz koze a jatekok 95%-ahoz
A legtöbb játék a BF4 motorjára fog épülni és jó pár kiadó érdeklődik a Mantle iránt.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
RyanGiggs
őstag
Értelek, csak az a baj, hogy a jóval olcsóbb meg sokkal lassabb lesz, mint a csúcs! Letiltanak benne még ezt-azt...Petit. És akkor már tényleg nem sok mindenre lesz elég a teljesítménye.
-
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[ Szerkesztve ]
-
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...[ Szerkesztve ]
-
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.
[ Szerkesztve ]
“When the flaws of the system are exposed, it is usually the irritant who gets cast out.”
-
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).
“When the flaws of the system are exposed, it is usually the irritant who gets cast out.”
-
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. -
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[ Szerkesztve ]
-
pakriksz
őstag
akkor a jelszótörők is szarul vannak megírva, bár cpu családokra külön külön van optimalizálva, de még is 40x gyorsabb egy középkat gpu-n
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
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
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
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.[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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
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 -
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
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.[ Szerkesztve ]
-
Thrawn
félisten
Nem akartok házi programozóversenyt indítani egymás között pl itt a Logouton? Nem viccből írom, vérkomolyan gondolom Mindketten írtok egy példaprogramot a másiknak meg át kellene gyúrni, hogy gyorsabb legyen. Vagy mittomén, nem értek a lovakhoz
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
Thrawn
félisten
Csak azért említettem ezt, mert bár kultúráltan, de jól elvitatkoztok a másik programozási képességein, holott erről ugye semmit nem tudtok. Vagy tévednék?
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
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.
[ Szerkesztve ]
-
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)
Új hozzászólás Aktív témák
- Elektromos rásegítésű kerékpárok
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- EA Sports WRC '23
- Milyen notebookot vegyek?
- Kínai, és egyéb olcsó órák topikja
- Napelem
- Azonnali informatikai kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Audiokultúra - Hi-Fi-ről hifisen
- További aktív témák...