I received this via private email and thought it was worth wider discussion.

quote:

As I ponder the configuration of a new telescope control and image processing computer, I was immediately drawn to a dual core only processor as none of the applications are really written to drive multiple threads over 4 engines. But then, I started thinking about how all this gets accomplished and I started to wonder if perhaps a 4-way processor might have value after all.

I’m assuming and am not positive that Windows dispatches code this way, but if it does wouldn’t 4 engines have the benefit of allowing 4 different programs pretty much exclusive executing capability? CCDAP running all the time on one engine, TheSky on its own too, CCDSoft on the third and the fourth keeping up with other OS things and/or background FTP transfers.

I realize that at 2-3Ghz, any one core could probably keep up with everything happening at the same time. Still, I was wondering…

Thanks,
Jonathan

Unless an application is multi-process aware, the only scheduling of processors is by the OS. When I first went to dual core, I found guiding was unafftected by web browsing, unlike with a single processor. So my guess is that multiple apps may be assigned multiple processors but I have no clue as to how this is done.

BTW, the next version of Mac's OSX, called snow leopard, is supposed to do the processor scheduling itself, which sounds like thread scheduling. That is a year away and it remains to be seen how that will work.

Other comments welcome, of course.

There is a setting called CPU Affinity that I think can cause an application to use a specific CPU. Not sure if in a multi-core system whether that is really necessary to cause the OS to spread all the different processes across all the engines. One would hope that the OS wouldn't try to execute everything on a single core and leave all the others idle....

Jonathan

quote:

There is a setting called CPU Affinity that I think can cause an application to use a specific CPU.

That might be useful for a shaky application with critical time sensitivity (like maybe a large video camera that needs constant attention else corrupted or droped frames result if/when the CPU is not paying attention, though I run a Firewire camera and it doesn't take that much CPU time). Otherwise I would not mess with that. The fact is that a single CPU core is often most efficient when it runs 4 or 5 worker threads and an app running on multi-cores will often have different threads assigned to cores or even core switched by the OS. You can see this by monitoring a single non-multi-threaded app in “Task Manager” (Performance tab) – the total CPU will be near 50% (less if I/O bound, slightly more if computational) and sometimes one of the processors will be 80-100% and other times they will each be near 50%. A multi-threaded app will use all available CPU (unless I/O bound).

CPU design is very complicated and sophisticated and unless you *really* know what you are doing you should just let the app and OS handle things.

The benefit of dual (or more) core for non-multi-threaded apps is the ability to run several of them seamlessly. For example, you can deconvolve in one instance of CCDStack while processing images in another instance of CCDStack.

BTW, future versions of CCDStack (in development) will be multi-threaded...

Stan

By the way, CCDIS registration plugin will create multiple threads, up to the number of CPU's available on the computer. Each thread is dedicated to a CPU.

Regards,

-Paul