dumber ram question

I'm going to custom build a compaq and get it with the minimum ram once I'm sure the computer works then I will upgrade. Will it work with a 256m in one slot and a 1024m in the other. Is there any way to monitor how much ram a program uses and can you control which programs use which ram slots? If it turns out to be a fiasco I can always add 1024m later.

 

As far as I know there is no way to control which DIMM a program uses. If you want to check how much RAM a program uses, go into the task manager (right click on taskbar, or ctrl+alt+delete) and click on Processes and you will be be able to see how much memory & what kind of CPU utilization the program is using.

 

256 MB in one and 1024 MB in the other will work just fine. You can monitor how much RAm you are using in total in the Windows Task Manager, and you can also see how much each program is using, if you click on the "Processes" tab.

 

When quad cores become common even people on this forum will balk at getting 4 gigs of ram. What would be nice would be to optimize hardware and software so that say a ram hog program would have a one gig chanel to itself and the other cores would have say two 512 meg chanels and a 256 meg chanel. This would keep costs down by not buying memory you seldom use. Perhaps processors could have different L2 caches for each core also.

 

As mentioned, 1.25 GB of RAM will work fine the way you described. You can monitor RAM usage by using the Task Manager.

You cannot determine which DIMM is used for programs, though.

 

Uh, why? Why not just let all the cores share the same RAM? (Which is what happens normally)
That gives you much better performance, and the ability to actually distribute CPU load across cores. (If each core had separate RAM, you wouldn't be able to run multithreaded apps on more than one core, in other words you might as well have bought a singlecore system)

AMD's quad-core do have separate L2 caches, but shared L3 cache. I fail to see your point though. If each core was isolated from the rest, you'd have 4 single-core systems, not one quad-core.

The point about a multicore system is that all the cores *share* resources. They have the same memory space, and can share data, run the same programs and so on.

 

Restricting a given core to a given amount of RAM is not a good point. But I really like the idea to limit certain programs to some maximum amount of memory. Thus, Microsoft Outlook will not take 150mb+ of memory when I leave my desktop on for a week or so.
Anyone knows of such a program?

 

The new computers have a dual chanel memory if we let a program use both chanels then there will be a conflict with a program running on another chanel this means the dual chanel runs no faster than a single chanel memory. Of course we could let a program use all of the memory if no other programm is running.

 

Your computer is much better at optimizing itself than you are. I promise There aren't any ways to limit how much a program can allocate though, as far as I know. If your program is eating too much memory, get a new program. "dual-channel" can be faster if the memory is split between the channels. There's still only one channel running to the processor, so what dual-channel tries to do is speed up access by distributing loads between the two chips. There's is no "conflict" between which DIMM a program uses, and you will just end up slowing down everything if you try to limit one process to use of a single DIMM, even if it were possible.

Take some computer architecture courses... it's enlightening. All I can do is put on my "Expert Engineer and Computer Scientist" hat and say that what you're proposing has been thought of, and discarded for a more efficient model. Your computer runs hundreds of threads, and tens of processes, all the time. They need to be in RAM somewhere, and letting the computer optimize those locations and so on is the only way to do it efficiently in a general-use computing situation.

 

You like the idea of crashing programs? Yes, it's called task manager. Just right click and 'end process'

If an application can not get the memory it requests, it crashes. The entire point in pagefile and virtual memory is to be able to service multiple programs with the same computer and the same RAM.

What you're asking makes about as much sense as restricting a car to only two wheels, to save wear and tear... The problem is that the car won't run because it you've taken away the resources it needs. Same thing with programs. a program that can't get the memory it needs, has no alternative but to shut down.

Wheew, there's something you've misunderstood.
Dualchannel simply means that there are two "lanes" for accessing RAM, which in turn means twice the amount of data can be transferred between the memory controller and the RAM. It makes no difference to the CPU. It doesn't say "Please sende this chunk of data on channel 1. It simply sends a chunk of data to the memory controller, and the memory controller makes sure it's sent to RAM. It might be split across both channels, or it might be sent on one or the other. You don't know, and the CPU don't know the details of that. It's just done automatically. There are no conflicts whatsoever. Each core just sends requests to the memory controller, which queues them up and executes them, and hands the result back to the core that asked.
There are never any "conflicts" because no core and no thread ever "owns" a memory channel. Each core just requests and sends packets of data to the memory controller, and that's it. The application, or even the OS or the CPU itself, are unaware of exactly *how* it's communicated between memory controller and RAM.

It might help to look up what virtual memory is.
On any modern PC, the application does not have direct access to the physical RAM, and it doesn't know exactly where its data is stored. The CPU can handle 4GB memory normally, but less might be installed, and multiple applications have to share it.
So the OS "emulates" a full 4GB address space for each process. That is, each process believes it has 4GB of memory available. That doesn't mean it is actually *given* 4GB of memory, just that it can address that much, and it expects to be able to allocate that much *if it has to*.

Then it's up to the OS to shuffle things around to make everything fit. While every application thinks it has 4GB of memory to itself, few use more than a fraction of that. Which means that the OS can keep up the illusion as long as no process tries to actually grab all the memory for itself.
The OS uses the pagefile to assist with this task, because it might need to hand out more memory to running processes, than is actually available. So the pagefile is used to store memory contents that haven't been accessed in a while.

So, as long as everyone plays nice, it works, and the illusion that each process has its own 4GB of memory is kept up. This frees the programmer from having to worry about "what if I run out of memory? How can I emulate a pagefile myself, to unload data I don't need right now?"

It also makes it possible to run multiple processes at the same time, because they each are under the illusion that they're alone on the system. They don't have to deal with "these memory addresses are in use by a different process" because, the OS makes sure to translate all memory addresses from the virtual addresses the application uses, to the physical memory addresses that represent the actual RAM.

What you two are proposing is basically to tear down the OS and replace it with something like DOS. Something that doesn't provide those abstractions for the programmer, makes multitasking impossible, and basically, is not an operating system.

Instead, you both simply have to do the following:
- Trust that the OS will arrange the memory so that there are no problems. Unused data will *not* hog the RAM. Even if Outlook takes 150 MB of virtual memory, it does not prevent your RAM from being used. Outlook is mostly just idling doing nothing, which means its allocated memory isn't used. ANd that means that as soon as the OS runs out of memory, Outlook's data is at the front of the queue headed for the pagefile. Which again means that those 150MB of RAM are freed.
- Alternatively, use a different (better) program than Outlook. Something at uses a sensible amount of memory, perhaps?
- Realize that the actual RAM and the physical memory configuration is completely invisible to running applications, and to some extent, even to the OS. There are no "conflicts", threads do not fight over memory channels (because threads do not *access* the memory channels and are not aware that they exist). And vice versa, the memory channels only exist on the memory controller, which isn't even aware that there is such a thing as a thread, or that each CPU core has some kind of master plan with the requests it sends. The memory controller just handles the requests it receives, one by one, regardless of where it came from.

 

That's actually 2GB. There's a split between kernel-reserved memory and application memory (the system maps in system addresses), so the kernel gets 2GB and the app gets 2GB. See this for a little more detail. Unless you start Windows with the /3GB switch (which brings it's own host of problems), your application only has up to 2GB of memory which it can allocate, though it can access up to 4GB.

Great explanation for the rest of the VM and memory subsystems, though.

 

Yes and no. The application still has a 4GB memory space. Windows just won't allocate more than 2GB memory to it. But again, that just means that the application "thinks" that it has 4GB available to itself. Reality and Windows can and will interfere before it can allocate that much, but that was my point. The application is living under an illusion and isn't even aware of how much memory it can actually get access to. Each process lives in its own little world, totally unaware of what else goes on on the system, and the OS maintains the illusion that the process has access to all the resources it needs.
Because writing software is hard enough as it is... Having to deal with this would make it impossible...

I was trying to keep all the complications and special cases out though, to avoid more confusion than neccesary.

So much for keeping it simple...

 

Sure it's aware. If you try to malloc() too much memory, an exception is thrown that says "you can't grab that much memory". Some programs handle that gracefully, others throw up all over themselves It may have 4GB of address space available, but it can only allocate up to 2GB and then it gets that error. Only if you insist on directly accessing memory locations do you see that you have 4GB "available", and if you're doing that, then you should be well aware of the limitations and so on when programming it. The "illusion" is only that you have a full 32bit variable to address memory with which can address up to 4GB of address space. I think we're both saying the same thing, but the way you stated it, it appeared like an application could allocate up to 4GB of memory and be perfectly happy, which is not the case. The OS denies allocation as soon as the application tries to go over 2GB (or 3GB if you use the right version and startup options). Hence, the 2GB memory limitation.

 

Hi everybody,I have a question (for those who knows of course).
The "dual channel" works only if both memory are the same brand?
I have 2 memory on my notebook (Samsung 512Mb PC4200 and Sycron 512Mb PC4200) so i wonder if those can work on dual channel,or I have to change the second?
Actually....can anybody explain to me the concept of "dual channel"?
Thank you very much,re5pect,Danutz.

 

Dual Channel is just a technology that effectively doubles the memory bandwidth available to the system. This, in theory, is supposed to help the chipset and the rest of the system, to retrieve and send data toand from the memory in larger bits, and effectievly make transfer faster. However, it doesn't eally help out all that much.

You may be able to use those two modules in dual channel, but normally they are modules from the same brand. It may or may not work. Hope this helps.

 

Hi Zero,thank you for reply. Somebody told me that it will work only if they are both the same brand,the same size,the same frequency.How can I check if is working or not in dual?
10x a lot.

 

So they're not aware. They only really find out when it's too late. When they've tried to allocate more memory than the OS could give them. But generally, they just work from the hope (and expectation) that the OS will be able to give them the memory they need.

The point is, I could write a program that tried to allocate 3GB memory, and it'd compile. Nowhere in the compiler's output would I see "You can't allocate this much".

I'd only find out when I ran the program. Or more likely, I'd write a program that allocates smaller chunks of memory, but does it regularly. At some point it might have exceeded 2GB. The program wasn't aware that "Next allocation is going to break the 2GB limit", and nor was I as a programmer.

I meant it could *try* to allocate 4GB. There's nothing stopping it (other than the exception that'd be thrown when the OS can't do it)
That's the illusion. The program doesn't know in advance that "I've only got this much memory to play with. If I allocate so and so much, everything will crash". It just allocates what it needs, and as long as it doesn't go completely crazy, that illusion will be maintained, and the OS will be able to give it the neccesary memory.

But yeah, we're basically saying the same thing.

As for dualchannel, all that's really required is that they're both of the same size. After that, they should run at the speed of the slowest stick (slowest common timings and slowest common frequency).

So it *shouldn't* be neccesary to have them of the same brand. Of course, it's hard to make any guarantees. There may be some cheap budget chipset that can't handle if the sticks aren't *exactly* identical, but usually it should work as long as the two sticks have the same size.