He's forgetting dynamic memory management with malloc. In this case, the kernel has to keep track of which blocks of memory are free, and assign bits of memory to processes as they request them. Keeping the free memory together in one block and not letting it get too fragmented is very difficult, and kernels can differ a lot in how efficiently they handle it.

Alex

As I said before, the compiler determines how much memory (to be specific, STATIC memory) a program will request and when, but the kernel determines where this memory space comes from and if it actually gets it.

Take a C program that has a link list where memory is allocated dynamically. The smart programmer that wrote it makes sure to always check the return value of the mallocs when adding a new node to the list. Why? Because it is actually possible for the return value to be NULL because the kernel said it couldn't have any more memory. An example of this in action: back in my college days they put max memory usage on processes coming from our user accounts on the solaris server machines because previously people had killed the system when programs with large dynamic structures went out of control and sucked up MB's worth of memory while the students scratched there heads wonder why it wasn't working. Multiply this times 4 sections of 250 students and you run out of memory pretty damn quickly even when you have 4GB worth per machine.

I am not going to say the compiler has no part in memory usage since a smart compiler could do some optimization to the program code at compile time but there are a lot of things to do with memory usage in complex programs that just can't be determined until run-time and the kernal ultimately takes charge of all of that.

You seem to know more than your friend. The operating system, loads your program into memory. As well as all the data when it starts. It also handles all dynamic memory allocation while the program is running. Overall though, the differences between 2k and xp's mem. mgmt are probably slim to none. So I wouldn't pin the speed difference between those OSes solely on how they manage memory.

However... (pulling this out of my ass) XP is a lo more bloated. I imagine an OS where lots of little "extra" programs are constantly being unloaded and loaded (ie. XP) has a lot greater chance of memory being fragmented than one without.

Based on the quotes you provided, your friend clearly doesn't know what he's talking about... a compiler is no part of the OS in the first place.

Idiot who posted this is putting words into my mouth. I did not say 90% of the stuff he claims I did.

How this started was I said that there was a speed difference between different operating systems (IE XP is slower than 2k, which from personal experience is VERY true). He said that no, there is NO speed difference, that its just MEMORY USAGE. Not memory management. He changed his argument to "Memory Management" about 4/5ths of the way through.

So lets clear things up. I in no way claimed that one OS was faster than the other "simply because it was faster." Thats utter bullshit. The fact of the matter is, there are MANY things that affect the speed of an OS, and memory USAGE (read, usage, not management) is a fairly small part of it so long as there is always enough physical RAM left that other programs can use. Obviously it'll take longer to load if it uses more memory, but if it handles things efficiently then it won't be much a performance hit.

Another thing is, he is trying to claim that programming algorithms (speed vs memory usage, thus efficiency) has NOTHING to do with Operating Systems. As though Operating Systems were spawned and not programmed, magic and not logic.

I advise you ignore him from now on.