Re: Multiprocessor Core


randyhyde@xxxxxxxxxxxxx wrote:
>
> Actually, I was referring to my comment...

Sorry :)

> But that pretty much forces a process to run on one CPU only and makes
> load balancing an expensive task. Ideally, processors can execute
> programs from any memory location, so a CPU can be assigned to an
> arbitrary execution thread. If the process is sitting in memory that a
> CPU cannot access (e.g., the block of memory associated with another
> CPU) you either have to spend time moving data from that block to your
> CPU's block, or you have to leave the process frozen while the CPU is
> busy, even if other CPUs are available.

Well, yes, and that works pretty neat for drawing and spread***
applications.

> I have one work for you: NUMA (which is actually *three* words:
> non-uniform memory access). There has been a lot of research into this
> area. But most of the research is in the area of OSes and how OSes can
> coordinate the execution of processes when executing out of one memory
> location is more expensive than another.

When they share something, it will always get slower and more
complicated/unstable (but cheaper!). The price is the main obstacle
here. Theoratically, there's no problem to make x100 faster megacore
CPU, but the price will be unaffordable for a common consumer. Another
question is, do we need faster microprocessors, or is current speed
already enough? (for desktops). The corporate clients surely may be
interested in new faster servers (there is also some saying that
multicore eat less electricity, so practically it's cheaper to have one
multicore CPU than several independent machines).

.

Quantcast