Csak párhuzamosan programozni - na az még finomabb dolog (és inkább csak aprócska részletekre bontható feladatoknál villant a videókártya - játékok pixelei, videókonvertálás, renderelés, stb. - ahogy mondani szokták, a…
Csak párhuzamosan programozni - na az még finomabb dolog (és inkább csak aprócska részletekre bontható feladatoknál villant a videókártya - játékok pixelei, videókonvertálás, renderelés, stb. - ahogy mondani szokták, a "jól párhuzamosítható feladatok").
Ettõl függetlenül a tipikus hibákat nem szabad szubjektíven megítélni (melegebb felé kevésbé téved - milliónyi pontosító kérdés merül fel egyetlen kijelentés miatt).
Továbbá 256 bites számábrázolás jelenleg lehetetlen, de ez a processzoraink és tárolóink felépítésébõl adódik (már a decimális pontosság is hatalmas sebesség-visszaesést eredményezett tesztjeimben, mint a double pontosságú).
A fejlõdés ezen a területen szerintem marad állandó, kizárt, hogy ne legyen késõbb még finomabb felbontású globális léptékû modell, pontosabb eredményekkel és kevesebb hibával. Egyetemen furcsa volt olyan gráfelméleti tételt tanulni, amit épp a szomszéd épületbeli (ELTE) professzor bizonyított be nemrég, 2006-ban... Szóval a matematika nem ért véget még, és gondolom a pontosság és pontosítás terén sem.
Bár a videókártyákat átnevezhetjük "fizikai számlálóegység"-gé, még ha nem is ugyanaz, korrektebb...
Azért a párhuzamos programozás elég régi dolog, vannak látványos alkalmazásai is, pl a a legenda szerint a Terminátor 2-ben a T1000-es minden pixeljét egy-egy kb C64 képességû processzor számolta, ezért kaptak Oscart, már ha igaz a mese...
Nem egyszerû valóban a párhuzamos programozás, de nem is megoldhatatlan dolog, pláne egy ilyen horderejû kérdés esetén.
A 256 bites ábrázolással nincs semmi gond, a decimal pl 16 byte hosszú, ami pont 256 bit:
Link . ASM szinten "csak" össze kell fûzni 2-4 regisztert és kész...