>>I wasn't concerned with speed that much - just wanted to know whether the load would be spread.
>
>Yupp it should. But make sure the "load" mostly taxes the cpu, or you can have contention on already bottlenecked parts: 2 processes querying a table via phone line won't help<g>. In the very worst case you might actually slow down compared to processing singlethreaded if you tip caches already running near capacity over into thrashing. Happened on relatively memory starved machines on disk intensive routines - but is the exception and not the rule. I am sure both of you can visualize similar scenarios, even if I don't get into detail here.

Sure, we're talking about processor load only, of course, since everything else is pretty much shared. I had in mind the typical scenario with VFP web apps, where you'd offload the creation of lengthy reports to a queued exe, so the main app running the web server wouldn't take too long to respond. I assume these two would naturally go to different cores (or should be tweaked to do so if they don't by themselves).

But as you say, we can have various scenarios here, including the fight between the twins.

>There are WINAPI calls to get/set Process- and Threadaffinity. When I first used X2 cores the patch for high perf counters was not available, which gave my timing scenarios a nice random element <g> and I sometimes set the process affinity via the task manager manually. After the patch I did not bother to implement the API calls as my manual setting did not change overall performance markedly.

Seems to be one of those things where the automatic settings are too good to tweak, i.e. the time wasted on tweaking and testing never materializes in a serious performance gain.