Not really - you're just slightly more likely to see any threading bugs
if you've *actually* got it running on multiple cores.

In most instances, the multiple core/multi proc set up may actually help you
notice bugs in your code, which is a good thing (and what Jon stated, albeit
in a more roundabout way). Provided you are coding threads properly, it
should not matter.

*************************************************

On the whole, the other replies are correct.  Assuming no bugs, code that  
is already multi-threaded should "just work" in terms of taking advantage  
of multiple processors.  However, there are some caveats:

    * Probably the biggest one may not be very relevant any more, with  
Hyperthreaded CPUs not being a big thing anymore.  But if you've got an  
algorithm that parallelizes in a way that makes heavy use of local  
variables (e.g. a recursive algorithm), naive multithreaded code on a HT  
process can make performance much worse, rather than even the modest  
improvement one might otherwise see.  The virtual cores on a HT CPU share  
a cache, and when you've got multiple threads aliasing cache lines because  
their stack lives in the same offset within the cache, you wind up setting  
up a situation where the threads are trashing each other's cached data.

    * If you are multi-threading as a way of getting performance, as  
opposed to it simply being a architectural "simplification" (yes, writing  
multi-threaded code can actually simplify the design, even as it  
introduces the new complexities related to multithreading), then you  
should be careful to not have too many threads.  In an optimal situation,  
you would have exactly as many threads as you have CPU cores.  In reality,  
you might want a handful of extras, especially if your algorithm involves  
some i/o.  But going too far beyond that may result in inefficiency as you  
switch from one thread to the next (though for completely CPU-bound  
algorithms, this inefficiency should never be huge).

    * Even on a single-CPU system, multi-threading _may_ improve  
performance, if your algorithm is i/o-bound.  Having multiple threads  
ready to process i/o results when they complete can be very helpful.  If  
you can use an IOCP-based mechanism, even better (but I don't know in .NET  
which async mechanisms do this, except for the Socket class which I know  
does), since using IOCP you have one thread per processor (or thereabouts)  
that can handling i/o completions for some arbitrary number of tasks.

These are just a few things to keep in mind.  In reality, getting the best  
results from multi-threaded code on a multi-processor system is  
non-trivial.  It's a good idea to try the naive approach first, but you  
should at least be prepared for the possibility that something may thwart  
that approach.  Multiple threads and multiple CPUs introduce some  
non-intuitive behaviors (or at least, behaviors that are non-intuitive  
until you've been doing multi-threaded code for awhile :) ), and so if  
something doesn't seem to be working as you expected it to, don't worry.  
It probably just means there's one of these non-intuitive things getting  
in your way.  :)

Pete