A chip too far? Where is your solution Mr Larkin? - sci.electronics.design

Message from discussion A chip too far? Where is your solution Mr Larkin?

Jan Panteltje

View profile

More options Aug 19 2008, 4:57 pm

Newsgroups: sci.electronics.design

From: Jan Panteltje <pNaonStpealm...@yahoo.com>

Date: Tue, 19 Aug 2008 15:57:50 GMT

Local: Tues, Aug 19 2008 4:57 pm

Subject: Re: A chip too far? Where is your solution Mr Larkin?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On a sunny day (Tue, 19 Aug 2008 08:24:56 -0700) it happened John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote in
<11pla49cjbncqm5kso6h6pmil38tt60...@4ax.com>:

>On Tue, 19 Aug 2008 15:07:51 GMT, Jan Panteltje
><pNaonStpealm...@yahoo.com> wrote:

>>A chip too far? Where is your solution Mr Larkin?
>> http://money.cnn.com/2008/08/13/technology/microchips_copeland.fortun...

>>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.

Reply to author Forward