Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #3040 > unrolled thread

Next Big Thing

Back to article view | Back to comp.arch

Contents

  Next Big Thing kenney@cix.compulink.co.uk - 2011-08-16 09:47 -0500
    Re: Next Big Thing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-08-16 08:24 -0700
      Re: Next Big Thing Quadibloc <jsavard@ecn.ab.ca> - 2011-08-16 08:51 -0700
        Re: Next Big Thing MitchAlsup <MitchAlsup@aol.com> - 2011-08-16 12:17 -0700
          Re: Next Big Thing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-16 18:00 -0700
            Re: Next Big Thing Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-08-17 08:19 +0200
              Re: Next Big Thing Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> - 2011-08-17 12:40 +0000
              Re: Next Big Thing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-17 08:20 -0700
                Re: Next Big Thing MitchAlsup <MitchAlsup@aol.com> - 2011-08-17 10:43 -0700
                  Re: Next Big Thing nmm1@cam.ac.uk - 2011-08-17 18:19 +0100
                  Re: Next Big Thing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-08-17 23:39 -0700
                    Re: Next Big Thing nmm1@cam.ac.uk - 2011-08-18 07:27 +0100
    Re: Next Big Thing torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-08-17 10:49 +0200
      Re: Next Big Thing Quadibloc <jsavard@ecn.ab.ca> - 2011-08-17 05:37 -0700
    Re: Next Big Thing mac <acolvin@efunct.com> - 2011-08-18 22:23 +0000
    Re: Next Big Thing Morten Reistad <first@last.name> - 2011-08-24 20:44 +0200
      Re: Next Big Thing nmm1@cam.ac.uk - 2011-08-24 20:23 +0100

#3040 — Next Big Thing

 I can remember a couple of examples of computer technology being hyped 
as the next big thing for a year or three which then died. Bubble memory 
and superconducting computers. I was wondering if there were any others 
and if anyone thinks that something being discussed now will meet the 
same fate. 

 Ken Young

[toc] | [next] | [standalone]

#3041

On 8/16/2011 7:47 AM, kenney@cix.compulink.co.uk wrote:
>   I can remember a couple of examples of computer technology being hyped
> as the next big thing for a year or three which then died. Bubble memory
> and superconducting computers. I was wondering if there were any others


Very many others.  Of course, it depends a lot on your perspective as to 
how much hype there ism and how specialized the area is, how far back 
you want to go, etc.  Just a few examples from my experience with storage.

CCD as a disk replacement.
Wafer scale integration DRAM storage.
such "intermediate level" storage devices as the IBM data cell and its 
successors.
Holographic storage.

many more.


> and if anyone thinks that something being discussed now will meet the
> same fate.

This is a much harder question.  Sometimes it appears that an idea is 
crazy, and the hype dies down, but people keep plugging away at it and 
it becomes mainstream.  An example of this is vertical magnetic 
recording.  When it was first discussed in the late 1980s, people talked 
about it as the next big thing.  But people couldn't get it to work and 
the hype dies down.  But the engineers kept plugging away and now it is 
used in most disks.



And, of course, when you say computer technology, are you limiting 
yourself to hardware?  There are as many such ideas in software as in 
hardware, maybe even more.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#3043

On Aug 16, 9:24 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
> There are as many such ideas in software as in
> hardware, maybe even more.

Yes, but that ecosystem works very differently, so it's not useful to
discuss them together for this kind of topic.

Intel's Larrabee / Knight's Corner / Many Integrated Core
architecture... while exciting, could easily end up being a flop. It's
more versatile and flexible than a GPU for computing tasks, but such
an architecture seems to require an enormous bandwidth to memory to
function effectively.

One that likely won't be available/provided/included.

On the other hand, while the "right" way to make progress, from the
programmer's point of view, would be to make chips with just one
processor on them, but made from some exotic material so they could
run at a clock rate 20 GHz.

The labs are experimenting with exotic materials out of which
amazingly fast transistors can be made, but so far it's only in
silicon that a large, efficient CPU on the level of a Pentium or a
360/195 can be put on a single die.

Lab experiments that are many years away from becoming products, and
so don't become products for many years, aren't really "failures", but
they can at least sometimes get perceived that way.

John Savard

[toc] | [prev] | [next] | [standalone]

#3058

On Tuesday, August 16, 2011 10:51:40 AM UTC-5, Quadibloc wrote:
> On the other hand, while the "right" way to make progress, from the
> programmer's point of view, would be to make chips with just one
> processor on them, but made from some exotic material so they could
> run at a clock rate 20 GHz.

I know plenty of programmers who can programm parallel machines. Its just that we call them logic designers.....potentially the most embarisingly parallel problem ever.

But, and more importantly, this is the cross product of vonNeumann architecture and procedural programming languages.

Mitch

[toc] | [prev] | [next] | [standalone]

#3063

On 8/16/2011 12:17 PM, MitchAlsup wrote:
> On Tuesday, August 16, 2011 10:51:40 AM UTC-5, Quadibloc wrote:
>> On the other hand, while the "right" way to make progress, from the
>> programmer's point of view, would be to make chips with just one
>> processor on them, but made from some exotic material so they could
>> run at a clock rate 20 GHz.
>
> I know plenty of programmers who can program parallel machines. Its just that we call them logic designers.....potentially the most embarisingly parallel problem ever.
>
> But, and more importantly, this is the cross product of vonNeumann architecture and procedural programming languages.


One of my "I wish I had time for it" projects:

I think that some of the ideas in RTL languages, hardware design 
languages, could very usefully be placed into conventional programming 
languages.

I think that this would lead to making some programs easier to debug, 
less buggy - and probably also, as a side effect, would make code more 
parallel.



I have already talked about how, back when I was an undergrad Programmer 
on Duty, I would teach people to use a concurrent assignment construct

E.g. something like

       cur.next := node,
       cur.next.prev := node,
       node.next := cur.next,
       node.prev:= cur

getting translated into an approp[riate sequence, that may involve temps 
(or may not).


This is exactly the sort of thing that people used to hardware languages 
are used to doing.

[toc] | [prev] | [next] | [standalone]

#3068

Andy "Krazy" Glew wrote:
> I have already talked about how, back when I was an undergrad Programmer
> on Duty, I would teach people to use a concurrent assignment construct
[snip]
>
> This is exactly the sort of thing that people used to hardware languages
> are used to doing.

Working in hw, it seems kind of obvious that you are working with 
wavefronts (clock signals and data) passing over all your various 
resources; programming then becomes the problem of getting as much use 
out of them as possible, while the usual multithreaded problem of 
synchronization sort of goes away.

Is this the right way to think about it?

Terje
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#3070

Terje Mathisen <terje.mathisen at tmsw.no> sent on August 17th, 2011:
|----------------------------------------------------------------------------|
|"[..]                                                                       |
|                                                                            |
|Working in hw, it seems kind of obvious that you are working with wavefronts|
|(clock signals and data) passing over all your various resources; [..]"     |
|----------------------------------------------------------------------------|

That is the most beautiful interpretation which I have encountered.

|----------------------------------------------------------------------------|
|"[..]                                                                       |
|[..], while                                                                 |
|the usual multithreaded problem of synchronization sort of goes away.       |
|                                                                            |
|Is this the right way to think about it?"                                   |
|----------------------------------------------------------------------------|

It is never right that issues just disappear. The policy of hardware
being Globally Asynchronous, Locally Synchronous (GALS) still involves
synchronization.

[toc] | [prev] | [next] | [standalone]

#3072

On 8/16/2011 11:19 PM, Terje Mathisen wrote:
> Andy "Krazy" Glew wrote:
>> I have already talked about how, back when I was an undergrad Programmer
>> on Duty, I would teach people to use a concurrent assignment construct
> [snip]
>>
>> This is exactly the sort of thing that people used to hardware languages
>> are used to doing.
>
> Working in hw, it seems kind of obvious that you are working with
> wavefronts (clock signals and data) passing over all your various
> resources; programming then becomes the problem of getting as much use
> out of them as possible, while the usual multithreaded problem of
> synchronization sort of goes away.
>
> Is this the right way to think about it?
>
> Terje


Well, it's not the way I think about it, at higher levels of abstraction.

At a high level, I just try to think about outputs, and inputs, and 
expressing the outputs in terms of the inputs - even if some of the 
outputs and inputs are the same locations.  I'm always thinking 
NEW(variables) = f( OLD(variables) ).  Written in a way so that the 
order of evaluation does not matter.

Now, this is very much equivalent to saying something like ON RISING 
EDGE.  But I try to think in terms of as few such "clock edges" as 
possible, ideally only one.

Adding clock edges is like adding serialized Von Neumann state: it is an 
opportunity for bugs to arise.  Only do that when you get down to 
implementation.

[toc] | [prev] | [next] | [standalone]

#3073

On Wednesday, August 17, 2011 10:20:41 AM UTC-5, Andy Krazy Glew wrote:
> Now, this is very much equivalent to saying something like ON RISING 
> EDGE.  But I try to think in terms of as few such "clock edges" as 
> possible, ideally only one.

This is exactly right, the clock performs the synchronization of the parallel activities. And does so many (MANY) times better than atomic stuff in software-land.

One very interesting thing about RTL languages is that a particular expression may be executed many times before the totality of activity quiesses (the programmer does not specify how many times, the order of events determines how many times). Whereas, over in the software land, the writers want to execute a block of code exactly once after the gates have been checked and with synchronization to other interested third (and second) parties.

There is a tradeoff, here, and the tradeoff is in absolute performance.

Mitch

[toc] | [prev] | [next] | [standalone]

#3074

In article <f436c67d-a23d-486c-8ee1-007e145c7e03@glegroupsg2000goo.googlegroups.com>,
MitchAlsup  <comp.arch@googlegroups.com> wrote:
>On Wednesday, August 17, 2011 10:20:41 AM UTC-5, Andy Krazy Glew wrote:
>
>> Now, this is very much equivalent to saying something like ON RISING
>> EDGE.  But I try to think in terms of as few such "clock edges" as
>> possible, ideally only one.
>
>This is exactly right, the clock performs the synchronization of the
>parallel activities. And does so many (MANY) times better than atomic
>stuff in software-land.

That hurdle is so low that a guinea-pig could jump it.

>One very interesting thing about RTL languages is that a particular
>expression may be executed many times before the totality of activity
>quiesses (the programmer does not specify how many times, the order of
>events determines how many times). Whereas, over in the software land,
>the writers want to execute a block of code exactly once after the gates
>have been checked and with synchronization to other interested third
>(and second) parties.

Not all software uses a Von Neumann language, and some of us think
that we should be moving away from that model.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3076

On 8/17/2011 10:43 AM, MitchAlsup wrote:
> On Wednesday, August 17, 2011 10:20:41 AM UTC-5, Andy Krazy Glew wrote:
>> Now, this is very much equivalent to saying something like ON RISING
>> EDGE.  But I try to think in terms of as few such "clock edges" as
>> possible, ideally only one.
>
> This is exactly right, the clock performs the synchronization of the parallel activities. And does so many (MANY) times better than atomic stuff in software-land.
>
> One very interesting thing about RTL languages is that a particular expression may be executed many times before the totality of activity quiesses (the programmer does not specify how many times, the order of events determines how many times). Whereas, over in the software land, the writers want to execute a block of code exactly once after the gates have been checked and with synchronization to other interested third (and second) parties.
>
> There is a tradeoff, here, and the tradeoff is in absolute performance.

Interestingly, this multiple rexecution, called "relaxation" in hardware 
simulation

1) isn't necessary when you have a purely functional, single assignment 
language

1.1) when you can do "global smashing and code sorting" - unroll all 
loops, inline all functions, sort all code into a dependence graph 
without cycles

1.2) is necessary only when you have separately compiled modules that 
are not maximally unrolled and inlined, or which have cycles

2) you can eliminate cycles easily in functional, single assignment 
languages.

It is much harder to eliminate cycles in a sequential, conventional 
programming language.



But nevertheless sometimes conventional languages are more expressive.

I think relaxation may be useful in creating a common language 
infrastructure that can handle both.




While we are at it - notice the similarity between relaxation and replay 
pipelines?

[toc] | [prev] | [next] | [standalone]

#3077

In article <4E4CB399.1040606@SPAM.comp-arch.net>,
Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote:
>
>Interestingly, this multiple rexecution, called "relaxation" in hardware 
>simulation
>
> ...
>
>But nevertheless sometimes conventional languages are more expressive.
>
>I think relaxation may be useful in creating a common language 
>infrastructure that can handle both.

Definitely.  Modern Fortran PURE functions support that, and it
was not the first.

>While we are at it - notice the similarity between relaxation and replay 
>pipelines?

Yup.  LL/SC is precisely that at the ISA level, too.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#3069

kenney@cix.compulink.co.uk writes:

>  I can remember a couple of examples of computer technology being hyped 
> as the next big thing for a year or three which then died. Bubble memory 
> and superconducting computers. I was wondering if there were any
> others 

VLIW, bipolar logic for microprocessors (though these lasted longer than
1-3 years).

> and if anyone thinks that something being discussed now will meet the 
> same fate. 

Probably at least half of the "revolutionary" new technologies being
discussed now will fizz out without ever mecoming mainstream.  That's
the normal order of things in technology: You can't know until you try,
and many times the answer is "it didn't work" or "it wasn't practical".

	Torben

[toc] | [prev] | [next] | [standalone]

#3071

On Aug 17, 2:49 am, torb...@diku.dk (Torben Ægidius Mogensen) wrote:
> You can't know until you try,
> and many times the answer is "it didn't work" or "it wasn't practical".

And other times it's simply "another way was slightly better". So even
workable and practical ideas can often end up going by the wayside.

John Savard

[toc] | [prev] | [next] | [standalone]

#3079

> I can remember a couple of examples of computer technology being hyped as
> the next big thing for a year or three which then died. Bubble memory and
> superconducting computers. I was wondering if there were any others and
> if anyone thinks that something being discussed now will meet the same fate. 

Naaah. Who could be foolish enough to be caught af that again? With, for
example, explicitly parallel instruction sets, software multithreading,
netbooks, cloud computing...

Oh dear, do I sound like Old Nick?
-- 
mac the naïf

[toc] | [prev] | [next] | [standalone]

#3124

In article <z-2dnSdmpbqcHtfTnZ2dnUVZ7oudnZ2d@giganews.com>,
 <kenney@cix.compulink.co.uk> wrote:
> I can remember a couple of examples of computer technology being hyped 
>as the next big thing for a year or three which then died. Bubble memory 
>and superconducting computers. I was wondering if there were any others 
>and if anyone thinks that something being discussed now will meet the 
>same fate. 

Dataflow.

GaAs.

-- mrr

[toc] | [prev] | [next] | [standalone]

#3126

In article <4e554d06@news.broadpark.no>,
Morten Reistad  <first@last.name> wrote:
>In article <z-2dnSdmpbqcHtfTnZ2dnUVZ7oudnZ2d@giganews.com>,
> <kenney@cix.compulink.co.uk> wrote:
>> I can remember a couple of examples of computer technology being hyped 
>>as the next big thing for a year or three which then died. Bubble memory 
>>and superconducting computers. I was wondering if there were any others 
>>and if anyone thinks that something being discussed now will meet the 
>>same fate. 
>
>Dataflow.
>
>GaAs.

Those are not even remotely comparable.

Dataflow is alive and well, and will remain so for the foreseeable
future - in its niches!  Unlike flash-in-the-pan technologies, the
discussions of whether it will or can break out of them are regular
and inconclusive.  Until and unless someone can demonstrate that
it cannot do so for fairly insoluble reasons, those discussions
will continue - regularly and inconclusively.

GaAs is also alive and well for opto-electronics and possibly other
uses.  I accept that the claims of it being the next great general-
purpose technology were a flash-in-the-pan, but it won't go away
until people can replace all of its uses.


Regards,
Nick Maclaren.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web