Инсталирайте 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