Re: a dozen cpu's on a chip
- From: John Larkin <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 10 May 2008 12:41:10 -0700
On Sat, 10 May 2008 14:06:51 -0400, Phil Hobbs
<pcdhSpamMeSenseless@xxxxxxxxxxxx> wrote:
John Larkin wrote:
On Sat, 10 May 2008 00:04:22 -0400, krw <krw@xxxxxxxxxxxxxxxx> wrote:You mean something like Parallel PowerBasic, I gather? ;)
In article <9f2a24lb3qdd4fplttffo6oarcbgqc952v@xxxxxxx>,
jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx says...
On Fri, 9 May 2008 22:27:56 -0400, krw <krw@xxxxxxxxxxxxxxxx> wrote:You're making your scheduler's job more difficult and limiting
In article <3n6624pu6762nup9apu3crj5vh1uu6fqbn@xxxxxxx>,Why would you get an exception? If a device driver doesn't need fp
jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx says...
On Thu, 8 May 2008 07:42:04 -0700 (PDT), MooseFET <kensmith@xxxxxxxxx>Asymmetric multiprocessing makes the scheduler's life more
wrote:
On May 7, 7:48 pm, John LarkinRight. Amybe a few cpu's would have serious floating point power, or a
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=CESEX...When you get to large numbers of CPUs it seems to make sense to stop
I bet we'll see 256 one of these days.
making them identical. For servers this would be doubly so. Many of
the CPUs won't need to do floating point operations.
few separate fp engines could be assigned to cpu's as needed. Lots of
cpu's, doing stuff like file i/o or serial stuff, could be less
powerful. I suppose we'll always need special graphics hardware, but
just a few of those per chip.
complicated. Since the scheduler is part of the OS, and the OS is
most often M$, this isn't a good idea, IMO. ;-) Hardware is cheap
(so cheap PowerPC is including decimal FPUs). Throw the FPU on
every node, whether its needed or not.
Which negates what you say above. Running a task, then getting anIt also would make sense to do things like memory moves in the "MemoryNext step is to get rid of task swapping and threads altogether. One
Mismanagement Unit" since the values don't need to be modified on the
way through.
This will make it a lot harder to say how many CPUs are in a chip. If
there is only as much hardware as 200 full CPUs but 500 threads can be
running at the same time, do you call it 200 or 500 CPUs.
CPU is the OS, and one cpu gets assigned per process.
exception because you don't have an instruction you thought you had
is expensive.
opcodes, run it on one of the many cpu's that doesn't have floating
point. And vice versa. <> rocket science.
flexibility. Computer architecture is rocket surgery.
A bunch of cpu's don't need scheduling like a single-processor os
does; individual cpu's do their thing concurrently and set semaphores,
and go idle, if they finish whatever they are assigned to do. And
besides, the task manager cpu doesn't have anything else to do. The
scheduler will mostly set up things like memory management and
priviliges and assignments and turn them loose, rather than
frantically swapping them in real time. When everything runs
simultaneously, priorities become less important. It's a whole new way
of thinking.
The IBM Cell chip is an architecture that trends in that direction.
Current hardware and software has been driven by Intel's silicon
process skill (and their vicious lack of ethics) and by Microsoft's
thousands of programmers (and their vicious lack of ethics) but not by
any particularly intelligent planning. Most big software apps are
spinning-out-of-control crapware with gigabyte service packs just
pushing the bugs around. It's time for a change, for the next
generation of computing, and I think it will happen when there are so
many processors on a chip that multitasking quits making sense.
A new language wouldn't hurt either.
John
Again, for the 111'th time, I don't advocate parallel processing as a
way to get number-crunching performance. I advocate running a lot of
cpu's on a chip, one per process, as a path to system simplicity,
discipline, and reliability. It's high time we stopped worrying about
wasting transistors. The limit of computing per chip is thermal; which
transistors do it doesn't matter, so an architecture should optimize
reliability, and to get reliability we need to force some draconian
new rules onto programmers. They won't like it one bit. The resulting
os and architectures would be so brute-force simple that the academics
would hate it, too. Both groups have demonstrated their inability to
manage complexity.
The Cell is a SIMD processor, with a 1.5 Tb/s interconnect bus on chip.
There's a Power CPU that controls 8 Synergistic Processors (the SIMD
part). Some things run amazingly on SIMD machines, some don't. Crays
and other vector processors were SIMD, massively parallel machines are
MIMD. SIMD simplifies the architecture and the programming model, but
restricts the range of problems that can be tackled efficiently.
I think the idea of grouping cores with different specializations will
grow in importance, because it simplifies the programming model.
YES! Thanks for being the only person here who sorta agrees with me on
this.
John
.
- References:
- a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: MooseFET
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: krw
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: krw
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: Phil Hobbs
- a dozen cpu's on a chip
- Prev by Date: Re: History of noise (paper)
- Next by Date: Re: modifying a circuit design for a touch switch
- Previous by thread: Re: a dozen cpu's on a chip
- Next by thread: Re: a dozen cpu's on a chip
- Index(es):
Relevant Pages
|
Loading