Intel Core2Duo, for example is supposed to have a single die but two cores.
So, it should be possible to control what is processed on which core, which means that it is possible to instruct my algorithm to use the two cores in parallel.
The question is how?
Do I need to go down at the kernel level to do this, or is there a simpler way? To be more concrete, what does it take to implement a dual-core-merge-sort?
Judging by your past questions, I'd say you're looking to implement in C/C++, but I believe the answer is roughly the same regardless of language.
If you want to parallelize any operation, make it multithreaded. You can have as many parallel, concurrent threads as you have cores.
Here's a related question: http://stackoverflow.com/questions/1604991/how-to-implement-divide-and-conquer-algorithms-in-c-using-multithreading
As I understand it, binding a particular thread to a core or processor is called processor affinity. It's generally not a good idea, because the purpose of the operating system is to juggle threads between processors. It's unlikely that you'll do a better job of this than the OS can.
I hope you are looking to assigning threads to each of the core .. This is a detailed description of what can be done and how to do it.
Hope this helps.
A Specimen of Parallel Programming: Parallel Merge Sort Implementation. And here is one in Erlang. For more precise answers, you have to ask a more precise question.
To implement an algorithm that takes advantage of multiple cores, consider OpenMP.
Of course, algorithms that have strong data dependencies may not parallelize well.
It depends in what programming language you want to achieve this. For example for:
Python - use multiprocessing or parallel python lib.
C#/.NET - use parallel framework for multi-core apps.
newLISP - just use spawn()/other stuff for same goal.
C - you may use POSIX threads and such
etc., etc., etc....
Just choose language and look for parallel processing abilities in that language.
Good luck!
While POSIX threads (pthreads) are probably a good idea to start, this is not exclusive.
Multithreading in C isn't actually trivial, hence, I'd advice fork().
start one worker fork for each CPU with a subsection of you'r mergesort algorithm, and then reassemble them in the manager fork.
When working towards a parallel solution, I consider forks before threads, since they're easier to implement, and you get a quick preliminary result. Once that works, you might want to take some time and work with pthreads.