Re: A chip too far? Where is your solution Mr Larkin?
- From: Jan Panteltje <pNaonStpealmtje@xxxxxxxxx>
- Date: Tue, 19 Aug 2008 15:57:50 GMT
On a sunny day (Tue, 19 Aug 2008 08:24:56 -0700) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<11pla49cjbncqm5kso6h6pmil38tt60q25@xxxxxxx>:
On Tue, 19 Aug 2008 15:07:51 GMT, Jan Panteltje
<pNaonStpealmtje@xxxxxxxxx> wrote:
A chip too far? Where is your solution Mr Larkin?
http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortune/index.htm?postversion=2008081405
Blowing in the wind, all blowing in the wind.
1. A new programming language, accompanied with a new way of teaching
programming.
2. A new OS, which uses a nanokernel approach and wastes processors in
the name of reliability.
3. Ultimately, a new multicore cpu architecture that exerts much more
hardware control over the things that programmers tend to screw up.
The current generations of languages, programmers, methods, and OSs
are relics, and they don't scale.
It will take a long time to fix things, because the current computer
culture - academics, programmers, cpu makers, Microsoft - will fight
for its survival.
John
No, I can only very partly agree.
Starting at the end, it now seems survival is for those who solve this
problem first, in the widest sense.
I would expect MS and others to know this, they are investing into research
into this.
As a second point, 'maybe' just 'maybe' the multi core approach is the
fundamentally wrong one.
In an other thread FPGA's rising over DSP's diminish is mentions.
Sure, with so many gates, and reconfigurable logic, some
parts of sequential programs are better done in FPGA then smearing out
over many cores, my personal experience with this is fast DES.
As mentioned, in (3), I did mention this earlier in an other posting,
it is very difficult to use a CPU for each thread, and, as the article
on CNN says, it is very difficult to get 9 women to
give birth to one child in 1 month.
I had an old boss, he would ask, 'How many more men do you need to
do this within 2 weeks (as opposed to 3 month).
I had lengthy discussions about communication between workers being
a factor that could slow things down (as bottleneck).
Sure, the joke goes:
How many Belgians does it take to screw in a light bulb?',
and the answer is: 5, 1 to hold the bulb, and 4 to turn the ceiling.
But something there says it all.
Perhaps when we use FPGA as supplement to a sequential processor (where extra
processors can be configured in hardware too), then we can gain speed.
I fail to see an universal way to slice any sequential problem to a
parallel one.
But _if_ you do, you can become world famous, extremely rich, so
I'd say: Call MS or IBM :-)
So, blaming it all on 'programmers' is a bit silly (with all respect).
the first programs were hardwired anyways, blame it on the hardware guys...
The best way to optimise for speed, is to see where the system spends it time,
and tackle that bottleneck, if must be put a FPGA there, not add yet an other core,
with its communication issues.
.
- Follow-Ups:
- Re: A chip too far? Where is your solution Mr Larkin?
- From: Rich Grise
- Re: A chip too far? Where is your solution Mr Larkin?
- References:
- A chip too far? Where is your solution Mr Larkin?
- From: Jan Panteltje
- Re: A chip too far? Where is your solution Mr Larkin?
- From: John Larkin
- A chip too far? Where is your solution Mr Larkin?
- Prev by Date: Re: "Frames" Question
- Next by Date: Re: A chip too far? Where is your solution Mr Larkin?
- Previous by thread: Re: A chip too far? Where is your solution Mr Larkin?
- Next by thread: Re: A chip too far? Where is your solution Mr Larkin?
- Index(es):
Relevant Pages
|
