2. Fórumok
  3. Videokártyák
  4. A GPGPU nem olyan könnyű a mobil piacon
Keresés

Új hozzászólás Aktív témák

  • #44 dezz nagyúr flugi #42
    Új Válasz #44
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dezz

    nagyúr

    válasz flugi #42 üzenetére

    Már látom, hogy már az elején félreértettelek. Azt hittem, hogy a GPU-nál nem foglalkoznak a sorrendiséggel és már eleve ez komoly gondot jelent.

    Viszont akkor semmi újat nem mondtál Abunak a #18-asban, hiszen ő is arról beszélt, hogy elméletben hogyan kellene lennie és ehhez képest a gyakorlatban nem úgy van.

    "Ez a hozzáállás alapvetően sérül a gyakorlatban, és ez nem a kerekítési probléma miatt van, hanem mert véges az ábrázolható kettedesjegyek száma."

    Ha már újra a #18-asnál jártam, erre is reagálnék: persze, hogy nem a kerekítés miatt van. Viszont éppen emiatt van szükség a kerekítésre, aminek a megvalósítása befolyásolja a kapott eredményt, ezért szükséges követni a szabványokat.

  • #43 flugi tag flugi #41
    Új Válasz #43
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    flugi

    tag

    válasz flugi #41 üzenetére

    a harmadik bekezdésből hiányzik az asszociativitás a kommutativitás mellől, természetesen beleértendő.

  • #40 dezz nagyúr flugi #33
    Új Válasz #40
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dezz

    nagyúr

    válasz flugi #33 üzenetére

    Ja, értem, szóval a CPU-k odafigyelnek erre. A GPU-k ugye in-orderesek, nem? Szóval, akkor az OpenCL nem figyel erre oda, vagy mi?

    Magam is belefutottam érdekes problémákba ezzel kapcsolatban, amikor annó (90's) átírtam pár kódomat (off-line renderelt grafikai effektek reklámfilmekhez) 68k CPU ASM-ről FPU-sra. Olyannyira számítottak a kerekítés eltérései, hogy egyes grafikus effekteknél meglepő módon jól láthatóan bezavart a végeredménybe és át kellett írni a kódot miatta.

  • #39 Sir Ny senior tag flugi #38
    Új Válasz #39
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Sir Ny

    senior tag

    válasz flugi #38 üzenetére

    a, b és c ismert, x az ismeretlen. Ennek három megoldása van a lebegőpontos számok körében.

  • #37 Sir Ny senior tag flugi #36
    Új Válasz #37
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Sir Ny

    senior tag

    válasz flugi #36 üzenetére

    ,,a példa értelmezése szerint az egyenletrendszernek egyetlen, két értékű megoldása van, az 1 és a -1 páros. Egyetlen pár, amiben két valós szám van. Egyetlen más pár sem megoldása az egyenletrendszernek. Nincs alternatíva."

    az a+b+c=x egyenletnek pedig három jó megoldása van, amelyből a programozó csak egyet kér, de azt rábízza a processzorra, hogy melyiket. (mert így gyorsabb)

    Az a baj, hogy túl buta vagy, vagy úgy csinálsz (trollkodsz) hogy lopkodd az én időmet. (azaz csak lopkodod az én időmet mindenféle értelem nélkül, nem tudom túl buta vagy-e, vagy ez szándékos). Én abbahagytam.

  • #34 Sir Ny senior tag flugi #32
    Új Válasz #34
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Sir Ny

    senior tag

    válasz flugi #32 üzenetére

    ,,A példád irreleváns. Az egyenletrendszernek van két megoldása valós számokon, ez két konkrét megoldás. "

    tetszőleges program tetszőlegesen kerekítve véges (illetve ami ennél fontosabb: előre meghatározható) számnyi különböző eredményt adhat, csak a szerencse dönti el, hogy melyiket.

    Az analógia nem irreleváns, de teljesen tökéletes.
    - Programozó - tanár
    - Több lehetséges jó eredménnyel járó feladatot kérnek
    - Elfogadnak egy jó megoldást
    - Mind a matematikában, mind a számítástechnikában nincs megszabva hogy hogyan kell eljutni addig

    => mind a matematikában mind a számítástechnikában a végrehajtó egységtől függ, hogy melyik eredményt adja
    - Mind Pistike, mind a GPU belső ütemezése rejtély, azaz tekinthetőek fekete doboznak, amely a tanár/programozó számára teljesen véletlenszerűen ad vissza egy eredményt a lehetséges jó eredmények közül

    => az égvilágon semmi különbség nincs a matematikával.ű

    ,,Schrödinger macskája annak köszönheti a népszerűségét, hogy furcsa, és sokan, köztük te is asszociatívan használják, vagyis "erről eszembe jutott" módon."

    Nocsak, de nagy mellénnyel van valaki. Ha nem tudsz szöveget értelmezni, minek ugatsz? Írtam, hogy az egész világ (klasszikus fizikai része) így működik, nem csak a matematika, hogy a lehetséges eredményekből kapsz egyet véletlenszerűen (ha van valahol számodra ismeretlen adat, akkor számodra véletlenszerűen) és írtam, hogy ha belevesszük a nemklasszikus fizikát, akkor is csak a lehetséges állapotok száma nő meg, és azok közül kapunk egy (tényleg)véletlenszerűt. (Azt hiszem hogy most a tér kvantált, de nem teljesen követem, hogy mikor melyik)

    ,,Abu azt mondta, hogy az baj, ha matekot végigszámolva hol 1, hol 0.999999 jön ki, és ilyen értelemben van több válasz ugyanarra a kérdésre."

    Igen, és ebben téved. Ez a példa meg különösen idióta, tekintve hogy 0,999=1, tehát ha van egy 3/3-as kifejezésed, akkor a számolásod módjától függően juthatsz el a 0,999, vagy az 1 alakig (bár megegyeznek úgyhogy lényegtelen).

    szerk:,,Ebből következően hiába igaz, hogy a matematikában az összeadás kommutatív, float és double számokra az ADD gépi utasítás nem az."

    A matematikában az összeadás kommutatív asszociatív? Nocsak? Én eddig azt hittem tetszőleges három fixhosszú lebegőpontos számot összeadva sorrendtől függő eredményt kapok :C

  • #31 dezz nagyúr flugi #26
    Új Válasz #31
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dezz

    nagyúr

    válasz flugi #26 üzenetére

    Nem vagyok benne biztos, hogy jól értem-e, amit mondani szeretnél.

  • #30 Sir Ny senior tag flugi #28
    Új Válasz #30
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Sir Ny

    senior tag

    válasz flugi #28 üzenetére

    ,,Schrödinger cicája pedig tartja az irreleváns tudományosnak szánt hivatkozások világrekordját, szoros versenyben a Gödel tétellel, és a relativitáselmélettel. Nem csoda, hogy itt is felbukkant :D"

    Öm. Nem. Schrödinger cicája az egyetlen olyan (gondolat)kísérlet ami egyrészt ölég népszerű, másrészt pedig a determinisztikussághó' van köze.

    ,,Ez a matematikában tényleg így van. Csak programozásban nem."

    Csak akkor, ha matematika = adott aritmetikai műveletek adott sorrendben való végrehajtása. BTW programozástól (programfutástól) is elvárhatnánk ugyanezt.
    De ha már a programfutást feladat-centrikussá tesszük, azaz megmondjuk a szegény processzornak hogy micsináljon, és pont leszarjuk hogy hogyan csinálja, (bízunk benne hogy jól majd meglepődünk, hogy nem), akkor a matematikától is el lehet várni ugyanezt.
    Például egy feladat: Pistike, itt van az egyenletrendszer, határozd meg egyetlen megoldását. Mondjuk: a=b és a*b=1. És Pistike csűri csavarja és az jön ki, hogy a=b=-1. Katinak meg a=b=1. És itt a hangsúly nem Pistikén van, vagy hogy rosszul számol: ha az a feladat, hogy valahogy határozza meg, és az a feladat, hogy egyetlen megoldást adjon meg a sokból, akkor akármelyik jó. Pont, mint a programozásnál, ott is az a processzor feladata, hogy adjon egy jó eredményt ahogy tud. Abu meg ha a matematikáhó' nem ért, ne szóljon belé.

    szerk: ha már aritmetika: ugye tudod, hogy a programfutás az az aritmetika és ezáltal a matematika része?

  • #25 dezz nagyúr flugi #18
    Új Válasz #25
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dezz

    nagyúr

    válasz flugi #18 üzenetére

    "a GPU atomikus művelete (amivel a párhuzamosan számolt részeredményeket összedolgozni érdemes) ütemezőfüggő sorrendben hajtódik végre, CPU programokban ez általában determinisztikus, hacsaknem több szálú, trükkös kódot csinál az ember."

    A komolyabb CPU-k jó ideje out-of-order végrehajtást használnak (feltéve, hogy nincs dependencia). Egy olyan kód, hogy pl.:
    a=b+c
    d=e+f
    g=a+d
    lehet, hogy így hajtódik végre:
    d=e+f
    a=b+c
    g=a+d

  • #19 polika senior tag flugi #18
    Új Válasz #19
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    polika

    senior tag

    válasz flugi #18 üzenetére

    A probléma amiről írsz akkor valós, ha a kerekítési pontosság közelében szeretnéd a végeredményed pontosságát megkapni. Ahogy írod, ez 1-2 műveletnél közel hozható, viszont kurvasok művelet kis hibája ténylegesen torzíthatja az eredményt, főleg ha a float számaidnál az ábrázolási pontosság határait feszegetik a különböző részösszegek (igen nagy ill igen kicsi számok kevert halmaza).

    A vicc ráadásul az egészben hogy a pontos kerekítés hiánya, vagy megléte nem érinti számotevően a kerekítési hibákat, bár kétségtelen hogy a tuncate vs kerekítésnél statisztikailag a truncate egy 2-esnyi deficitben van, de ez jóval 1 tizedesnyi alatt van. Tehát igazából a két módszer összevetésénél csak az a valós hogy nem egyformán produkálja a hibákat. DE hibás a cikknek azon ki nem mondott, konklúziója hogy ha minden hardver a matek szerint kerekítene, akkor az eredmények pontosan ugyanazt adnák, összevethetők lennének.

    Én eleve a hardveres kerekítést nem teljesen értem hogy miért van rá szükség ha ennyivel bonyolítja az áramköri elemeket ill tranzisztor számot?

    Mert ugyebár az ábrázolásból adódó részösszeg hibákon nem segíthetsz, a kerekítés az bármikor használva csak rontja a kapott értéked pontosságát, részösszegeket kerekíteni pl tök érelmetlen dolog, csak ott van értelme a kerekítésnek ahol emberek számára értelmezhető számmá szeretnénk alakítani az EREDMÉNYT, azaz kerekíteni csak a végeredménynél van értelme. Mind program futás, mind programozási értelemben a részösszegek kerekítése hülyeség (pontatlanabb, lassabb). Mert ha mondjuk van 23 bitnyi értékes információm akkor ha truncatelek, ha kerekítek csak 23 bitnél kisebb hasznos információ lesz ennek az eredménye, azaz értelmetlen. Ahhoz meg hogy legyen egy emberek számára készült végeredmény jellegű outputnál egy kerekített érték azt szoftveresen is simán lehetne kezelni, ugyanis grafikai problémában eleve nincs ilyen érték, GPGPU tipusú problémában ahol KURVASOK számítás van, ott meg pont jellemzően a végeredmény jellegű kerekített értékből van iszonyú kevés.

    Én teljesen megértenék egy olyan szavbányosítási verziót ahol a 32 bites pontosságnál a standard a truncate lenne (mobil/grafikára optimalizált alacsony tranzisztor szám, alacsony fogyasztás optimalizált standard), és a dupla pontosságú 64 bitet is tudó hardvernél lehetne csak követelmény a helyes kerekítés (GPGPU matematika, modellezésre használt hardver, ahol elsődleges kicsikarni minden lehetséges pontosságot).

Új hozzászólás Aktív témák

Hirdetés