Below is the body of code for a small DLL I'm writing. Where do I put the code? This is from Processor.cpp in VS2010.
// TODO: add construction code here,
// Place all significant initialization in InitInstance
// The one and only CProcessorApp object
// CProcessorApp initialization
Would you mind letting me know the result of the suggestions? If you need further assistance, feel free to let me know. I will be more than happy to be of assistance.
Jesse Jiang [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Out of curiosity, are you writing code to try to determine how many threads to start and run simultaneously in a multi-threaded application?
If so, what operating systems do you intend to run it on?
In developing a graphics-intensive multi-threaded app (datasets generally much larger than the L2 cache sizes) I found that in general starting the number of threads equal to the number of physical processors + 0.5 * the number of additional logical processors because of hyperthreading, but reduce the count by 1 if every physical processor would be used when there are more than two, seemed to be the best overall approach for running on a variety of old and new systems. VERY interesting to see the tradeoffs in performance in actual operation.
I sense you're going to have fun.
No, I left in 92 at the end of the 32 bit processors. I've never seen an Alpha believe it or not.
The local wisdom is not to exceed the number of processors with a greater nimber of threads and put each thread on it's own processor. This seems a little exhorbitant to me because Windows is a time sharing system. Whereas I understanf the concerns, I domt know why they set the thread ratio that low.
VMS never had formalized multithreading for it's 32 bit machines although it did for Alphas. So what I know about it I learned in the VB forum for Windows.
A valid concern. A dual 6 core system with hyperthreading will net you 12 physical and 12 additional logical processors...
Is this "local wisdom" you speak of Intel processor-specific? Not exceeding the number of physical processors doesn't seem to leverage the additional capabilities Hyperthreading brings to the party, and I can tell you based on testing that more processing gets done if you DO keep the execution units more busy via additional hyperthreading threads. Leaving half the hyperthreading thread slots free for the rest of the system to get by while the high performance computing task is going on seems to be enough to keep from interfering with the user experience and using them all up simply doesn't net that much more throughput (and sometimes less).
So in essence, a hyperthreading logical processor seems to be worth about half a real processor in additional performance. This seems to be a fair rule of thumb in Windows XP, Vista, and 7 with both the 32 and 64 bit instruction sets on various Intel processors.
- Proposed as answer by Jesse JiangMicrosoft community contributor, Moderator Thursday, July 21, 2011 6:32 AM