- Milyen billentyűzetet vegyek?
- Házimozi belépő szinten
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen széket vegyek?
- Kormányok / autós szimulátorok topikja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Tálaljuk a februári hardverlevest
- Milyen belső merevlemezt vegyek?
- iPad topik
Új hozzászólás Aktív témák
-
#171
mexicanraven
senior tag
mexicanraven
senior tag
Hali mindenkinek!
Most építem az új gépet, minden alkatrészem megvan! Viszont figyelmes lettem valamire, ui ez állt az Intel E5200-as procim dobozán:
Intel 64 Architecture for 64-bit Computing
Ez tkp mit jelent? Én úgy tudtam, hogyha 64 bites rendszert szeretnék, ahhoz olyan lap+proci+oprendszer kell! Akkor ez hogy is van? -
gefffry
aktív tag
Én anno használtam 4 giga rammal vista x64-et, pattant minden nem lehetett rá semmi panaszom, után kivettem belőle 2 giga ramot, és érezhetően belassult minden.
gondolok itt vista betöltésre, program indításra.Tom nem egy nagy "teszt jellegű" próba volt, de sztem 64 bites op rendszert csak 4+giga ram melleté rdemes felrakni. Egyébként 1-2 progitól eltekintve a 32 bites progok is jól mentek 64 biten.
-
#168
#54715584
törölt tag
csabyka666
#161
#54715584
törölt tag
válasz
csabyka666
#161
üzenetére
nekem hasonlo a konfig, tokeletesen fut xp64 alatt full beallitasokkal
-
#166
greatchaos
addikt
greatchaos
addikt
számomra igen nagy csalódás volt az +32bit előnye... és az is, hogy már sok éve ezt reklámozzák, hogy milyen faja...
-
#165
csabyka666
veterán
radírfej
#164
-
#164
radírfej
senior tag
csabyka666
#161
radírfej
senior tag
válasz
csabyka666
#161
üzenetére
nálad nem a 64 bites oprendszer hiányzik, hanem a 3000plusz kevés... ki lehetne facsarni még néhány fps-t egy erősebb procival.
-
#163
csabyka666
veterán
fLeSs
#162
-
#162
fLeSs
nagyúr
csabyka666
#161
fLeSs
nagyúr
válasz
csabyka666
#161
üzenetére
Nem túl vszínű, esetleg ha van 64 bites verziója is, akkor talán, de akkor sem számottevően.
-
#161
csabyka666
veterán
Hali!
3000+-os Athlon 64-em van. Most 32 bites xp-t használok. Adott egy játék: CoD4. Véleményem szerint jobban kéne futnia a konfigomon (GF7900gt, 2 giga ddr400, Athlon64 3000+). Szerintetek jobban pörögne 64 bites win-en, vagy felesleges vele szórakoznom...
Köszi! -
-
ddekany
veterán
"te el sem tudnad kepzelni, hogy milyen regi forditoval dolgozok nap mint nap (nem dzsunka ceg), ami a procinak milyen regi uzemmodjara gneral kodot..."
Hát... ami olyan ősi, futhatna szoftveres emulátoron is, végül is pl. egy DOS-os időkböl megmaradt csodához csak jó az a sebesség is... Lásd C64 programok PC-n.
És persze itt most PC-kröl van szó, nem vmi mainframe-ekről (EBCDIC baby! ). -
ddekany
veterán
"gondolj bele pl. abba, hogy egy 3000 fős direktmarketing call center számára szerzel be PC infrastruktúrát. a jól ismert, kezelhető problémákkal rendelkező WinXP-t választod, vagy valami újat"
A x86-os és a ValamilyenMásVasraKészült XP közt nem olyan nagy a különbség. Kevesebb, mint pl. az XP és a Vista közt van. Igen, Vista-t is kerülik nagyobb cégeknél egyenlőre, de hát előbb utóbb az lesz a szokványos, és akkor a 3000 fős call centerben is az lesz. Szóval megy ez... szerintem túl drámainak gondolnak egyesek egy ISA (és társai...) váltást.
-
ddekany
veterán
válasz
Dare2Live
#150
üzenetére
"ismerek jópár pldt hardver/sw független VMes dologot, hogy a legismertebbet mondjam ott a mindent kihoztak/nak amit csak lehet a Javabol azerus. Tessék összelőni méretben/memo foglalásban/cpu terhelésben egy utorrentel."
Épp épp azt mondtam, hogy újra kell fordítani a programot, tehát natív lesz, nem lesz lassabb. A VM-es dolgot zárójelben jegyeztem meg... a Java-t pl. én sem erőltetném desktopon, és akkor én még elsősorban egy Java-s ember vagyok. A Java maradjon egyenlőre a szervereken, szerintem...
-
zlutor
aktív tag
-
ez mind igaz, csak az utolsó lépés maradt ki a sztoriból - a felhasználók változtatási / kockázatvállalási hajlamától való félelem. ami egyébként nagyrészt jogos is, és sokban pont az IT ipar felelős érte, tehát szépen a saját farkukba haraptak
gondolj bele pl. abba, hogy egy 3000 fős direktmarketing call center számára szerzel be PC infrastruktúrát. a jól ismert, kezelhető problémákkal rendelkező WinXP-t választod, vagy valami újat, ahol egy általános hiba (akárcsak telepítési hiba) miatt 3000 ember órákig malmozik, és percenként repülnek ki a dollárezrek az ablakon?
-
zlutor
aktív tag
te el sem tudnad kepzelni, hogy milyen regi forditoval dolgozok nap mint nap (nem dzsunka ceg), ami a procinak milyen regi uzemmodjara gneral kodot... Es hogy mennyi es mekkora erteku sw/HW kombo van szanaszet a vilagban, amire ez fel fog kerulni - es elore lethatolag min. 10 meg evig fel is fog kerulni...
Szoval, csak annyit akarok mondani, hogy a Windows igazandibol csak egy dolog - talan nem is a legnagyobb erteket kepviselo - ebben a jatekban.
Arrol ne is beszeljunk, hogy mi van azokkal a progikkal amit X eve megirtak, bevezettek komoly helyekre - ahol nem ugy megy am, hogy rosszul alszunk es kidobunk vasat, szoftvert csak mert az MS kidobott valami uj szart -, mukodik jol, megtanulta hasznalni X ezer ember, es a forraskod (es vele a keszito ceg) lehet, hogy mar nincs is...
Szoval, ha kijonne valami uj, ami nem kompatibilis a regivel, annak igen nagy valoszinuseggel rovid vege lenne...
-
Dare2Live
félisten
ismerek jópár pldt hardver/sw független VMes dologot, hogy a legismertebbet mondjam ott a mindent kihoztak/nak amit csak lehet a Javabol azerus. Tessék összelőni méretben/memo foglalásban/cpu terhelésben egy utorrentel.
Minek átérni más alapra ha az nem gyorsulást hanem durva lssulást hoz?
-
LordX
veterán
Az Itanium nem azért bukás, mert jött az AMD 64, hanem mert superskalár helyett VLIW (bocsánat, EPIC) architektúrát csináltak bele. És a VLIW mint kiderült, nem a legjobb megoldás a teljesítmény növelésére.. Saját magával nem kompatíbilis (új processzor verszió, és fordíthatsz mindent újra), és gyakorlatilag lehetetlen teljesen kitölteni az utasításokat.
-
ddekany
veterán
Szerintem viszont műszaki szemmel értelme nincs sok... Ugyanis, ha van Windows, meg driver, meg ilyen-olyan compiler IA-64-re (vagy akármilyen új hardver-platformra), akkor már nem nagy ügy kiadni rá az alkalmazásokat (Office, Photoshop, Half-life, akármi), hiszen ugyan azokat az API-kat használhatják, csak az ISA más, de az meg kit érdekel, megoldja a C++/Pascal/akármi fordító. Jó, igaz, kétféle változat kell mindenből a "boltok polcaira", de ez lényegében már disztribúciós gond (és mivel van Internet, egyre kevésbé), nem műszaki. Persze az egyik nagy "ha" itt az, hogy legyen az új vasra Windows... viszont ezen pont nem tud segíteni az x86 emuláció. A másik nagy ha a driverek megléte, de ha más az I/O (és persze, hogy más), akkor drivereknél sem segít az x86 emuláció. Szóval, itt talán a "mainstream" desktop szoftverfejlesztői kultúrával van a gond, hogy egyszerűen nincs benne a világképükben, hogy Az Egyetlen Szent x86-on kívül más is van. Mert már egy ideje nincs is. Ördögi kör...
-
ddekany
veterán
Én meg ott (is) látnák menekülési lehetőséget, ha a hardver független alkalmazásfejlesztés fokozatosan mindennapos dologgá válna. Mert ha kb ugyan az az OS és pont ugyanazok az alkalmazások rendelkezésre állnak a régi és az új platformon is, akkor már nem nagy ügy egy drasztikus ISA váltás sem. Végül is a kód túlnyomó többségét csak újra kell fordítattni, és kész, szóval nem nagy ügy (vagy alkalmazások esetén, ha vmi Java-szerűségben íródik, újrafordítani sem kell). A legmunkásabb az OS portolása a másik hardverre, na meg a driver-eké, de pl. van többféle platformra "Linux" is, stb, szóval látszik, hogy ez gyakorlatban is igenis lehetséges, nincs valódi technikai akadály. De hát az üzleti kicsinyesség, ugye...
-
-
#141
Cs(|)be
tag
NagyMesterB
#136
Cs(|)be
tag
válasz
NagyMesterB
#136
üzenetére
Miután összeraktuk a gépet, gyorsan indítottam csak egy rendert.. csak úgy, nem foglalkoztam vele mi mekkora, meg milyen durva. Azért elég powwa a teljesítmény.
-
zlutor
aktív tag
Az a kompatibilitas nagyon nagy dolog am! Senki sem hagy(hat)ja veszni a jelenelgi vevokort...
Esetleg olyan tortenhet, hogy 2in1 proci keszul, ami tudja regi uzemmodot, de mellette bevezeti az ujat. Ja, es a ket uzemmodot nem engedi keverni...
Ezek utan, hosszu, hosszu idovel kikopha a korabbi megoldas...
-
ddekany
veterán
válasz
#95904256
#137
üzenetére
Ki tudja... de ha nem, akkor ahhoz valami nagyon durva adatfeldolgozó képességnek is kell járulnia, különben nincs értelme pl. sejt és neurális háló szinten letárolni a szörnyeket a Doom XXVI-ben.
Engem amúgy főleg az érdekelne, hogy valaha lesznek-e még nagy váltások (pl. rendes ISA váltás), vagy most már örökre beleragadt ebbe a kompatibilitás miatti végtelenségig menő toldozás-foltozásba a mainstream számítástechnika. Az Intel megpróblta otthagyni az x86-ot (Itanium), de hát az AMD elrontotta a 64 bites csodájával... (Persze lehet, hogy ennek csak örülhetünk... ki tudja.)
-
DuplaZso
aktív tag
Csatlakozom azokhoz, akik majd csak akkor fognak 64 bitre váltani, amikor az _általánosan_ használt programok (ebben azért a játékok is benne vannak) igénylik majd a 3GB-nál nagyobb rendszermemóriát. Addig csak parasztvakítás az egész, ugyanúgy, mint az AMD-reklám.
-
ddekany
veterán
Jé... OK, igazad van, ezt (Address Windowing Extensions-t) nem ismertem. Viszont ahhoz, hogy ezt kihasználja egy alkalmazás, a készítőinek kell "kézileg" megoldani a lapozgatást, szóval elég kínos (ellenben a 64 bites program esetén, ahol semmi ilyen plusz programozói munka nincs). Retro feeling... tiszta DOS EMS (csak ott még az 1M átlépése volt a gond)!
-
ddekany
veterán
"Windows esetén már rég túlnőttük a 32 bites limit(ek)et, csak nem szembetűnő."
Olyan szemponból nem, hogy egy alkalamzás tuti hogy nem tud lefoglalni megának pl. 5G memóriát. (Azt hiszem XP esetén valójában max 2G-t tud, de ez most minegy, a kemény elvi határ a 4G minusz kernel (és minusz videómemória és hasonló aprólék, ami még esetleg ugyanbban a címtérben akar fetrengeni)).
-
no ismét tanultam valamit
első ránézésre elég buták ezek a limitek (lehet, van mélyebb okuk), de én a process virtual address space-en túl egyedül a system cache-t látom problémásnak (meg is lepődtem, hogy XP alatt 860MB-ra van korlátozva). A pool paged / non-paged limitek azért elég bőségesnek tűnnek még most is (különösen a non-paged). -
ddekany
veterán
-
P.H.
senior tag
Windows esetén már rég túlnőttük a 32 bites limit(ek)et, csak nem szembetűnő.
Először is, amiről beszélünk (pl. innen; az első kettő a Feladatkezelő megfelelő oszlopainak kiválasztásával követhető):
Pool Nonpaged Bytes: these represent allocations directed to the nonpaged pool, which is a set virtual memory pages that always remain resident in RAM. (These are nonpageable bytes.) Device drivers and the OS use the nonpaged pool to store data structures that must stay in physical memory and can never be paged out to disk. (For example, the TCP/IP driver must allocate some amount of nonpaged memory for every TCP/IP connection that is active on the computer for data structures that are required during processing of network adaptor interrupts when page faults cannot be tolerated.)
Pool Paged Resident Bytes: Most virtual memory pages that are acquired in the Operating System range of virtual addresses can be paged out. The Pool Paged Resident Bytes represent memory locations from the pageable pool that currently reside in RAM.
System Cache Resident Bytes: the system’s file cache occupies a reserved range of virtual memory addresses, some of which may currently reside in RAM. (Cached file segments can also be non-resident, in which case they must be fetched from disk when they are referenced by executing processes.) System Cache Resident Bytes represents segments of the file cache that are currently resident in RAM.
32 és 64 bites Windows XP összehasonlítása e tekintetben [link] 2. pont alatti táblázat utolsó három sora.
A Windows-verziók teljes összehasonlítása e téren: [link]
Ez magyarázat a Vista sokkal nagyobb (és az XP x64 néha megugró) memóriahasználatára, illetve a x64-es Windows-ok 'látszólagos' gyorsulására.
-
ahogy elnézem, komoly igény a 64 bites OS-ekre rövid távon csak a memória-korlát miatt van, az viszont itt van a nyakunkon, 1 éven belül égető probléma lesz - már most több szoftvernek fáj a hasa a 2GB-os address space limittől.
azért nagyon jó ez a cikk, mert megmutatja, hogy a 64-bites Vista már elég jó érettségi szinten van (legalábbis ha a 32-bitessel hasonlítjuk össze
![;]](//cdn.rios.hu/dl/s/v1.gif)
), amikor kitör az "átállási kényszer", akkor nem lesz dráma, lesz hová váltani. -
lenox
veterán
Amugy Pentium Pro ota fel van talalva a PAE (Physical Address Extension), amivel 64 GB memoriat lehet cimezni 32 bites oprendszerrel (tehat 36 bitet lehet a cimhez hasznalni). Van FreeBSD, Linux, Solaris, Windows support. Kicsit maceras, de van. Mondjuk pont xp-n limitalva van 4 GB-ra (szal szart sem er), de pl. 2003 Server az oke.
-
Dr. Akula
félisten
Sztem ami tényleg gyorsít (illetve a lassulásokat csökkenti) az a RAID0 C:\ meghajtónak. Lehetne is teszt RAID vinyókról, pl. mennyivel gyorsabb RAID0 mint a RAID5, 2 vs 4 vinyós RAID0,ilyesmik. Most hogy így lement a vinyók ára, és szinte minden alaplapon van RAID vezérlő, aktuális lenne.
-
#95904256
törölt tag
A felvetés amire reagáltam ez volt:
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
Az általános célú regiszterek nem lebegőpontosak.
Ezért nem említettem őket.Persze a lebegőpontos számok címszámításnál lehet számolni velük, de kétlem hogy az ebben rejlő lehetőségre gondoltál...
-
#115
#95904256
törölt tag
hobizsolti
#112
#95904256
törölt tag
válasz
hobizsolti
#112
üzenetére
A lebegőpontos számításokat eddig is tudott az FPU 32/64/80 biten. A 64 bites üzemmód az SSE/SSE2 (32/64bit) alatt hoz annyiban újat hogy most nem nyolc hanem tizenhat regiszterrel gazdálkodhat a programozó. Ez sacc-per-kábé 0-20% teljesítmény növekményt hozhat a lebegőpontos számításoknál. Persze ha kihasználják...
Az FPU valóban 80 bites számolásra képes, de nem mindig számol annyin. Pl. egyik látványos dolog a viszonylag hosszú ideig tartó osztás. A 80 bites eredmény előállításához a K8-as magnak 24 órajel kell, de egyszeres illetve dupla pontosságnál 16 illetve 20 órajel is elég. Ha mindhárom esetben 80 biten számolna, majd vágna, akkor mindig 24 órajel után lenne eredmény.
Sőt, ha az SSE/SSE2/FPU gyökvonásokat hasonlítod össze (32/64/80 bit), akkor még látványosabb ez az időbeli különbség.
-
#114
ddekany
veterán
hobizsolti
#112
ddekany
veterán
válasz
hobizsolti
#112
üzenetére
A lebegőpontos számításhoz külön 80 bits regiszterek vannak (x86-nál... pontosabban x87-nél, de most mindegy) mióta csak megjelent. Ez független az általános célú regiszerek méretétöl. (Jó, mondjuk átmenetileg lehetnek a lebegőpontos számok általános célú regiszterekben, és akkor most már a 64 bites lebegőpontos számokhoz nem kell két regiszter...)
-
#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.
-
ddekany
veterán
Nem vettem részt egy játékmotor fejlesztésében sem, de nagyon valószínűnek tartom, hogy a forráskód 99% úgy maradhat ahogy van (csak persze újra kell fordítani (nem programozóknak mondom: a újrafordítás az semmi extra, egy mindennapos dolog, egy gombnyomás)).
Az egész 64 bites mizéria lényege a megcímezhető memória mérete, főleg az egy alkalmazás által megcímezhetőé. Szóval épp itt az ideje... nincs messze, hogy 3-4G vagy több kelljen pl. egy játéknak.
Azért a régi AMD-s reklámfilmért meg köszönet a PH!-soknak. Majd jól seggberúgja őket érte a szponzor, ha az AMD köztük van...
Na szóval, ilyen ez. Hazudnak bele az ember arcába. -
Tibord
senior tag
Szóval ahhoz, hogy a játékok 64 biten gyorsabbak legyenek kell egy tisztán 64 bitre írt motor, ami most még nem létezik, és szerintem néhány évig még nem is fog..
Pontosan így gondolom én is csak nem tudtam igy megfogalmazni
Csak egy kérdés ezt nem tudom. Ha a proci 64bites akkor a buszerndszer is az nem? -
Vertic
aktív tag
Na igen, a játékok... ott a teljesítményigény nagyon függ attól, hogy milyen típusú játékról van szó, de általában három dolog nagyon számításigényes ezen a területen: a grafika, a fizika, és az A.I. (vagy M.I., ahogy tetszik
).
Az utóbbihoz szerintem nincs szükség nagy pontosságú számításokra, ott inkább sokmindent kell csinálni, szóval az nem hiszem, hogy sokat profitál a 64 bitből.
Előbbi kettő, a grafika meg a fizika viszont igen, na itt viszont nagyon durván sok a számítás, és egy részéhez nagy pontosság sem árt. Viszont itt meg legtöbbször már elkészült motorokat használnak fel a játékokhoz, mivel ezeket baromi hosszú ideig tart kifejleszteni és sok pénzbe kerülnek. Másrészt meg ezek a motorok valószínűleg tele vannak elég durva alacsony szintű trükkökkel amik kihasználnak mindenféle hardver- meg szoftversajátosságokat, hogy minél gyorsabbak tudjanak lenni. És azt sem szabad elfelejteni, hogy a grafika már amúgy is eléggé optimalizálva van hiszen az oroszlánrésze a GPUban számolódik, tehát itt nem is lehet elvárni a nagy gyorsulást a 64 bitre váltással, hiszen a GPUra nincsen hatással ez (legalábbis szerintem)
Szóval ahhoz, hogy a játékok 64 biten gyorsabbak legyenek kell egy tisztán 64 bitre írt motor, ami most még nem létezik, és szerintem néhány évig még nem is fog... na, viszont ha az elkészül, szerintem akkor se kell azt várni, hogy durván gyorsabb lesz, inkább csak 32 biten lesz lassabbszerk.: igen, a memóriaigény viszont valós, ahogy elnézem trendet, tehát ha más nem is, ez abba az irányba mutat, hogy kelleni fog az a 64 bites rendszer előbb-utóbb.
-
Tibord
senior tag
Tudom kicsit sántít a hasonlat
Ne mágiának képzelem el a dolgot minimális rálátásom van a programozásra. (próbálták tanítani
)
De ha nem tévedek a mostani játékokba elég sok az adat nem?
De ha meg nincs akkor is ott a RAM kérdése mivel ez 1-2év mulva "kicsit" fontosabb lesz mint most. -
#105
#95904256
törölt tag
hobizsolti
#95
#95904256
törölt tag
válasz
hobizsolti
#95
üzenetére
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?
Nem értem az egész számra vonatkozó kérdést, kifejtenéd?
Amúgy a 80 bites számítás/kerekítés csak az FPU bővített pontosságú üzemmódjában áll fenn. ( Bár az összeadás, kivonás, szorzás a pontatlanabb üzemmódokban is 80 biten történik. )
-
Vertic
aktív tag
az autószereléses hasonlat azért sántít, mert ott teljesen máshogy kell szerelni egy trabantot, mint egy toyotát.
de egy 32 bites programot ugyanúgy kell megírni, mint egy 64 biteset, tényleg semmi különbség nincsen a kettő között, nem kell semmiféle mágiára gondolni. Csak akkor használhatod ki a nagyobb adatszélesség nyújtotta előnyöket, ha eleve szükség volt rá. De ha nem volt, akkor attól nem lesz gyorsabb a program, hogy "64 bitre optimalizálják". Ha eleve szükség volt a nagyobb memóriára, pontosabb számításra, akkor gyorsíthat - vagy pontosíthat - különben meg semmi különbség nem lesz. -
#103
Tibord
senior tag
hobizsolti
#95
Tibord
senior tag
válasz
hobizsolti
#95
üzenetére
Az vesse rám az első követ, aki ugy gondolja hogy azért mert én meg tudom szerelni a trabantot meg a ladát mert megtanultam 10 éve akkor már fasza autószerelő vagy és nem kell nekem megtanulni az újabb autók szerelését. autó autó nem mindegy?
nem azt mondtam hogy a haver optimalizáljon hanem a programozók.
Elvégre ezt várja el az ember tőlük.
Én se szeretem ha új dolgot megtanulnom vagy a megszokot jólbevált módszert fel kell adnom de ez a világ rendje. És ezt diktálja a fejlődés és a józan ész.
egyébként mért nem érdekel 0.1 másodperc?
Próbáld megcsinálni 2000szer egmás után mingyárt érdekelni fog.ennyit erről. A véleményemet írtam le és ez nem biztos hogy egyezik a tieddel
-
#95904256
törölt tag
Nem csak renderelő és képmanipuláló szoftvereknél jelentős a 64 bit, hanem adatbázisok kezelésénél illetve több tudományos ( főképp számelmélettel kapcsolatos ) feladatnál.
Pl. többször örültem már annak hogy több száz bites számokkal simán dolgozhattam regiszterekben tárolva, valamint 32 biten bizony előfordult hogy egy-egy look-up táblát nem sikerült bepakolnom a memóriába és több napos küzdelem kellett hozzá hogy kitaláljak valamit.
-
#101
Vertic
aktív tag
hobizsolti
#96
Vertic
aktív tag
válasz
hobizsolti
#96
üzenetére
így van.
Elég kevesen tolják assemblyben... egy átlagos alkalmazásnál meg az ember valami fincsi magasszintű nyelvben kb. leszarja, hogy az a változó amit használ épp, az milyen pontosságú - amíg elég az adott pontosság. Tehát ha elég a 4 bájtos integer, akkor senki nem fog 8 bájtosat használni, tök értelmetlen is lenne.
A lebegőpontos számoknál már sokszor van értelme double-t használni, de ahol kellett, ott eddig is azt használtak, szóval ezzel nem sok nyereség lesz.
Leginkább a fordítóprogramok feladata az optimalizálás, de az se tud mit csinálni, ha egyszerűen nincs szükség a szélesebb adatra. Ha trükközni lehet a fordításnál, hogy összefoghatnak esetleg két 32 bites adatot, akkor rendben, mondjuk ennek sem tulajdonítok nagy jelentőséget, de a programozók döntő többsége soha nem kerül ezzel közelebbi kapcsolatba, csak kiválasztja, hogy neki mekkora pontosság kell, és csókolom.
Az optimalizáció inkább a visszairányba szokott kelleni - tehát ha 32 bites platformra írunk programot, és túl lassú, akkor megpróbáljuk a 64 bites változókat olyan keveset használni, amennyire csak lehet, vagy ha nincs FPU a gépben (mobilokra kell gondolni), akkor mindent integerrel old meg az ember amit csak tud, még ha logikusan lebegőpontos kéne is.
De olyan optimalizációról még nem hallottam, ami gyorsítana valamit, ahol egyszerűen nincs kihasználva ez.
Tehát valószínű, hogy a képfeldolgozó-renderelő, illetve a hatalmas memóriát vagy nagy pontosságú számítást igénylő programokon kívül a többi (a mindennapi életben használt programok túlnyomó többsége) soha a büdös életben nem lesz gyorsabb 64 biten, és ez nem a programozók hibája. Ennyi. -
szgombos
csendes tag
1. Szerverteszteket szeretnék látni 64 bites Suse, Ubuntu vagy más disztribek alól, és még sokakat érdekelne.
2. A jelenlegi 64 bites processzorok olyanok mint a 486-osok 32 biten, szerintem.
3. Ha már teljesen új platformot kell fejleszteni akkor csinálják meg 128 de méginkább 256 bitesre hogy ne kelljen 20 évente egy-egy újabb generációnak ilyen tesztekkel töltenie az idejé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. -
Tibord
senior tag
Nagyon jó írás
Olvasgattam a hozzászólásokat és annyit had füzzek hozzá én is hogy azért azt lássuk be, nyilván nem a 32bit a jövő hanem a 64. Már csak a memoriaszükségletből kiindulva is.
Bár még ma nem kell(általában) 4GB de 2 évell ezelöt még a 1GB is soknak számított ugyhogy el lehet kézelni mi lesz itt 2 év mulva (pl.: crysis 2 ). A tesztből pontosan leszürhető hogy a mai nem kimondottan tökéletes driver front ellenére is észrevehető lassulás nincs a rendszerben. A másik probléma hogy sok 32bit-es alkalmazást csak lefordítanak de nem optimalizálnak 64bit-re.
Én a x64-es rendszerre szavazok (a pista nekem 7 hónapja nem produkált kék halált vagy lefagyást, mi ez ha nem fejlődé. Kivételt képez tuning miatti kifagyás de az meg nem a Op.Re. hibája)
De mindenki használja azt ami neki tetszik és bevált csak akkor ne szidjon egy olyan rendszert amit ki se próbált vagy nem a megfelelő gépen tette ezt (kipróbálás nem egyenlő fél nap használattal)
Bocs a hosszú rizsázásért
Mégegyszer gratula az írónak
-
lapa
veterán
értem én, hogy a cikk a nagyközönségnek szól, de szerintem simán létjogos lenne egy 2003 szerver tesztkörnyezet a fentiek mellé, lévén ahogy otthon sem, a munkahelyen sem fogok nekiállni tesztelgetni ezer programmal. az viszont érdekelne megéri-e a 64 bit, pláne, hogy ezek vasak nem a "home and office use" árkategóriában vannak...
a másik, elméleti síkú megjegyzés meg tényleg az, hogy bár közöm nincs a linuxhoz, gyakorlatilag nem találtam linuxra vonatkozó adatokat a tesztben. ez nálam kb ugyanaz a kategória, mint a közbeszerzéses csakwindowstmegvevős.
-
Nippon
őstag
Pedig a Vista egy igen stabil oprendszer! Talán nem Slot 1-es procin kéne futtatni a 64bites oprendszert, és akkor nem lenne gond. Nem rossz dolog az a 4giga hidd el!
Amúgy meg kétféle játék van, az egyik jól fut (kb az összes) a másik (Crysis) meg nem, de semmilyen gépen sem. Így lehet, hogy egy-két FPS-sel kevesebb lesz (bár TFT-n Vsync ON-nal úgyis fix 60 v 75 ahol bírja a kari) viszont a több memória miatt nem lesz swappelés. -
orbano
félisten
azert egy jatekban is lenne boven hol hasznalni a 64 bitet. egyszeruen csak nem eleg ujraforditani a kodot a legtobb ilyen alkalmazasban, hanem at is kell tervezni. szerintem kb. ez a tanulsaga a tesztnek is. majd 3-4 ev mulva talan, amikor nagyobb aranyban lesznek 64 bites oprendszerek, lehet, hogy elkezdenek nativ 64 bites programokat gyartani. addig nemigen varhato barmifele elorelepes, az egyetlen haszon a 4gb-nal tobb memoria
-
zlutor
aktív tag
Szerintem is... Ha nincs 64 bites adat, nem hiszem, hogy direktben sokat profitalnak a desktop progik abbol, hogy 64bites a rendszer...
A szerver oldal mas, ott bizony elofordul, hogy a 32 bit nem eleg - pl. igazan nagy adatbazisok - de ezzel meg nem foglalkozik a teszt (nyilvan)...
-
#88
azbest
félisten
hobizsolti
#71
azbest
félisten
válasz
hobizsolti
#71
üzenetére
Elolvastam a #10-es hozzászólásban található HUP link tartalmát is (avagy linux és 64bit).
És hasonló következtetésre jutottam, mint amire te is.
A 16bit -> 32it váltás teljesen más volt. Ugye a lehetőségek nem duplázótak, hanem 65ezerszereződtek, ma meg 4mrdszorozódás van
A memória-korláton kívül a cíkkben írt dolog (hogy kevesebb művelettel lehet ugyanazt elérni) ott valóban erősen kiütközött. 16 vs 32 bit hatalmas különbséget mutat: a számolásban is eléggé korlátozó a 65535, és az érzékszerveink számára is van különbség egy 16bites és 32 (24) bites kép között.A 16 bites procival ugye elég nehézkesen, sok művelettel lehet 32 bites végeredményt kihozni. Ehelyett 32 biten egy lépésben elvégezve a feladatot látványos sebességnövekedést látunk a 16 bites megoldáshoz képest. (valószínűleg nem csak 2szerest).
32 bit elég jól lefedi a legtöbb igényünket. Csak tudományos / speciális alkalmazások ugranak be, ha valós 64 bit igényről van szó (kivéve a memóriakezelés). Persze ahogy mások írták már a plusz regisztereket felhasználva lehet gyorsítani némileg a programokon (a fordítók optimalizálása erre).
Egy hasonlat: adott egy személyautó és egy teherautó, a végsebességük egyforma. Ha üresen mennek akkor nem igazán gyorsabb egyik sem a másiknál. Viszont ha sok csomagot kell vinni, a teherautó ugyanolyan gyorsan elviszi egyben az összeset, ezzel szemben a személyautó a kis csomagtartója miatt többször kénytelen fordulni, mire mindent a célba szállít.
Tehát ha egyszer különbség lesz 32bit és 64bit között, akkor az valószínűleg nem abban jelentkezik, hogy a 64biten gyorsulna, hanem a 32biten sokkal lassabban lehet megoldani a kitűzött feladatokat.
Ma még a hétköznapokban nem nagyon ismerünk olyan problémát, amit 2^32 légy ne tudna megoldani viszont 2^64 de. A fájl mappingos dolog amiről olvastam érdekes dolog és egyike a ritka, de hasznos kivételnek.De ismeritek a mondást:
A számítógéppel olyan problémákra keressük a megoldást, amelyek számítógép nélkül nem is lennénekNem tudom pontosan hogyan történik elektronikai szinten a számolás, de el tudom képzelni, hogy a 64 bitet szét lehetne szedni 2x32-re melyek függetlenül is működhetnek de ha kell 64biten egyesítve is. Persze erről rögtön beugrik a HT és a több mag... de végülis ha csak bizonyos feladatokra kell valóban 64bit, akkor az elektronika egy része valószínűleg nagyon nincs kihasználva - csak 0ákat utaztat.
-
lb
csendes tag
Sztem itt alapvetően szoftver programozási probléma van.
Valószínű - bár annyira nem értek hozzá - nagyon kevés szoftvert írtak ezek közül 64bitre, inkább amolyan toldás-foldás jellegű a dolog.
A cinebenchnél látszik, jelentős különbség, illetve tudom, hogy a vray standalone verziója szintén sokat profitál 64bitből.
Cinebenchet magam is kipróbáltam, 64 X2-n.
Szóval még nem fújnám le a dolgot, max annyi, hogy majd ha mindenütt 64bit ketyeg,
Sztem még jópár év. -
Lortech
addikt
Nekem pl Pentium m procim van Vistával, és kapásból tudok még pár embert.
De a procin kívül van egy másik nagyon fontos tényező is, a driverek. Egyes régebbi alkatrészeknél az is csoda, ha 32 bites Vista driver van, nemhogy 64 bites. XP-s 32 bites drivert az egyszerűbb eszközök nagy százalékánál nem vészes Vistára kiadni, de 64 bittel már nemigen foglalkoznak. Drivereknél pedig nem úgy van, hogy felrakod a 32 bitest és működik általában, mint felhasználói alkalmazásoknál. Ehhez hozzájön, hogy digitális aláírással ellátott driver kell x64-hez.
A Vista felhasználók többsége 32 bitest használ, na most ha csak 64 bitest adtak volna ki, akkor velük kitolnak, mivel nem választhatták volna azt, amit egyébként választottak volna. Ezt jól megaszondtam.
még valami: az MS hülye lett volna két verzióval párhuzamosan szívni, ha reális lett volna, hogy mindenki azonnal hanyatt-homlok átáll a 64 bitre, és hipphopp mindenhez elkészül a 64 bites driver, alkalmazások stb. Nyilván nem a felhasználó két szép szeméért van két változat, hanem hogy minél több Vistát el tudjon, de a kettő szorosan összefügg (felhasználó igény - válasz).
-
Kekszi
csendes tag
En Java fejleszto vagyok es en is csak annyit tudok mondani, hogy egyszeruen nem tudjak a fejlesztok kihasznalni a 64bitet. Felesleges. Egyedul tenyleg csak a renderelo es kepmanipulalo alkalamazasokanal van ertelme ilyen nagy szelessegu szamokat hasznalni. Mas programoknal egyszeruen nincs szukseg ra. 32 bites integerben −2 147 483 648-tol 2 147 483 647-ig terjedo ertek tarolhato. Ez a programok legnagyobb reszeben boven elegendo! Hiba hasznalnanak a fejlesztok 64bites egesz szamokat, ha nem tarolnak benne akkora erteket!
Szerintem -
fLeSs
nagyúr
válasz
#95904256
#78
üzenetére
nem, én pontosan azt írtam, amit akartam.
rengeteg notiban van/volt core duo, ami nem támogatja az em64t-t, ezért sem tehette meg a microsoft, hogy csak 64 bites vistát dob piacra. rengeteg lóvétól esett volna el. de ott van a core solo, pentium m, (régebbi) pentium 4 is.
csak egy megjegyezés. -
#75
#95904256
törölt tag
hobizsolti
#71
#95904256
törölt tag
válasz
hobizsolti
#71
üzenetére
Azokkal a műszaki és gyakorlati dolgokkal amit leírtál teljesen egyetértek, viszont azzal ahogy a cikket szemléled, nem.
Ez a cikk nem szakembereknek szól, hanem az átlagos felhasználókat kívánja kicsit megismertetni a 64 bit nyújtotta előnyökkel, hátrányokkal, lehetőségekkel. Végülis, ők azok akik a többséget alkotják.
-
#72
pok.tom
aktív tag
hobizsolti
#71
pok.tom
aktív tag
válasz
hobizsolti
#71
üzenetére
kvp777 hozzászólása az egyetlen, amit ebből a fórumból meg lehet tartani.
szvsz nem programózok vannak csak itt bocs.. ne haza beszélj..
és pl nekem de talán még aki idetéved ebernek leglaább 50%a nemolvassa végig a te hszedet azis biztos meg h. a felét nemérti..
mod: nem off topikba akartad rakni? -
#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.
-
#70
Komplikato
veterán
Komplikato
veterán
Jó a cikk, de a Crysis tesztet furcsálom, több helyen is +10-20% gyorsulásról írtak egyesek, igaz nem tudom milyen konfiggal. Lehet 64 bites Catalyst volt alattuk?
-
b.vr
őstag
cikk 2. oldala:
A regiszterszélesség-duplázás másik fontos mellékhatása, hogy 64 bites egész számokkal dolgozhatunk. ... esetlegesen 64 bites színmélységgel dolgozó, képalkotásra készített alkalmazások, CAD/CAM tervezőprogramok
Ezt javítani kellene, mert téves. A CAD/CAM/DCC/rendering programok 64 bites _lebegőpontos_ számokkal dolgoznak akár a geometriát, akár a színmélységet tekintve (és természetesen koordinátánként / színkomponensenként)
-
Elmör
őstag
Én is csak a Vistát próbáltam 64bites verzióban, talán azért, mert kíváncsi voltam, hogy a Crysis 4GB RAM-al jobban megy vagy sem, mint 2GB-al. Jelenthetem az én konfigomon nem segített a 4GB. Egyértelműen VGA téren van hiány (persze Very highban csak).
Máshol sem láttam javulást, talán csak a Stalker nem töltött annyit, mint korábban, aztán sajna mire megjött a Witcher és a Hellgate:London addigra eladtam a másik 2GB-ot, pedig ezeknél a gameknál állítólag jó, ha van 3-4GB RAM már. Ezért is gondolom, hogy ha idén még nem is, de 2010-ben már mindenképp ismét 64bites rendszer lesz fent nekem, nagy valószínűséggel Vista.
Hátrányt nem érzékeltem, működött ugyanúgy minden, mint a "sima" Vistában. Persze nekem leginkább csak játékra van a gép max. filmnézés vagy netezés.
A cikken átrágtam magam, köszönet érte!
-
04ahgy
nagyúr
Én azon csodálkozom, hogy ezidáig senki sem említette azt, hogy mi a helyzet XP téren. Mindenki a Vistával foglalkozik.
Megemlíteném tehát, hogy a két Vista (32 bit vs. 64 bit) közt messze kisebb a különbség, mint a Windows XP Professional SP2 és a Windows XP Professional x64 Edition SP2 között. Utóbbi ugyanis köztudottan a 64 bites Windows Server 2003 kernelére épül, és forráskódban is több más helyen épít rá. Lehet, hogy ott érdekesebb eredmények lennének...
Majd ha sok időm lesz, letesztelem nektek. Talán.
HGyu
MOD.: A cikk valóban fenomenális, nagy köszönet érte!
-
FTeR
addikt
jó lett a cikk. általában nem szoktam hw cuccokat olvasgatni, főleg nem ilyen hosszúkat, ezt mégis jó volt elolvasni
"de valamikor valaki azt mondta, hogy 640 kB memória elég lesz mindenre"
nem, nem és nem. sosem mondott ilyet. nincs rá bizonyíték és ő is tagadja. az ilyen idézeteknél legalább az idő és a mondatkörnyezet belőhető, de ezzel kapcs még ezt sem sikerült senkinek összehozni.hamár itt tartunk. nekem úgy rémlik, h ms beszólt intelnek, h nem fogja külön támogatni az ő cuccát. nyilván ez is sokat dobott az amd megoldásának elfogadásán.
-
#61
Dr. Romano
veterán
Dr. Romano
veterán
Gratula jó cikk!
Gondolkodtam hogy kipróbáljak e egy 64bites oprendszert, de a mostani "tesztet" elnézve inkább hanyagolom. Amíg nem lesz minimum 4GB ramom addig nem sok értelme lenne.
-
Uchimata
tag
Aki azt várta, hogy a gépén 32-ről 64-bites oprendszerre váltáskor óriási sebességnövekedést fog tapasztalni, az tévedett. A 64 bit lényege nem a meglévő alkalmazások turbója volt, és ezt semmilyen józan gondolkodású ember nem is várhatta el. A regiszterek kiszélesedtek, és kétszer annyi van belőlük. Van benne némi architekturális változtatás, ahogyan azokra a cikk is felhívja a figyelmet, de a lényeg, hogy mostantól a fejlesztők nincsenek a 4 GB-os határon belülre kényszerítve, illetve a 32b-nél szélesebb adatokat (értsd 64b, esetleg 128b) sokkal kevesebb órajelből feldolgozhatják. Ezzel lehetőség van a 64bitre készített (nem csak fordított) alkalmazásokat ugyanolyan órajellel hasonló teljesítménnyel futtatni, mint a fele olyan széles (32b) adatokon dolgozó programokat -- ezzel ugyebár majd 2x annyi adatot (vagy 2x olyan minőségű adatot) dolgoz fel, mint egy 32 bites alkalmazás.
Vagyis mind memóriában, mind az adatok 64 bitesre szélesedésében felkészül a közeli jövőre az az ember, aki gépét 64 bites oprendszerrel telepíti. A benchmark többek között arra volt jó, hogy azok a hobbi PC-sek, akik bizonytalankodtak a teljesítménymutatókban, az most egy álatlánosabb képet kapott, melynek konklúziója az is lehetne, hogy ha nem muszáj, nem kell váltanod, de félned sem kell tőle.
Kinek pedig a munkája a PC (pl. szoftverfejlesztők, rendszertervezők, hálózatosok), annak meg úgy is tudnia kell, hogy a 64 bit vagy a 32 az elvárt.
Szerintem ;)
-
pok.tom
aktív tag
mert még mindig van egy csomó gép, amiben olyan proci van, ami nem támogatja a 64-bitet.
szted aki vistat vesz annak még 32bites procija van?
amugy érdekes ez a teszt páran ellentmondanak.. h. észrevehető gyorsulás. a ph teszt szerint meg nem annyira?
még kb 1év mikor kijött ugye mint sokan mások énis feldobtam a 64bitet aztan már az alaplap drivernél elakadta az egész.. kicsit szenvedtem vele aztan hagytam.. fel a 32bitet néha jeletősen lassu pl 1. egyszerű törlésnél nemtudom mit gondokozik.. vajon 64bitnél nem csinálja ezt a belassulást..? most ezt nagyon érdekel.. kicsit romokban "néha" romokban van most a vista lehet felrakom a 64bite verziót aztan meglátom -
-
twollah
nagyúr
Miert ne csinalhatna meg?
Monopol helyzetben van.
Akkor az Intes es az AMD sem pocsolne azzal, hogy kiadna 32 es 64bites CPUkat.
Mindegy ez a "mi lett volna ha" kategoria.
Jelenleg ez van ezt kell szeretni.Ha emlekeim nem csalnak anno az Apple mar eljatszotta, hogy amikor kijott az elso PowerPC Mac azonnal megszuntette a 68ks oprendszerenek a tamogatasat.
Erdekes modon simabb volt az atallas.Vagy kenyszerited az embereket az atallasra vagy huzod halasztod az atallast.
A Windows eseteben sajnos ez megy, lasd: Windows7 ami 32 es 64bites is lesz.A 64bitre valo atallast talan az fogja gyorsitani, hogy a jatekoknak elobb vagy utobb keves lesz a 32bit alatt maximalisan elerheto 3giga es elkezdik a fejlesztok csak 64bitre irni a programokat.
De ez meg a jovo zeneje. -
twollah
nagyúr
Vegre egy normalis fejtagitos hozzaszolas!
"Roviden szolva meg messze vagyunk a valodi 64 bites windows rendszerektol, bar a tervek mar keszen vannak."
Jah!
Ha hihetunk az MSnek akkor a Windows8 (ami ugye majd valamikor a 7 utan fog jonni) mar 64bites lesz.IMHO az MS ott szurta el, hogy a Vistat 32/64bitre kiadta.
Eleg lett volna csak a 64bitben kiadni.
Akinek meg nem tetszik az forduljon fel!
E helyett mi van?
32 es 64bit + a kovetkezo Windows is 32 es 64bites lesz.A memoriakezelesrol meg csak annyit, hogy idovel azt vesszuk eszre, hogy 32biten az a 3 giga mar nagyon szuk es valtani kene 64bitre.
Es ki jar jol?
Nem a (f)elhasznalo, hanem az MS, mert ujra meg kell venni a Vistat vagy a masik Windowst.
Ki van ez talalva kezi' csokolom! -
kvp777
tag
Egy program nem lesz gyorsabb attol ha ujraforditjak, csak akkor ha platformfuggetlen, vagy _eleve_ 64 bitre irtak meg. Ha egy program uint32_t-eket hasznal (dword, lparam, unsigned long int, cardinal) es leforditjak 64 bitre, akkor csak annyi valtozik, hogy minden utasitas elott ott lesz a 32 bitre valto prefix (ez lassitja). Ezzel szemben, ha a program idaig is uint64_t-ket hasznalt (unsigned long long int), akkor eddig emulaciot kellett hasznalnia, mostantol futhat rendesen. A gond, hogy aki visual studiot haszalt a fejleszteshez, annak jo ideig nem nagyon volt rendes uint64_t tamogatasa, tehat senki nem hasznalta. Aki viszont linuxot vagy csak gcc-t hasznalt, az barmikor el tudta erni. A vista sem tokeletes meg, mivel nincs benne a teljes uj 64 bites win64 api. Ez olyan, mint amikor a win3.1-re felrakta az ember a win32-ot. Mar mukodott a felulet, de a kernel meg 32 biten ment. Aztan a win95-ben atalltak 32 bitre mindenhol, kiveve a grafikus rendszert (gdi), vegul a win98-nal lettek tobbe kevesbe kompatibilisek a winnt4-el. (kiveve, hogy minden biztonsagi funkciohoz kapcsolodo parametert alapbol eldobtak) A vista most a win3.1->win95 idoszak elejen van. Meg se igazi win64-es programok (amiket nem lehet kiadni 32 bites valtozatban), se rendes api-k nincsennek. Tejesitmenynovekedest csak a '64-bit vista only' programok fognak majd elerni. (meg az osszes gcc-vel forditott kod, de ez windows alatt nem jelentos, ki hasznal windows alatt gimp-et, open source video konvertert, vagy firefox-ot?)
A macosx is csak most kezdi utolerni magat, pedig mar jo 10 eve 64 bites cpu-kon fut. Ennek ellenere csak a 10.5-os valtozatban (legutobbi) jelent meg a rendes 64 bites api, mivel most mar minden tamogatott hardver 64 bites. Ha a microsoft nem adna ki tobb 32 bites cpu-n is futo os-t, akkor lenne eselye arra, hogy gyoruljon a rendszer. (vagy ket kodbazist es fejlesztocsapatot kellene fenttartani, egyet a win32, egyet a win64-es kernelnek, ahogy eddig volt a ntvdm /dos/, a win16 es a win32, sot nt4 alatt meg az os/2 es a posix) A vista most igazabol meg csak a win32-ot tamogatja rendesen, bar a win64 par eleme kezd megjelenni, de egyelore meg nem jelentos. Es szerintem beszelni kellene azzal a bolonddal, aki kitalalta, hogy 64 bites rendszeren a c fordito 32 bites egeszeket hasznaljon alapbeallitaskent. Linux alatt 64 bites gepen sizeof(int) = sizeof(uint64_t), es ez a korrekt. Roviden szolva meg messze vagyunk a valodi 64 bites windows rendszerektol, bar a tervek mar keszen vannak.
-
#43
Blizzard.9
tag
Blizzard.9
tag
"Az x86-64 gyakorlatilag az x86 64 bitre történő terjesztése, ami azt is jelenti, hogy kompatibilis a már meglévő 32 bites architektúrával."
Itt van egy kis elírás. -
-
choosen
tag
lol
Lassan féléve van fenn a 64-es Vista és én teljesen megvagyok vele elégedve.
Érezhetően minden gyorsabban töltődik. És mindenre találni megfelelő programot.
Ha a QFannal volt problémád akkor miért nem kerestél megfelelő progit? Az hogy,nem ment nembiztos hogy, az oprendszer rossz. -
#33
twollah
nagyúr
Thulcandra
#32
twollah
nagyúr
válasz
Thulcandra
#32
üzenetére
Ez szerintem attol is fugg, hogy mennyire optimalizaljak a forditoprogramokat.
Persze ezt csak a paraszti eszem mondja. -
#32
Thulcandra
senior tag
Thulcandra
senior tag
Ahhahha, a reklám mekkora átcseszés, rendesen betolják a nép agyába, hogy kétszer gyorsabb lesz - legalábbis ezt sugallják a "supports twice the data then 32bit", közben nem hogy kétszeresére, még másfélszeresére se gyorsul!
-
Nmajkix
csendes tag
Engem spec. érdekelt volna valami komolyabb környezetben lefolytatott teszt is...
pl:
WinServer2003 x86-64bit vs 32bit, Exchange server 2007, esetleg SQL 2005 (2008).... Hátha ott mutatkozik némi előny.Ja és nem 2 GB rendszermemóriával, hamár a 32bitnek 4 Gb-nél van a határa...
Persze tudom, hogy az átlagos júzer nem ilyen környezetben mozog, de a cikk címe is ez: Processzorok 64 biten.
-
azbest
félisten
Gondolom, csak akkor lenne lényeges különbség 32bit vs 64 bit közt ha péládul 64 biten olyan trükkösen megírt adatfeldolgozást használna egy progi ami két 32 bites adatot egy 64 bitesként egy lépésben használna. De ez elég macerás dolog lehet meg sok műveletnél nem is kivitelezhető. Azért gondolom az assemby lelkes művelői brutál dolgokat képesek lekódolni egy 64 bites procin (trükkökkel növelni a 32 bites adatok feldolgozásának sebességét). Hmm lehet hogy képfeldolgozásban van realitása ennek.
-
]Phobos[
senior tag
Bocs, de gyakorlatias emberke ként kissé felkaptam a vizet. Nyilván van benne potenciál, de ha ilyen tempóban használják ki a progik, inkább megéri a magok számát növelni. Abban viszont eccerű VirtualDub alatt is megéreztem a gyorsulást( majdnem 2x sebesség!
) 2500+ Bartonhoz képest! -
]Phobos[
senior tag
A QFan-nal volt valami galibája az OS-nek, csak erre tudok gondolni, mert 0401-es BIOS-sal 1 MHz-es húzásnál is QFan Error-t írt ki, 64bites OS-nél meg kapásból hibát észlélt restart után, jah és 2600-as prm-nél alap 60 fok, és elindult fölfelé, úgy, hogy még az MSN-t sem nyitottam meg, 75 foknál inkább restartoltam. Mindezt úgy, h amúgy 2.88-ra felhúzva is 60 fok körül tartja silent módban( 32bit alatt ).
-
Yany
addikt
Lehet, hogy rosszul tudom, de a 32 bites Windows hiába lát akármennyit is 2 giga fölött, egy process egyszerre max. 2 gitát lát. Én a héten tervezem összerakni a gépem és biztos, hogy már nem 32 bites oprendszert teszek fel rá. Persze ha fLess még megajándékozna minket általános tapasztalatokkal (vagyis pl. hogy instabilabb volt-e 64 biten a rendszer, mint 32-n, vagy hasonlók), akkor még eldőlhet a vita, de engem a 4 giga RAM-om is 64 bitre ösztökél...
-
]Phobos[
senior tag
OH, bocs májszter, mekkora barom vagyok, hogy 3 napot elpocsékoltam az életemből 1 nyilvánvalóan nem működő dologra, goldoltam megosztom mással is, hátha nem mindenkinek van ideje 3 napot kísérletezgetni, meg szívni a .... . Elk.rtam. Nem kicsit, nagyon! Tehát ha lenne olyan progi, ami jelentősen gyorsul, akkor, igen van értelme. Esetenkénti 3-4%-os gyorsulás viszont számomra nem mérvadó. Ergó, nekem MÉG nem éri meg váltani. Ez pedig csak azért ciki, mert nem tegnap jelentek meg a 64bites procik. ENNYI! Vistát meg nem próbáltam, de MONDTÁK, hogy 32bites Ikszpénél lassabban mennek a játékok, persze minden ember hülye, akit ismerek, ha meg nem, akkor búgócsiga. Lehet, szánalmas, de nem divat májszter vagyok, a gyakorlat jobban érdekel. Éljenek soká a vérpistikék!
-
én egy vitathatatlan előnyét láttam eddig a 64 bitnek: lakótársam 3D grafikus 3ds max-al és VRay-el dolgozik. egy-egy nagyobb jelenetnél, mikor a memória kihasználtság elért egy bizonyos szintet a Max egyszerűen kivágott az asztalra (állítólag a 32 bites op.rendszer max 1.5 GB RAMot oszt ki egy alkalmazásnak)... 64 biten ilyen nincs, gondolom az több memóriát ad neki...
]Phobos[: ezt komolyan gondoltad? túl fűti az op.rendszer a procit? ez aláírásba illő lenne
CPT.Pirk: köszi, de mostmár mindegy. 64 bitet használ, marad is
-
CimbiX
aktív tag
En több, mint 6 honapja VistaX64-et hasznalok, eddig ez volt a legstabilabb oprendszer, amit eletemben hasznaltam. Semmi fagyas, ujratelepiteni sem kellett soha. Teny, hogy csak jatekokra hasznalom joforman a gepet, de igenis erezhetö a 2 es 4 giga közötti különbseg pl. mar a STALKER-ben is.
-
CPT.Pirk
Jómunkásember
Procidat nem a win fűti túl, valamint vistából már kész a 64 bites... És akkor arra mit lépsz, hogy 64 bites vista nálam gyorsabb a 32bitesnél?
Az XP64bites változatához meg köztudottan nehéz jó drivert találni, nyilván valami driver bugba futottál bele, amitől a betöltés is lasabb lett. Emiatt nem a komplett technológiát kellene baromságnak nevezni, hanem amit leírtál.
-
]Phobos[
senior tag
Azt elismerem, h a 64bites Ikxpé nem "valódi" 64bites rendszer- legalábbis én így emlékszem-, a lényeg, h nekem lassab volt mint a 32 bites, a videókari driverek meg bugosak: CS1.6 E4300+2600Pro+2GB RAM = 30! FPS? A CPU-t vmiért még maxra tolt hűtővel is túlfűtötte néhány óra után, arról meg, h mennyi idő alatt állt fel a win, ne is beszéljünk ... ez a 64bit oltári baromság! /legalábbi 1enlőre/ Vista-ból elég lesz a 32bites is, 1 játék sem gyorsul 2+2GB Rammal jelentősen ...
-
Niquis
aktív tag
Még az A64 felfutása idején tesztelték valahol, viszonylag neves oldalon az UT2004 sokcsatornás hangos verzióját 64 biten, és ott kihozták, hogy arra pl. baromi jó. Sajnos most nincs időm utánanézni, hogy hol és mikor volt, de ez pl. egy elég jó lehetőség a kiterjesztés kihasználására.
-
nekemis ez a véleményem annyi kulonbseggel hogy en a 32 bites Vistat valasztottam
Amig nincs szuksegem 3 giganal tobb ramra, addig ense valtok, 64 bites OS-re, énis kipróbáltam 2 hónapra a 64 bites vistat, es regebben az XP-t is, de nem volt teljesítményjavulás sehol (nem renderelek, es nem vagok videot).
Szoval szép-szép, de amig 32 bites programokat futtatunk 64 bites rendszeren, addíg felejtős. -
skyboi
tag
Tényleg nagyon vártam már egy írást ebben a témában. Azt gondoltam, hogy a VISTA megjelenésével elérkezett az az idő, hogy 4 giga ramra váltsak és 64 bites OPrendszert tegyek fel. A szösszenetnek hála beláttam, hogy jó nekem még a XP 32 bit. Kínlódás, baj nem hiányzik. Gratulálok a cikkírónak!
-
#6
msgt.fubar
senior tag
msgt.fubar
senior tag
Egyre jobban kezdem megszeretni a ph-cikkeket, nem csak az "unalmas" benchmarkok és tesztek vannak benne, hanem az első néhány oldalon érdekes háttérinfók (ha úgy tetszik fejtágítás). Nekem ez mindenképpen pozitívum, jó a dolgok mögé látni.
Végén jót nevettem a 2003-as AMD-reklámon
-
Enton
addikt
Magyarán szólva szinte semmi olyan feature-t nem tud még Win alapon felmutatni a 64bit ami miatt érdemes lenne áttérni a 32bites verziókról!
Sajnos alapból nagyon rossz a hírük a 64bites Win platformoknak, de hogy még nagyon gyorsulást sem okoz!
szerény véleményem szerint akkor csak a memóriakezelés az ami a plusszt és a hasznot hozza a 64bit kiaknázásából!
Már csak az a kérdés hogy mi a helyzet a Linux/Unix és hasonló lekicsinylett OS-ek terén!Az olvasmány pedig tanítandó, tananyagi szintű!Grat hozzzá!
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
Hirdetés
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Kínai és egyéb olcsó órák topikja
- A fociról könnyedén, egy baráti társaságban
- Google Pixel 9a - a lapos munka
- Milyen autót vegyek?
- Medence topik
- Kerékpárosok, bringások ide!
- BestBuy ruhás topik
- További aktív témák...
- BESZÁMÍTÁS! MSI B450M R5 5500 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Chieftec 600W
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Telefon felvásárlás!! Xiaomi Redmi 9, Xiaomi Redmi 9AT, Xiaomi Redmi 10, Xiaomi Redmi 10 2022
- Csere-Beszámítás! Olcsó Számítógép PC Játékra! R5 1500X / RX 570 8GB / 16GB DDR4 / 250SSD + 2TB HDD
- Apple iPhone 14 Pro Max / 256 GB / 88% akkumulátor / 1év Garanciával / Gyári Független
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest