Hirdetés

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

  • hobizsolti

    csendes tag

    válasz kvp777 #46 üzenetére

    kvp777 hozzászólása az egyetlen, amit ebből a fórumból meg lehet tartani.
    A cik írója sincsen tusztában szerintem azzal, ami leírt.
    Én programozó vagyok (.Net Framewok), és szerintem kvp777 is az, mivel Win API hívásokat, változó típusokat is ismer, nem csak játékokat.
    Érdekes, hogy a cikk írója azt mondja, hogy ha a programozó odafigyelnek, akkor gyorsabb lesz.
    Leginkább így néz ki az ilyen:
    Manager: jó a 64 bit?
    Programozó: igen
    Manager: tudnánk használni
    Programozó: igen
    Manager: mennyi idő?
    Programozó: sok, !!! két féle kódot kell írni, tesztelni, fenntartani, ismerni !!!
    Manager: és ha 32 bitest futtatunk 64 biten is
    Programozó: menni fog
    Manager: akkor legyen ez.

    Másrészt még a Java / .Net programokban sem elég a Java Virtual Machine és a Common Language Runtime átírása, és felrakás, hisz ha egy progit int32-vel írnak meg, akkor az 64 biten is int32 lesz, a futtató környezet nem dönthet másként, mert akkor esetleg bug-ot okot. Másrészt ha valami int32, akkor azért használják, mert a tárolt értékek beleférnek az int32 értéktartományba, tehát hiába is írná át int64-re.
    A legtöbb esetben semmi szükség int64-re. Kivétel multimédia esetleg, titkosítás, tömörítés, ahol esetleg bináris aggyal érdemes gondolkodni.
    Érdekes, hogy a cikk írója assembly-vel jön. Ki a fene ír abban programot. Amikor MFC, .Net, Java-ban feljlesztünk, akkor sehol sincs az assembly. Nem is foglalkozuk azzal, hogy hogyan van két szám összeadva. Különben minden fejleszés jó sokáig tartana. Nincs ki megfizeti.
    A gcc-s fejlesztésről nem tudok szólni semmit, se a linuxról.

    Játékot sem programoztam, de arra kíváncsi lennék, hogy a játékok fizikája mivel dolgozik. Int-ekkel, vagy lebegőpontos float, double értékekkel. Ha double-el, akkor ebben az esetben kit érdekel a 64 bites egész szám???
    A .Net framework 3.0-an bemutatkozott Windows Presentation Foundation sem pixel-ekben számol már, hanem device independent point-ban, és float értékekkel működik. Míg a Win32 API int, long értékeket használ. És a WPF ha jól tudok DirectX-et is tud használni. A 3D-s rendszerek rendszerint lebegőpontosan számolnak, mert egy számítás végén nem mindegy, hogy a kezdetekor az a változó 4,567 volt, vagy 4, vagy 5.
    Egy 4-re kerekített 4,567 érték 10-zel való szorzás után már elég nagy eltérést mutat, és szétesik a prezentációs képesség.

    Hát én sem értek még mindenhez igazán. Lehet egy csomó hülyeséget mondtam, de az biztos, hogy a cikk nem a valóságot festi. Messze vagyunk attól, hogy 64 bit-et optimalizáljunk, és lehet nem közelebb megyünk.

    Ami talán az ilyen optimalizációk helye lehetne az a fordítóprogramok. De az megint csak nem hozhat döntést int32 és int64 között. Ez még azt is jelentené, hogy a programozó nem csak a hardware-re kellene figyeljen, hanem még arra is, hogy milyen fordítóval dolgozik.

    TIsztelet a fórumtársaknak, én megértem, hogy egy felhasználónak, mint amilyen munkán kívül én is vagyunk nagyon nem számít, és magasról tesz a bitekre. Egy a mondat: ha már 64 bit, akkor legyen gyorsabb. És teljesen igaza van. Csak azt kel tudni, hogy nem úgy van, hogy optimalizáljuk, és kész.

    Példa: XML feldogozás, szöveg szerkesztés, adatbázius kommunikáció. Ki mondja meg, hogy ezek közben melyik regiszter mit csinál és milyen gépi kód megy, és hol vannak a prefix-ek. Ezt egy ember nem értheti meg, nem lehet, hogy tudja kezelni.
    A programozás modul felhasználásának és a rétegek szeparálásának mondana ellent. Sok függést okozna a rétegek között, és ami még biztosabb, hogy sok bug-ot hozna, és ezzel együtt még nehezebben debugolható kódot.

    Na ilyen a véleményem. Üdv mindenkinek. Legyen egy jó gépünk holnap is. :)

    Ja és Core2 6750-en ANGOL Vista x64 van.

    [ Szerkesztve ]

    Zsolt

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