We have not announced anything more specific than needing a 64bit OS and DirectX10 video card.

That is a dual channel board, so getting just one will decrease performance, as even what you have already will be forced down into single-channel mode as well. You will want a matched pair, if anything. At that though you will only see any gain if you can actually use more than your current maximum at once.

From my understanding that running several programs at once causes you to more memory that is not on the game, and slows down your computer. Any program that you do not need to do anything prysical with should be shrunk down to your taskbar until you need to do something with.

We have not been given any idea how much memory GC3 is going to need. Adding 4G may be more than you need, or it may not support the largest galaxies the game will support. Until StarDock gives us some figures, you may wish to add 8G, just in case (If you can afford it, and your PC can handle it).

"Closing them to the taskbar" is not really closing them. It is minimizing them (i.e., moving them off the desktop). Minimized programs still take up resources; like CPU cycles (unless they are idle), and memory (mostly swap file space). 

Multitasking and multiprogramming are operating system capabilities, you either have them (Windows does) or you don't. You don't avoid them.

In the manner you stated, memory is not shared, it is allocated. The OS is responsible for making sure memory does not accidentally get allocated to more than one address space. Yes, different programs can "share" memory, but this is very different from what you imply. The programs have to know exactly what they are sharing and have to authorize each other (through OS facilities) to share memory, and this is relatively rare.

This is another very common misconception. The truth behind this is that if you don't have enough RAM for the load you are putting on your PC, the OS will start page swapping (moving a less used page of data or code onto the swap file to make room for the page of data or code being accessed). The more overcommited the RAM gets, the higher the swap rate gets, and the less work the programs can do (swapping takes CPU cycles and IO reads and writes, which interrupts the programs affected). Adding RAM when this is happening will reduce the swapping, which will give the appearance of improved performance, which leads people to believe that "the more RAM you have the faster the computer runs". But this is only a situational appearance, not a factual rule.

All programs use virtual memory. A program asks the OS for a quantity of memory, usually many times. Unless the program specifically asks for "Real Memory" (memory dedicated to RAM and can not be swapped) the OS will map Virtual Memory to the program's address space and tell the program what it's virtual address is. It is a very rare and privileged program that will ask the OS for direct access to "Real" memory. Virtual memory is mapped by the OS to one of two or more resources, the first of those resources being RAM and the remaining ones on disk (I am pretty sure Windows has only one disk space for this, the swap file).

Any OS with Virtual Memory capabilities manages Virtual Memory in chunks called pages (usually 4K bytes per page), and decides which pages should be mapped to RAM and which to the swap files, and "swaps" pages in or out as needed, making room for the pages being used more often by swapping the less often used pages out to the swap file.

The only direct memory limit imposed by the OS (and the computer hardware) on the game (or any other program) is the size of the address space. For a 32bit addressing program, this is 2G (actually only 31 bits are used for addressing). 64 bit addressing is many magnitudes greater.

The game can easily exceed the RAM available and keep functioning. That is what the Swap file is for. The amount of RAM mapped to the game's address space will constantly vary depending on how much virtual memory the game asks for and how much of the game's virtual memory is swapped out. The only concern here is how much swapping has to be done in a small period of time to keep up with the processing of all of the programs the OS is managing, which can impact performance. This is the criteria that should be used for choosing which programs to close to reduce the load on the available RAM or when to add more RAM to the computer.

The speed of RAM is always the speed it was manufactured for. The slowing of speed to your hard drive speed that you may see is the result of how much and how fast the OS has to swap RAM to the Swap file. Also consider that if a virtual address is accessed by the game that is resident on the swap file (not in RAM), the OS has to find a page of RAM to write out to the swap file, then find the page the game tried to access and read that page into the vacated RAM page, before the game can actually access the data in that page. That is three accesses to the RAM page and two I/Os to the hard disk.

I am sitting here looking at what I have just entered for this reply and trying to think of a simpler way of answering your questions, but am not finding any. There is a lot here that goes much deeper into the details of the hardware and the OS, but I really don't think this forum is the appropriate place. I hope I have answered your questions well enough for you (and anyone else that needs it) to get a general idea. To go any further in detail would require several college courses in computer engineering and operating systems programming.

I still have to proof read this reply, but my time is constrained at the moment. I will review it later and make more corrections as needed.

EDIT-> Sorry it took so long to get back to proof read this, but I think I have it all stated as I intended to. I hope, Willy, that it helps you to understand what is going on a little bit better. As I said earlier, the subject is quite complex and can take years to learn, especially if you try to learn it from both the hardware and operating system aspects of it.

Sorry it took me so long to get back to you.

There is some truth in this at a superficial level, once the number of programs running exceeds a threshold (and this can be a very arbitrary threshold).

In Actuality, the computer does not slow down. It just has more work to do, and the programs may be competing for the same resources and that will slow down the apparent rate at which programs will complete their tasks.

Competition between programs for access to the content of the hard drive is one of the biggest bottlenecks you can run into, the one that will slow down the running programs the most. Only one I/O operation can be done to a disk at a time (this is an argument used for having more than one hard disk, but the cost benefits on a personal computer really doesn't support having more than one hard drive for most of us).

Another bottleneck can be the number of programs running exhausting the supply of RAM pages, which causes page swapping, which also adds demand on I/O operations.

I think it is unfair to put the onus for this problem on the hardware. This is really a case of the support the OS has for multitasking and multithreading. Also, if you are running only one or two programs, ones that are not programmed to take advantage of multiple tasking or multiple threading, at the same time, then the OS will rarely use the entire multiple core/thread capabilities of the CPU chip. You might be able to display the core/thread usage with the resource monitor that comes with Windows. GalCiv 3 will be coded to take full advantage of multiple core/thread CPU chips (this was not announced in so many words, but it is there if one knows what to look for).

No. Lets see if I can clear this up.

RAM can be, but rarely is, accessed directly by programs, and only after getting it allocated via a privileged call to the OS. The rest of this dialog will ignore such programs.

Each program currently running has its own address space, containing pages of code, data, and unallocated space. RAM is used to back pages of virtual memory allocated to programs when a program asks for memory in which to place its code and/or data. All a program knows is the virtual address of the memory block it receives from the OS.

The OS keeps track of where every page of virtual memory in all of the address spaces currently in use is. They can be in RAM, on the swap file, or unallocated. When RAM is exhausted, pages of virtual memory gets swapped to the swap file by the OS (a "least used" algorithm is usually used). The program doesn't know this has happened. But, a program can not access code or data that is not in RAM. When the program tries to access anything on a page that has been swapped out, the OS finds room in RAM to swap the page back so that the program can access it again. The program is totally unaware of this action by the OS.

So, the game will use RAM, but only indirectly, through the maps and tables the OS and the hardware shares that shows where the virtual pages are backed. Does the game know the RAM address of the page it is accessing? No. It only knows the virtual address. When the game accesses the virtual address, the hardware will, using the tables provided to it by the OS:

1). translate the virtual address to the RAM address within the RAM page backing up the virtual page.

--OR--

2). signal the OS that the virtual page is not in RAM. When the OS receives this signal it will either; for swapped pages swap the page back into RAM (which might require swapping another page out to make room) and adjust its tables accordingly, or, for unallocated pages, terminate the program with an addressing exception.

Sorry for describing this two ways, but I hope one description or the other helps to better understand what is going on.

I really don't think this forum is the proper venue for this, but sometimes I just can't help myself when I see that someone is obviously confused, so I jump right in. My apologies to everyone who wishes I hadn't done so. And I hope that more than one person benefited from this.

I have a hard time believing you're as old as you say. Not every day you see an older person this well-versed in computers.

There are a few of us around. There would have to be when you consider that electronic computers were first built in 1946.

Retired programmer, yes. Operating Systems Design and coding, yes. Computer hardware installer, maintainer, and upgrader, yes (1963 - 1972). Game programmer, no.