Generally you will not notice the effects of putting particular processes on particular cores as Windows is generally pretty good at scheduling items between cores, especially on Windows 7 which was designed with this kind of thing in mind.
I have found that in general a busy task will spend most (generally >60% for normal apps and >95% for single threaded games) of it's time on one core and Windows will schedule other tasks on other cores as things get busier so I wouldn't worry about it. I seem to remember reading that windows 7 is able to tell which cores are "preferred" in a system, so on an Intel system that uses their Turbo Boost feature (which uses the activity on the first core to tell if it needs to boost) and Hyperthreading then Windows will tend to schedule single threaded tasks on the first core and then multithreaded tasks will preferentially be assigned to the "real" cores before the hyperthreaded "virtual" cores. I've seen this at work on my i7 (quad-core, 8 hyperthreaded cores) and it works pretty well with games almost exclusively using the first core and then moderate use on the alternate "real" cores.
The only time that I find specifying the affinity to be useful is when watching video using certain media players that are multiprocessor friendly but seem to have timing issues. Mediaplayer Classic Hometheater Edition seems to "jump" quite a lot when you start skipping forward in a video, presumably because it is using multiple threads to decode and they aren't well synchronised across cores and in that case setting it to only use one cpu stops the jumping.
In case you do need to change CPU affinity there are a couple of tools:
Runfirst helps to fix older programs by making sure they only run on the first cpu available in the system.
This review on Toms Hardware has a tool that will automatically reassign task affinities for you, but the link they have seems to be broken, and it appears to be a bit difficult to find these days. I think this program has to be kept running all the time you want it to be assigning affinities. Looks like you might be able to get it here
In general though I do not think you will see any real benefit to manually assigning affinities and I think the practise has pretty much died out as software has gotten better.
I would honestly expect that 8GB of ram would be more than enough to suit your needs, but I've no real experience using the tools you are using. I can say that on a 6GB system I have never had the system feel slow due to hard drive thrashing when I've been running multiple virtual machines and an IDE (eclipse) running...
You have a CPU with hyperthreading technology. You can't change this, but don't worry, you won't have any performance loss; actually it increases your system's performance.
Note that the CPU clock is not equal to CPU performance. The clock is not divided by two for two threads.
Update/conclusion: As already mentioned in the comments, in some (most?) BIOSs it is possible to turn off the hyperthreading. But that will not bring any performance enhancements, due Intels thread management is intelligent enough to use only as much as needed.
Best Answer
Operating systems use the concept of processes and threads for running programs.
When you load a program, a process is created. The process has its own memory and credentials and that process can only read/write to its own memory and do through the kernel whatever its credentials allow.
On a single CPU system, the OS goes through each running process and gives it a portion of CPU time, round robin. Only one process actually executes in a given instant of time. (If a process is waiting or "blocked" for I/O, a very common condition, it is skipped.)
A process can split part of itself off as a thread. This is essentially two parts of a single process having two separate turns on the CPU (all of a processes threads "live in" the process and can see its memory).
A process can also
If there is more than one CPU core, while a process begins on a single core, the OS can place its threads on other cores, and if the process spawns or forks other processes, it can place them on other cores than the parent process.
The OS manages which cores it uses and might even transparently migrate processes to different CPUs from time to time to keep things balanced. On Windows and probably Linux you can pin CPU "affinity" so it stays only on specific cores if you wanted.
So, if the application spawns threads and/or processes to accomplish its work, it will benefit from multiple CPU cores. If it doesn't, that specific program will not. Your OS will still be assigning other programs to other cores, so it can mean other programs will have less of an impact on your single-threaded single-process program.