YMMV - XP ran perfectly fine for me on an Athlon700/512meg ram... and flied when I upgraded to 1gig and disabled pagefile. Yes, Vista and Win7 require a higher baseline than XP, but in my experience they utilize powerful hardware better than XP. I obviously wouldn't install either on underpowered hardware, just like I wouldn't use XP (but rather Win2K) on even older hardware.
SuperFetch. Instead of looking blindly at "free physical memory", take a look at what SuperFetch uses and deduct that from the score, since it's essentially free ram - it's nondirty (aka clean) disk cache, and can thus be discarded right away if the system needs ram to service a memory request. And the up side is that SuperFetch speeds up application loading bigtime. I'd be pretty surprised if there aren't clones of it for linux already.
actaully the windows 7 caching model is great. on games the difference between the first loading of a level and subsequent loads are night and day thanks to it's caching model.
That's the windows cache system generally, from way back in the NT days... Vista and later SuperFetch is more than that.
btw, regarding the article more directly: they shows no figure about the actual _swap_ usage, a thing that may or may not disprove their theory.
Indeed. The xpnet site does mention that they factor in paging somehow, but that's still pretty useless - paging activity needs to be a separate statistic. Also, simply looking at pagefile usage isn't terribly useful, an inactive app can have it's working set trimmed and pages flushed out to disk, and this won't matter much in the big picture.
What you need to look at is the rate of pagefile activity (ie., pages/second) as well as how often it happens - not just static numbers (even if having 1gig of data in the pf is probably a warning sign:))
Bull(2). The OS does not spend any time to "free up that RAM cache". the RAM is simply overwritten with new data, just like if it was free. The original data was just a copy of data from the HDD.
Almost correct - before handing out the memory to satisfy a memory request, Windows makes sure it's all zeroed out, for security concerns. Look at the various lists used by NT to organize memory pages, this link has a rudimentary description
Zeroing out pages is fast, though, and done with SSE write-through (i.e., no cache pollution). Iirc the SSE operations were done already in Win2k, and is definitely there in XP and later. So it's going to run at pretty much full RAM bandwidth... and outside of memory-starved situations, this zeroing happens in the background.
Active RAM has the same periodic refresh cycle of idle RAM, but also the constant reading/writing of data over the system bus, which means about twice the energy used.
With your terminology, "active" meaning "being read/written"? You can easily have contents in RAM that's not being actively accessed, which means there won't be bus activity.
The question being: does simply having used RAM (i.e., set rather than reset bits) mean noticeably higher power consumption?
Wether the program is accurate or not is another matter, but the fact it doesn't report every system as using 100% of its memory suggests it is at least somewhat aware of superfetch etc.
Not really, SuperFetch doesn't necessarily use all available RAM - it depends on how much data it knows about... it doesn't just go out and read random files to memory:)
Also anecdotal, subjective and unscientific from my side: Windows seems to page out to disk too early, at least the "older" (and memory-conservative) releases, WinXP and below. After upgrading to 1GB of RAM and disabling pagefile, I definitely noticed less disk activity... and since then, I never looked back.
While the GP is correct in the dangers of disabling pagefile, I rarely had problems on 1GB, and never on 2GB. These days my machine has 8GB, so whatever:)
You're making an apples-to-oranges comparison, and you don't mention what software is running on either of your machines...
I've found Vista and Win7 to generally work better, giving decent enough hardware. Because of SuperFetch, Visual Studio loads faster on my Vista64 dualcore laptop with 7200rpm drive and 2 gigs of memory than on XP64 quadcore workstation with 10000rpm raptor drive and 8 gigs of memory. But this isn't a fair comparison either, since the rest of the software suite on those two machines are specced differently.
Yep, that would be a problem - but neither the TFA nor xpnet mentions if this is actually happening, it seems that they're looking almost exclusively at "free physical memory", which isn't a useful stat in this regard. The xpnet site does say they factor in "how often it relies on virtual memory", but not how they do this (there's multiple metrics to choose from, some fairly uninteresting) and the fact that they seem to factor this in as a part of "memory usage" rather than keeping it as a separate stat makes me pretty wary of trusting any analysis from them.
Well, it's easy to get wrong - and considering Windows is used by regular Joes, it's OK that task manager simplifies matters a bit instead of showing up pages of detailed information.
It's a shame when people who have no clue about how the memory manager works then start making a lot of assumptions... and even worse when somebody who's "collecting system metrics" don't seem to get it, either.
I'm not ruling out that there could be disk paging involved, and there's some actual problem, but considering my own win7 experience across a number of machines as well as the info in the TFA + linked site, I somehow doubt it:)
TFA (which I've just read:)) doesn't really mention whether they're looking at disk paging. Browsing to the xpnet site does say they do, but it also mentions that they base memory load on "free physical memory". The Windows APIs don't report the superfetch cache memory as "free physical memory", since it isn't.
Those Devil Mountain guys need to update the system metrics they're collecting - it should include at least cache-size in addition to free physical memory, and pagefile use (size of paged-out data and paging rate per second!) should be a separate stat, not factored in with the "free physical memory" stat.
No offense but I'm going to side with the guy who appears to make his living testing these sorts of things... the guy who is offering me numbers.
He's offering you interpreted numbers, not raw data - and he's not offering you all the numbers you need in order to make educated statements on what's going on. He's probably doing it in good faith out of ignorance, rather than trying to spread FUD, but it's still pretty useless metrics.
It shows up as part of the memory commit bar - which is what regular users will look at, and then go off screaming about "OMG IT USES ALL MY SYSTEM MEMORY!1!!! one one". It's also deducted from the "free" count, since technically it isn't free (it can be freed quickly, but has to be zeroed out before it can be handed off to a new app - security and all).
The Win7 task manager does show a "cached" stat, though, so your effectively free memory is "free"+"cached". And if you want more comprehensive memory stats, you should look at perfmon.msc or SysInternals' Process Explorer.
I wonder if TFA has actually measured that disk swapping happens (easy with procexp or perfmon), or are just shouting their heads off without understanding what's going on... it's well-known that SuperFetch utilizes otherwise unused memory for disk caching, and does so proactively:)
Yep - it's a shame that legitimate customers have to be treated like would-be pirates, whereas piracy makes it as simple as 1) download via torrent client 2) install and apply crack 3) profit
Getting Battlefield 2142 (legit, of course) working was quite a dance for me... first I had to use EAs sucky download manager, then I had to create two accounts at different EA sites and get them linked (it wasn't exactly obvious how or what you need to do), and even then I couldn't play the game, bombing out with a nondescript securom error message. Turned out it considers sysinternals' Process Explorer a "dangerous thing to have running" - like, wtf?
If I'm going to be treated as a villain when purchasing a game, I might as well just pirate it and save myself the hassle.
Could you give an example of "does a lot of things automatically that you don't necessarily want"? I honestly can't recall bumping my head into this. The one thing I can think of would be invoke and addr of locals using lea w/eax...
You don't have to use the high-level features of MASM, but they can definitely be nice. People have imitated.IF for NASM, so I'm probably not the only one who thinks it is:) - and you know exactly what you're getting when using those highlevel keywords, while not having to introduce a lot of "skip_if" style labels (or the dreadful @@ anonymous ones).
I agree on the "inconsistency", and always use [indirection] brackets, also when writing MASM. You can control emitteded opcodes with MASM just fine, though - add eax, byte ptr 5 versus add eax, dword ptr 5 and jmp near ptr mylabel versus jmp short mylabel.
Intrinsics aren't portable across compilers, whereas you can write your routine once in an external assembly module and link against that, regardless of compiler used. Also, even Intel's compiler doesn't generate perfect code when using intrinsics - IMHO intrinsics are mostly useful for fleshing out an implementation, and then you can hand-tune the register allocation once your idea works.
FASM has a powerful preprocessor, but it's lacking in some respects: macros can't "EXITM", so you can't do something to the effect of mov eax, mymacro(10, ebx), which is possible with MASM-style macros (and thus JWASM). Also, fasm's preprocessor doesn't have decent string processing.
Agreed - the MASM preprocessor is so powerful you can even implement a C-style switch block with it. And before you exclaim "oh, but that's easy", let me add that we're not just talking a series of CMP/JE instructions, but a fully-fledged "binary search tree" style implementation:)
And while eg. the FASM preprocessor is also pretty powerful, it doesn't have masm's EXITM statement, nor it's string processing features. OTOH the preprocessor+assembler can still do some pretty wicked things, like modifying emitted code (think assemble-time time code encryption).
Hand-tuned code usually outperforms what a compiler produces from intrinsics. Not always by a lot, but sometimes it can be substantial... also, some of the intrinsic routines have horribly long and convoluted names compared to the real mnemonics. And then there's the issue of incompatible intrinsics across compilers. So much easier (and portable:P) to use an external assembly module and link that in.
And yes, x86 has had register renaming for quite a while - introduced with the PPro back in 1995. That doesn't mean hand-picked register allocation is useless, though.
For OS development, a few very tiny bits of code just can't be written in C - this is a very limited amount of code lines, though. You usually don't even need assembly code for driver development, since you'll be interfacing with your OS HAL layer.
If you're writing high-performance audio or video code, assembly can still have very substantial performance gains, though, since it lets you use the full CPU instruction set (MMX, SSE), which highlevel code generally doesn't. It's true that recent compilers can utilize SSE automatically, but even Intel's own compiler is inferior to hand-written code.
And if you start using instruction intrinsics, rather than depending on automatic use of SSE instructions, then I'd argue that you're actually writing (a bastardized) form of assembly... and the code generated when you use intrinsics can usually be sped up quite a bit by hand-tuning the register allocation by rewriting in - you guessed it - assembly.
An assembler assembles assembly code - you don't write "assembler code", you write "assembly code". Unless of course you're writing an actual assembler;)
You generally don't see that kind of commandlines for other assemblers, though.
And not being able to specifying output format on the commandline is kinda limiting - it can be quite useful to target multiple formats (omf/coff/elf) from a single source file. It's possible with FASM, but kinda mucky... requires setting environment variables and doing include "%TARGETFMT%.inc" - ugly compared to just specifying output format at commandline, or specifying a pre-processor symbol:value pair and acting on that.
Slashdot Mirror
I kinda agree with you, but if MS did it that way, the *u*x zealots would run around in circles screaming lies & bloody murder. Catch-22? :)
YMMV - XP ran perfectly fine for me on an Athlon700/512meg ram... and flied when I upgraded to 1gig and disabled pagefile. Yes, Vista and Win7 require a higher baseline than XP, but in my experience they utilize powerful hardware better than XP. I obviously wouldn't install either on underpowered hardware, just like I wouldn't use XP (but rather Win2K) on even older hardware.
SuperFetch. Instead of looking blindly at "free physical memory", take a look at what SuperFetch uses and deduct that from the score, since it's essentially free ram - it's nondirty (aka clean) disk cache, and can thus be discarded right away if the system needs ram to service a memory request. And the up side is that SuperFetch speeds up application loading bigtime. I'd be pretty surprised if there aren't clones of it for linux already.
actaully the windows 7 caching model is great. on games the difference between the first loading of a level and subsequent loads are night and day thanks to it's caching model.
That's the windows cache system generally, from way back in the NT days... Vista and later SuperFetch is more than that.
btw, regarding the article more directly: they shows no figure about the actual _swap_ usage, a thing that may or may not disprove their theory.
Indeed. The xpnet site does mention that they factor in paging somehow, but that's still pretty useless - paging activity needs to be a separate statistic. Also, simply looking at pagefile usage isn't terribly useful, an inactive app can have it's working set trimmed and pages flushed out to disk, and this won't matter much in the big picture.
What you need to look at is the rate of pagefile activity (ie., pages/second) as well as how often it happens - not just static numbers (even if having 1gig of data in the pf is probably a warning sign :))
Bull(2). The OS does not spend any time to "free up that RAM cache". the RAM is simply overwritten with new data, just like if it was free. The original data was just a copy of data from the HDD.
Almost correct - before handing out the memory to satisfy a memory request, Windows makes sure it's all zeroed out, for security concerns. Look at the various lists used by NT to organize memory pages, this link has a rudimentary description
Zeroing out pages is fast, though, and done with SSE write-through (i.e., no cache pollution). Iirc the SSE operations were done already in Win2k, and is definitely there in XP and later. So it's going to run at pretty much full RAM bandwidth... and outside of memory-starved situations, this zeroing happens in the background.
Active RAM has the same periodic refresh cycle of idle RAM, but also the constant reading/writing of data over the system bus, which means about twice the energy used.
With your terminology, "active" meaning "being read/written"? You can easily have contents in RAM that's not being actively accessed, which means there won't be bus activity.
The question being: does simply having used RAM (i.e., set rather than reset bits) mean noticeably higher power consumption?
Wether the program is accurate or not is another matter, but the fact it doesn't report every system as using 100% of its memory suggests it is at least somewhat aware of superfetch etc.
Not really, SuperFetch doesn't necessarily use all available RAM - it depends on how much data it knows about... it doesn't just go out and read random files to memory :)
Also anecdotal, subjective and unscientific from my side: Windows seems to page out to disk too early, at least the "older" (and memory-conservative) releases, WinXP and below. After upgrading to 1GB of RAM and disabling pagefile, I definitely noticed less disk activity... and since then, I never looked back.
While the GP is correct in the dangers of disabling pagefile, I rarely had problems on 1GB, and never on 2GB. These days my machine has 8GB, so whatever :)
You're making an apples-to-oranges comparison, and you don't mention what software is running on either of your machines...
I've found Vista and Win7 to generally work better, giving decent enough hardware. Because of SuperFetch, Visual Studio loads faster on my Vista64 dualcore laptop with 7200rpm drive and 2 gigs of memory than on XP64 quadcore workstation with 10000rpm raptor drive and 8 gigs of memory. But this isn't a fair comparison either, since the rest of the software suite on those two machines are specced differently.
Yep, that would be a problem - but neither the TFA nor xpnet mentions if this is actually happening, it seems that they're looking almost exclusively at "free physical memory", which isn't a useful stat in this regard. The xpnet site does say they factor in "how often it relies on virtual memory", but not how they do this (there's multiple metrics to choose from, some fairly uninteresting) and the fact that they seem to factor this in as a part of "memory usage" rather than keeping it as a separate stat makes me pretty wary of trusting any analysis from them.
Well, it's easy to get wrong - and considering Windows is used by regular Joes, it's OK that task manager simplifies matters a bit instead of showing up pages of detailed information.
It's a shame when people who have no clue about how the memory manager works then start making a lot of assumptions... and even worse when somebody who's "collecting system metrics" don't seem to get it, either.
I'm not ruling out that there could be disk paging involved, and there's some actual problem, but considering my own win7 experience across a number of machines as well as the info in the TFA + linked site, I somehow doubt it :)
My guess would be "nothing to see here people, move along - trolls day out, looking for publicity".
TFA (which I've just read :)) doesn't really mention whether they're looking at disk paging. Browsing to the xpnet site does say they do, but it also mentions that they base memory load on "free physical memory". The Windows APIs don't report the superfetch cache memory as "free physical memory", since it isn't.
Those Devil Mountain guys need to update the system metrics they're collecting - it should include at least cache-size in addition to free physical memory, and pagefile use (size of paged-out data and paging rate per second!) should be a separate stat, not factored in with the "free physical memory" stat.
No offense but I'm going to side with the guy who appears to make his living testing these sorts of things ... the guy who is offering me numbers.
He's offering you interpreted numbers, not raw data - and he's not offering you all the numbers you need in order to make educated statements on what's going on. He's probably doing it in good faith out of ignorance, rather than trying to spread FUD, but it's still pretty useless metrics.
It shows up as part of the memory commit bar - which is what regular users will look at, and then go off screaming about "OMG IT USES ALL MY SYSTEM MEMORY!1!!! one one". It's also deducted from the "free" count, since technically it isn't free (it can be freed quickly, but has to be zeroed out before it can be handed off to a new app - security and all).
The Win7 task manager does show a "cached" stat, though, so your effectively free memory is "free"+"cached". And if you want more comprehensive memory stats, you should look at perfmon.msc or SysInternals' Process Explorer.
I wonder if TFA has actually measured that disk swapping happens (easy with procexp or perfmon), or are just shouting their heads off without understanding what's going on... it's well-known that SuperFetch utilizes otherwise unused memory for disk caching, and does so proactively :)
Yep - it's a shame that legitimate customers have to be treated like would-be pirates, whereas piracy makes it as simple as
1) download via torrent client
2) install and apply crack
3) profit
Getting Battlefield 2142 (legit, of course) working was quite a dance for me... first I had to use EAs sucky download manager, then I had to create two accounts at different EA sites and get them linked (it wasn't exactly obvious how or what you need to do), and even then I couldn't play the game, bombing out with a nondescript securom error message. Turned out it considers sysinternals' Process Explorer a "dangerous thing to have running" - like, wtf?
If I'm going to be treated as a villain when purchasing a game, I might as well just pirate it and save myself the hassle.
Operand order depends on assembler, not platform :)
Could you give an example of "does a lot of things automatically that you don't necessarily want"? I honestly can't recall bumping my head into this. The one thing I can think of would be invoke and addr of locals using lea w/eax...
You don't have to use the high-level features of MASM, but they can definitely be nice. People have imitated .IF for NASM, so I'm probably not the only one who thinks it is :) - and you know exactly what you're getting when using those highlevel keywords, while not having to introduce a lot of "skip_if" style labels (or the dreadful @@ anonymous ones).
I agree on the "inconsistency", and always use [indirection] brackets, also when writing MASM. You can control emitteded opcodes with MASM just fine, though - add eax, byte ptr 5 versus add eax, dword ptr 5 and jmp near ptr mylabel versus jmp short mylabel.
Intrinsics aren't portable across compilers, whereas you can write your routine once in an external assembly module and link against that, regardless of compiler used. Also, even Intel's compiler doesn't generate perfect code when using intrinsics - IMHO intrinsics are mostly useful for fleshing out an implementation, and then you can hand-tune the register allocation once your idea works.
FASM has a powerful preprocessor, but it's lacking in some respects: macros can't "EXITM", so you can't do something to the effect of mov eax, mymacro(10, ebx), which is possible with MASM-style macros (and thus JWASM). Also, fasm's preprocessor doesn't have decent string processing.
Agreed - the MASM preprocessor is so powerful you can even implement a C-style switch block with it. And before you exclaim "oh, but that's easy", let me add that we're not just talking a series of CMP/JE instructions, but a fully-fledged "binary search tree" style implementation :)
And while eg. the FASM preprocessor is also pretty powerful, it doesn't have masm's EXITM statement, nor it's string processing features. OTOH the preprocessor+assembler can still do some pretty wicked things, like modifying emitted code (think assemble-time time code encryption).
Hand-tuned code usually outperforms what a compiler produces from intrinsics. Not always by a lot, but sometimes it can be substantial... also, some of the intrinsic routines have horribly long and convoluted names compared to the real mnemonics. And then there's the issue of incompatible intrinsics across compilers. So much easier (and portable :P) to use an external assembly module and link that in.
And yes, x86 has had register renaming for quite a while - introduced with the PPro back in 1995. That doesn't mean hand-picked register allocation is useless, though.
For OS development, a few very tiny bits of code just can't be written in C - this is a very limited amount of code lines, though. You usually don't even need assembly code for driver development, since you'll be interfacing with your OS HAL layer.
If you're writing high-performance audio or video code, assembly can still have very substantial performance gains, though, since it lets you use the full CPU instruction set (MMX, SSE), which highlevel code generally doesn't. It's true that recent compilers can utilize SSE automatically, but even Intel's own compiler is inferior to hand-written code.
And if you start using instruction intrinsics, rather than depending on automatic use of SSE instructions, then I'd argue that you're actually writing (a bastardized) form of assembly... and the code generated when you use intrinsics can usually be sped up quite a bit by hand-tuning the register allocation by rewriting in - you guessed it - assembly.
An assembler assembles assembly code - you don't write "assembler code", you write "assembly code". Unless of course you're writing an actual assembler ;)
At least the other C++ compilers caught up (and then exceeded) - but it did take quite a while before Watcom was dethroned performance-wise.
You generally don't see that kind of commandlines for other assemblers, though.
And not being able to specifying output format on the commandline is kinda limiting - it can be quite useful to target multiple formats (omf/coff/elf) from a single source file. It's possible with FASM, but kinda mucky... requires setting environment variables and doing include "%TARGETFMT%.inc" - ugly compared to just specifying output format at commandline, or specifying a pre-processor symbol:value pair and acting on that.