Reducing runtime memory in Windows 8
blogs.msdn.com
blogs.msdn.com
So, pointless demo. It probably run everything from the HDD.
Bigger issue: The low priority memory. AVs are a big memory hog and cause problems, this will mitigate it. MS is acknowledging that AVs are a necessary evil and there are not the only ones that do this, and this allows you to just make friendly programs.
Well, if the memory were lower, the call would have been made CPU->HDD which is orders of magnitude slower, so you'd expect more RAM would necessarily improve the general performance.
However, RAM remains one of the largest power consumers, and so reducing memory usage also reduces power usage, which improves battery life.
Tom's hardware has a great article on this here: http://www.tomshardware.com/reviews/lovo-ddr3-power,2650-2.h...
Note in particular the figures at the bottom of the article page.
The best possibility would be fully realising the NUMA architecture, and giving each core a stack of dedicated SRAM or DRAM at sizes of 1GB (these would have to be off-die though).
On modern CPU's, HALF- or MORE of the silicon is used to afford 4-16MB L3 caches. A CPU die is not much smaller than a DRAM chip, and a 1GB chip of DRAM is less than $10 these days judging by the prices of 16GB, 16-chip sticks of DRAM.
- CPU caches are wired much more complex than SRAM memory modules would need to be. It may be shared between CPUs, and being n-way surely requires silicon, too.
- if the ratio is way more than 10, why, then, do I find zillions of references stating that a) DRAM needs a transistor per bit, and b) SRAM can be built with 6 transistors per bit?
1) A programmer who programs something of decent size and ceases to concern themselves with memory entirely will write code that will continue to bloat unneccesarily-so for the life of the software. At least some attention to memory is neccesary to keep usage reined in. You don't have to fight for KiB, but think about it. It rather seems to be a resource you can use 5% of, but without proper attention rapidly wind up consuming 100% of.
2) A programmer who disposes of the idea of using memory efficiently has probably discarded the idea of algorithmic efficiently in any way whatsoever. Pursuing memory optimization is a decent proxy for all forms of optimization.
[/not a programmer by trade]
Space and time have to very often be traded off against each other in algorithms.
If the memory is available, you'd do better to use it, no?
> If the application tries to write to the memory in future, Windows will give it a private copy
It is textbook Copy-on-write. To me it seems no judgement is made about the programmer.
>If the memory is available, you'd do better to use it, no?
I don't understand... if I have 2 GB of RAM, I should always use all of it? The case being made in the article is to minimize memory consumption to increase battery life - something that will be crucial on tablets I assume.
These are Windows programmers we're talking about. The culture doesn't seem to encourage fastidiousness.
If the memory is available, you'd do better to use it, no?
Yes, but what if you run out later? Should you do the dedupe when some other process is blocked trying to allocate memory or should you do it earlier?
http://blogs.technet.com/b/askcore/archive/2008/09/17/what-i...
If they use a DLL version x for a component A and a version y for a component B, they raised memory usage only for convenience of not updating one of the components to use the latest version of the DLL.
This is especially a problem in enterprise deployments where there may be a variety of spottily maintained internal and third-party applications loaded on a machine. Having to choose between refreshing every single one of them or throwing the unrefreshed ones out is an impractical choice. Thus DLL versioning.
Avoid resulting problems by either maintaining your apps in a way that allows them to all use the same build of a DLL or simply by running as few apps as possible to minimize library loading in general, duplicate or otherwise.