Steam 설치
로그인
|
언어
简体中文(중국어 간체)
繁體中文(중국어 번체)
日本語(일본어)
ไทย(태국어)
Български(불가리아어)
Čeština(체코어)
Dansk(덴마크어)
Deutsch(독일어)
English(영어)
Español - España(스페인어 - 스페인)
Español - Latinoamérica(스페인어 - 중남미)
Ελληνικά(그리스어)
Français(프랑스어)
Italiano(이탈리아어)
Bahasa Indonesia(인도네시아어)
Magyar(헝가리어)
Nederlands(네덜란드어)
Norsk(노르웨이어)
Polski(폴란드어)
Português(포르투갈어 - 포르투갈)
Português - Brasil(포르투갈어 - 브라질)
Română(루마니아어)
Русский(러시아어)
Suomi(핀란드어)
Svenska(스웨덴어)
Türkçe(튀르키예어)
Tiếng Việt(베트남어)
Українська(우크라이나어)
번역 관련 문제 보고
32 bit programs have a ram limit of 2g per program
and 3.5-3.75g for the entires system
64bit program can use as much ram as available
Go to My Computer -> System Properties -> Advanced System Settings -> Performance. Disable everything but smooth edges and maybe translucent selection rectangles.
Disable all the services and unneeded crap running in the background by running msconfig or services. Gamebooster does this automatically, or you can get the list of services it disables and do it yourself and uninstall gamebooster.
64-bit code is faster than 32-bit code even if an application doesn't go over the 32-bit memory limit. It does use more memory though, but 32-bit is becoming legacy hardware and memory usage can be lowered with some tweaking, and the OP is already doing a ghetto rig instead of the best solution which is upgrading when ram is cheap so might as well take the extra step.
To answer your other question: Will is stop lagging? Probably not. I have a feeling your underlying hardware (cpu, motherboard, HDD) are probably slowing you down as well.
This is an absolute false statement. Even the Steam application is still 32-bit. The main advantage to compiling in 64-bit is to get access to more memory. Although 64-bit hardware may outperform 32-bit hardware, it is usally because of the architecture (i.e. more registers, faster data transfers, bigger cache, etc...) However, many parts of this architecure can be used with the 32-bit applications as well if you have the underlying 64-bit hardware in place.
That's not a false statement that code is faster even if a program doesn't go over the 2gb limit.
Anyways, the bigger issue is changing usage habits to be more minimalist.
This may free up 512MB to 1024MB of memory.
Also 64-bit executables tend to be about 30% larger than 32-bit ones.
Really, it is not. The only reason why 64 bit can be faster is 8 additional general-purpose registers. But instruction word is longer because of additional prefixes, longer addresses, offsets and opcodes themselves. Thus, this makes decode slower. More than that, you need twice as much cache/RAM bandwidth for data and stack (and you can keep more instructions in L1i cache and twice more data in L1d cache. So you have more cache hit percentage).
And you usually don't get any performance gain from ability to use 64-bit operands - compiler uses SIMD instructions to work with 64-bit data either way.
All in all, 64-bit applications either have the same performance or, in best case, 10-15% faster. No big difference.
Modern 2015 software (often still 32-bit too) and a bloated browser on limited memory is going to struggle either way and the future has to be kept in mind. Ram is cheap too. But yeah I made the points because of that, and the huge misconception about 64-bit. Go for 32 if you're set on not upgrading.
Finally