Re: a dozen cpu's on a chip
- From: "Michael A. Terrell" <mike.terrell@xxxxxxxxxxxxx>
- Date: Thu, 15 May 2008 12:04:12 -0400
John Larkin wrote:
On Thu, 15 May 2008 09:14:43 +0100, John Devereux
<jdREMOVE@xxxxxxxxxxxxxxxxxx> wrote:
John Larkin <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
On Wed, 14 May 2008 19:50:42 +0100, John Devereux
<jdREMOVE@xxxxxxxxxxxxxxxxxx> wrote:
John Larkin <jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
On Wed, 14 May 2008 14:37:40 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:
On a sunny day (Wed, 14 May 2008 07:09:57 -0700) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<t8sl24dnv1gga7v38sormu0bvc6dd1eg3d@xxxxxxx>:
Dvorak has vague inklings as to what's going on:
http://www.pcmag.com/article2/0,1895,2129596,00.asp
Not really, first the 4 TB is full with HD recordings in a day or so.
Look up HD editing
'Clean disks?" whats he running windows?
You tube streaming o na separate core?
What a waste of a super fast powerful core.
Webcam? Even less bandwidth.
Twittering, blogs, yes you _REALLY_ need 10 extra cores for that.
The man is an idiot.
WHOAAAAAA!
And that Intel guy is a salesman.
Now that they are faster then AMD all of the sudden speed is important.
I have to admit that I was more pessimistic about Intel, but hey, maybe I will
be proven right once they have 80 cores with 70 idle..
So you and Mr Brown agree that computing has already reached its
pinnacle of perfection, and the trillion-transistor chips with
hundreds of CPU's will always run Windows, and the individual CPU's
will always multitask, because that's efficient.
Well, since absolutely nothing in technology has changed in the last
20 years, I suppose it's safe to assume nothing will change in the
next 20 either.
In most systems most tasks are idle - but occasionally you will need
to do something that takes a *lot* of CPU power. E.g. media
transcoding, recompiling the linux kernel, FPGA synthesis, video
editing, ray tracing.
Your "lots of little cores" scheme is not much use in this scenario,
since all the near-idle tasks could have been done in a single
multitasking core anyway, and the (likely single) heavy duty task runs
*really slowly* on one of your little cores.
What is actually needed is a single core that is just about as fast as
possible. Only when it runs up against practical limits is it then
worth going to 2-core, 4-core etc. And you can then rewrite the "heavy
duty task" to split itself over multiple cores. But the most efficient
scheme would still be to have all the lightweight tasks on one of the
cores, and the single heavy duty program spread over the remainder.
And this is what we have.
Of course this is what we have. But what will we have 10 or 20 years
out?
The GHz race is slowing down to a standstill; everybody is going to
more cores to get more mips per chip. The new PR race will be for
number of cores, not GHz.
FTTH is coming; soon a good hunk of the population will have gigabits
per second pouring into their houses.
Nanometer geometries are happening, but still with UV lithography. So
yields are going to suffer, and yields on a single-core CPU with a few
billion transistors won't be great.
Heat sinks probably won't get much better.
So, things will stay the same?
No, I agree there will be a move to more cores.
You seemed to be saying that the software complexity / reliability
problem could be solved by putting every process on a separate core. I
don't see the number of cores as being relevant to this. Current
designs already have available mechanisms for isolating processes as
much as desired.
"As desired" is the key phrase. Most of the industry seems to think
that means "pretty well, usually, it only crashes once a week or so".
I want it to mean "absolutely, it can't lock up." Programmers need to
be protected against themselves, ans the only real protection is
hardware.
And there will always be a need for processes to
communicate, so the problems of synchronisation, deadlocks and
resource contention remain whether or not you have a process-per-core.
So *design* all that into the hardware. There's certainly less
resource contention if there's lots of CPUs available, each with some
local memory and code cache.
Essentially, a massively multicore chip will be under-utilised if the
software only runs one task per core - unless the cores are so
underpowered that they cannot run the few computationally intensive
tasks well.
Nanometer transistors are fast and free. Quit worrying about keeping
them busy so we can get past using 50-year old concepts in a
multitask, gigabit world. The majority of guys here are adamant that
things will never change, a pretty radical position for engineers to
take. Newsgroups seem to attract that type.
At this moment, my PC is running 389 threads, on one CPU.
John
404 threads, and a 96% idle CPU. By their argument, that is wasteful,
too.
--
http://improve-usenet.org/index.html
Use any search engine other than Google till they stop polluting USENET
with porn and junk commercial SPAM
If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
.
- Follow-Ups:
- Re: a dozen cpu's on a chip
- From: Martin Brown
- Re: a dozen cpu's on a chip
- References:
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: Martin Brown
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: Martin Brown
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: Jan Panteltje
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: John Devereux
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- From: John Devereux
- Re: a dozen cpu's on a chip
- From: John Larkin
- Re: a dozen cpu's on a chip
- Prev by Date: Re: 3phase PFC
- Next by Date: Re: Probe for rise/fall time measurement of 1kV floating signal
- 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