- Az Amazon 54 milliárd dollárt pumpál Nagy-Britanniába
- A Tesla és a Google volt mérnökei AI által írt szövegek után kutatnak
- Nehéz helyzetben az SMIC, régebbi chipet használ az új Huawei laptop
- Itt a legkisebb asztali GeForce RTX 50-es VGA
- A ViewSonic új üzleti monitorai megoldják az online kommunikációt is
- Nvidia GPU-k jövője - amit tudni vélünk
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Itt a legkisebb asztali GeForce RTX 50-es VGA
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- DUNE médialejátszók topicja
- Vezetékes FEJhallgatók
- Milyen házat vegyek?
- Fejhallgató erősítő és DAC topik
- HTPC (házimozi PC) 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.
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
Hirdetés
- Milyen légkondit a lakásba?
- Autós topik
- Xbox tulajok OFF topicja
- Minden készen áll a Galaxy Unpackedre
- Elfelejtettem a film címét
- Nvidia GPU-k jövője - amit tudni vélünk
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Formula-1
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RTX 4070Ti Super GAMER PC termékbeszámítás
- Samsung Galaxy S22 Ultra 128GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 200 Pro 512GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged