Új hozzászólás Aktív témák
-
#113
hobizsolti
csendes tag
ddekany
#111
hobizsolti
csendes tag
ha jól tudom, akkor a vista is csak 2GB-ot rendel a processzeknek az address space-ből.
Ezért is van az, hogy a Crysis kéri a patch-et vista alá, ami engedélyezi, hogy több address space-t kapjon.
Win32 ugye 4 gb-ot kezel. ebből 2gb van a processznek, 2 gb-ot fenntart az oprendszer magának (talán pontosab kernelt mondani, nem vagyok biztos benne.)
Ez is érdekes, mert ha igazam van (én 80%-ot adnék rá), akkor érdekes XP-s gépbe 2-nél több ramot rakni, persze megjegyezve, hogy azért a 2-ből ugye a többi futó progi is fogyaszt, de akkor mondjuk legyen 3G, és akkor tfh marad 2,5G szabad, ezt nem tudja kihasználni egy progi sem. Feltéve ha nem több processzes, és inter process kommunikál (IPC hívások - sosem csináltam) - amúg Windows-ban van COM, ami egy olyan technológia, ami ha jól tudom RPC-vel működik, távoli eljárás hívás, persze helyben is megy - ehhez sem értek igazán, csakennyit tudok. -
#112
hobizsolti
csendes tag
#95904256
#105
hobizsolti
csendes tag
válasz
#95904256
#105
üzenetére
csak arra gondolta, hogy a cikk nem említ semmit sem azzal kapcsolatban, hogy mi a helyzet a lebegőpontos számításokkal kapcsolatban. Én sem tudom, azért lennék kíváncsi.
Csak az egész számokat említi.
Arra gondolta, hogy a proc eddig is tudod "szélesen számolni" tehát 32bit -> 64 bit talán nem befolyásolja a lebegőpontos számítást?Annyira nem értek a pontos proc működéshez, csak azt tudom, hogy mindig 80 biten számol, csak ha nem használod az bővített módot, akkor levág, kerekít.
-
#96
hobizsolti
csendes tag
pok.tom
#74
hobizsolti
csendes tag
ELnézést, senkit nem akarok lenézni.
Egy valamit emelnék ki:
Nem úgy van az, hogy majd a programozó optimalizál, nem ennyire egyszerű
És még egyet:
A végfelhasználónál senkit nem érdekel, hogy ki optimalizál, legyen gyorsabb és kész.Egyetértek veletek abban, hogy ez nem programozóknak készült. Ezzel így van jól. De ha így van, akkor ne a programozói optimalizálásra vetítsük a problémát. Akkor tudjuk, hogy az hogyan zajlik, hogy x64-re fejlesztünk. És szerintem ehhez nincsen lövése se a cikk írójának.
-
#95
hobizsolti
csendes tag
Tibord
#94
hobizsolti
csendes tag
Az vesse rám az első követ, aki beszámol arról, hogy ő, haverja, ismerőse hogyan optimalizált végig egy teljes alkalmazást 64bitre. De nem egy kis alkalmazást, azzal úgyse kapsz akkor teljesítmény többletet. kit érdekel, hogy 2mp alatt csinálja meg, vagy 2,1 mp alatt. Egy nagy alkalmazás optimalizálásáról szeretnék hallani.
Extrém esetet eltekintve: 3D, game, ...
És még mindig nem szólt senki sem a lebegőpontos számokról.
float: 4 bájt
double: 8 bájt
a processzorok a pontosság miatt 10 bájton számolnak, csak a végén visszaveszik az eredményt 4 vagy 8 bájtra. hol van itt a 8 bájtos egész?szerintem csak a memória éri meg jelenleg.
nincs szükség az esetek 95%-ban (szvsz) a 2^64 értéktartományra. -
#71
hobizsolti
csendes tag
kvp777
#46
hobizsolti
csendes tag
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.
Új hozzászólás Aktív témák
Hirdetés
- 123 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- Bomba ár! Dell Latitude E6400 - Intel P8400 I 3GB I 160GB I 14,1" I Intel VGA I Garancia!
- Asus ROG G20AJ - Intel Core i7-4790, GTX 980
- Xiaomi Redmi Note 12 128GB Kártyafüggetlen 1Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest