--- In
guide-user@yahoogroups.com, Bill J Gray <pluto@p...> wrote:
> Hi Paul,
>
> I _think_ that to be multiprocessed, the app has to be written
> such that execution threads can be handed from one processor
> to another. As far as I know, the various flavors of Windows don't
> subdivide processing below the thread level. (Anyone care to
> correct me on this? I'm really not familiar with dual-processor
> setups.)
>
That's correct. The windows scheduler operates at the thread level,
so in order to use both CPUs of a dual processor machine, an
application has to be multi-threaded.
It's not immediately obvious to me how an application such as Guide
(or my own SkyMap) could make effective use of multi-threading, since
by and large the computations which need to be done to draw a star
chart are sequential rather than "parallel" in nature. SkyMap
actually is multi-threaded, in that it has a separate thread which
handles the serial port for telescope communications, but that's done
purely for ease of programming, rather than any efficiency gain on a
dual-processor machine - the CPU usage of the background thread is
trivial, since it spends most of its time in a "blocked" state
waiting to be woken up by a character arriving at the serial port.
With the speed of modern PCs, I suspect that for most people
performance is no longer really an issue for star chart generation.
Certainly on my fairly pedestrian (by modern standards!) 750MHz
machine both Guide and SkyMap draw charts in a small fraction of a
second; once you get to that stage it seems somewhat "academic" to
want more performance. (It seems like a long time ago that I was
using a 16MHz 386 machine, and I was thrilled when I managed to get
the computation time for a typical star chart down below 1 minute for
the first time :-) ).
Regards,
Chris