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

Groups > comp.arch > #3312 > unrolled thread

'smttter IBMdroids

Back to article view | Back to comp.arch

Contents

  'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:15 -0400
    Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-08-31 22:20 -0400
      Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-08-31 22:31 -0400
        Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-01 07:30 -0700
    Re: 'smttter IBMdroids Quadibloc <jsavard@ecn.ab.ca> - 2011-09-01 09:48 -0700
      Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 17:58 +0100
      Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-01 10:58 -0700
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-01 18:51 +0100
      Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 15:42 -0400
      Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-01 18:19 -0500
        Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-01 20:57 -0400
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:17 +0100
        Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 09:19 +0100
          Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:44 -0500
            Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:39 +0100
              Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 11:14 -0500
          Re: 'smttter IBMdroids Robert Wessel <robertwessel2@yahoo.com> - 2011-09-02 04:47 -0500
            Re: 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 11:26 +0100
            Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 08:48 -0400
            Re: 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 09:29 -0400
    Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-01 17:15 -0500
      Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-02 10:10 -0700
        Re: innovation from Armonk, was 'smttter IBMdroids John Levine <johnl@iecc.com> - 2011-09-02 21:21 +0000
          Re: innovation from Armonk, was 'smttter IBMdroids nmm1@cam.ac.uk - 2011-09-02 21:56 +0100
          Re: innovation from Armonk, was 'smttter IBMdroids Anne & Lynn Wheeler <lynn@garlic.com> - 2011-09-02 17:49 -0400
        Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-02 18:04 -0500
          Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 00:16 +0100
            Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 14:25 -0400
              Re: 'smttter IBMdroids Thomas Womack <twomack@chiark.greenend.org.uk> - 2011-09-03 20:09 +0100
          Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 22:02 -0400
            Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-03 21:50 -0500
              Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-03 23:52 -0400
        Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 08:26 -0700
          Re: 'smttter IBMdroids Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-09-05 11:14 -0700
            Re: 'smttter IBMdroids Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-09-05 22:05 +0200
            Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:27 -0400
          Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 17:16 -0400
            Re: 'smttter IBMdroids "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-09-05 14:40 -0700
              Re: 'smttter IBMdroids Robert Myers <rbmyersusa@gmail.com> - 2011-09-05 15:45 -0700
          Re: 'smttter IBMdroids Del Cecchi <delcecchi@gmail.com> - 2011-09-06 21:47 -0500

Page 2 of 2 — ← Prev page 1 [2]

#3354

On 8/31/2011 9:15 PM, Robert Myers wrote:
> Not in the mood today to claim that IBM invented everything and that you
> personally were involved?
>
> Robert.

Huh?  WTF you talking bout?

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

#3387

On Sep 1, 6:15 pm, Del Cecchi <delcec...@gmail.com> wrote:
> On 8/31/2011 9:15 PM, Robert Myers wrote:
>
> > Not in the mood today to claim that IBM invented everything and that you
> > personally were involved?
>
> > Robert.
>
> Huh?  WTF you talking bout?

Just stirring the pot.

Success has many fathers, but failure is an orphan.

IBM, at least as represented here, seems to want to claim credit for
an awful lot.  I never worked for IBM, and the little direct
experience I had with their equipment (360, 370, HASP RJE, and,
finally, the PC), did not leave me with the impression that IBM was at
the center of anything other than a lot of nicely-dressed salesmen and
user interfaces designed by sadists.

I've said before that IBM really shouldn't be in the business of
building supercomputers for technical computing.

There are probably many possible taxonomies for computing, but the one
that drives my dislike of IBM having any significant influence over
technical supercomputing is that there are

a. Calculations where you know days, and maybe even weeks, months, or
years ahead of time what will transpire when you run the program.

b. Operations where what the computer does next is entirely at the
whim of forces completely beyond its control and almost always beyond
anyone's ability even to predict such that the system will *always*
even run reliably.

Most technical computing is category a and all but small slices of
business computing are category b.  More and more business computing
that might at one time have fit into category a is gradually sliding
into category b, as business analytics are increasingly done in real
time.

Category b has an awful lot of painful constraints, and my hat is off
to anyone who can work successfully with those kinds of requirements.
Satisfying those requirements must require an awful lot of brain,
money, and attention-share, and I would strongly prefer to think that
most computers for technical computing were built by people who were
only vaguely aware of category b and certainly did not spend most of
the work week in that mindset.

Itanium was a processor that was clearly built with a category a
mindset.  That's why itanium got so much of my attention and maybe
part of why it failed--that, plus the fact that most of the people who
laid hands on Itanium were by habit category b users.  How much easier
it would be, it seemed to me, to build a really fast category a
processor and/or computer because, in most cases, you *do* know the
future.

By the time you get down to microarchitecture as it is currently
practiced, the whole world starts to look like category b.  Itanium
was a toe in the water of a microarchitecture designed more for
category a, and I've taken up a lot of time and space here asking what
went wrong because that's the kind of processing that interests me.
A computer built almost entirely for category a would have serious
issues dealing with remaining category b needs that it couldn't avoid
dealing with, but, in my never-sufficiently-humble opinion, if we ever
build a supercomputer for technical computing that isn't a sour joke,
it will be because all the category b constraints were left behind.
That's why I want IBM out of the business.

Robert.

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

#3392 — Re: innovation from Armonk, was 'smttter IBMdroids

>IBM, at least as represented here, seems to want to claim credit for
>an awful lot.

There are some things that IBM definitely did invent: Fortran, disk
storage, byte addressed memory, relational databases, and logical
computer architecture separate from the design of individual
computers.  There are plenty of other things they didn't, like virtual
memory and floating point arithmetic.

IBM was a credible if not particularly cost effective competetor in
the supercomputer market with the Stretch and then the 360/91 and
/195.  The /91 had some clever technical innovarions like register
renaming to allow more operations to proceed in parallel.  But it
didn't help that the 360's floating point design was so badly botched,
or that their high end computers kept going hugely over budget.  (I
gather that both the Stretch and the /91 were sold below cost.)

I never understood the goal of the vector facility.  By the time it
came along, it was pretty clear that the future of supercomputing
was in specialized machines, not add-ons to mainframes.

R's,
John

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

#3393 — Re: innovation from Armonk, was 'smttter IBMdroids

In article <j3rhbs$2p17$1@gal.iecc.com>, John Levine  <johnl@iecc.com> wrote:
>
> [ Re: IBM ]
>
>I never understood the goal of the vector facility.  By the time it
>came along, it was pretty clear that the future of supercomputing
>was in specialized machines, not add-ons to mainframes.

I can explain, because I was fairly close to IBM at the time.

It was never intended to be a 'supercomputing' facility, but was
there because a lot of finance houses ran Cobol during the day,
and wanted to gamble at night.  Er, sorry, invest on the futures
market using advanced prediction algorithms.

So it was a cheap add-on to a commercial machine that provided a
large marginal benefit if that's what you wanted, but wasn't an
interesting primary product.


Regards,
Nick Maclaren.

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

#3395 — Re: innovation from Armonk, was 'smttter IBMdroids

John Levine <johnl@iecc.com> writes:
> I never understood the goal of the vector facility.  By the time it
> came along, it was pretty clear that the future of supercomputing
> was in specialized machines, not add-ons to mainframes.

re:
http://www.garlic.com/~lynn/2011k.html#82 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#84 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#86 'smttter IBMdroids
http://www.garlic.com/~lynn/2011k.html#87 'smttter IBMdroids

I remember the 3090 (trout 1.5) processor engineers saying something
similar ... that they had optimized memory and floating point ... so
that floating point operations were happening as fast as memory could
deliver data. vector operations couldn't go any faster ... since memory
wouldn't be able to deliver data any faster (slightly different
argument).

there was conjecture was that marketing believed that there were
customers that would buy "vectors" ... just because it said "vectors"
(assumption that individual floating point was so much slower than
memory ... that memory was able to keep up with multiple floating point
units running in parallel).

as soon as Future System failed 
http://www.garlic.com/~lynn/submain.html#futuresys
... two teams were kicked off in parallel, ... one was doing quick&dirty
303x in parallel with 370/xa&3081
http://www.jfsowa.com/computer/memo125.htm

as soon as 303x was done, that team started on 3090 in parallel with the
continued 3081 activity.

recent thread mentioning 3090 vector feature:
http://www.garlic.com/~lynn/2011h.html#72 Vector processors on the 3090
http://www.garlic.com/~lynn/2011h.html#73 Vector processors on the 3090
http://www.garlic.com/~lynn/2011h.html#74 Vector processors on the 3090
http://www.garlic.com/~lynn/2011i.html#1 Vector processors on the 3090
http://www.garlic.com/~lynn/2011i.html#10 Vector processors on the 3090

I had friend that ran the (ibm) kingston engineering&scientific
datacenter that had a bunch of floating point systems ... misc
past refs:
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2000e.html#20 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#82 Disks size growing while disk count shrinking = bad performance
http://www.garlic.com/~lynn/2001d.html#32 Imitation...
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003d.html#35 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2004c.html#1 Oldest running code
http://www.garlic.com/~lynn/2004l.html#1 Xah Lee's Unixism
http://www.garlic.com/~lynn/2005d.html#10 Cerf and Kahn receive Turing award
http://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005t.html#3 Privacy issue - how to spoof/hide IP when accessing email / usenet servers ?
http://www.garlic.com/~lynn/2006m.html#4 The Power of the NORC
http://www.garlic.com/~lynn/2006o.html#1 harris
http://www.garlic.com/~lynn/2009j.html#54 A Complete History Of Mainframe Computing
http://www.garlic.com/~lynn/2010b.html#71 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010b.html#72 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing
http://www.garlic.com/~lynn/2010f.html#61 Handling multicore CPUs; what the competition is thinking
http://www.garlic.com/~lynn/2010o.html#3 When will MVS be able to use cheap dasd

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#3397

On 9/2/2011 12:10 PM, Robert Myers wrote:
> On Sep 1, 6:15 pm, Del Cecchi<delcec...@gmail.com>  wrote:
>> On 8/31/2011 9:15 PM, Robert Myers wrote:
>>
>>> Not in the mood today to claim that IBM invented everything and that you
>>> personally were involved?
>>
>>> Robert.
>>
>> Huh?  WTF you talking bout?
>
> Just stirring the pot.
>
> Success has many fathers, but failure is an orphan.
>
> IBM, at least as represented here, seems to want to claim credit for
> an awful lot.  I never worked for IBM, and the little direct
> experience I had with their equipment (360, 370, HASP RJE, and,
> finally, the PC), did not leave me with the impression that IBM was at
> the center of anything other than a lot of nicely-dressed salesmen and
> user interfaces designed by sadists.
>
> I've said before that IBM really shouldn't be in the business of
> building supercomputers for technical computing.
>
> There are probably many possible taxonomies for computing, but the one
> that drives my dislike of IBM having any significant influence over
> technical supercomputing is that there are
>
> a. Calculations where you know days, and maybe even weeks, months, or
> years ahead of time what will transpire when you run the program.
>
> b. Operations where what the computer does next is entirely at the
> whim of forces completely beyond its control and almost always beyond
> anyone's ability even to predict such that the system will *always*
> even run reliably.
>
> Most technical computing is category a and all but small slices of
> business computing are category b.  More and more business computing
> that might at one time have fit into category a is gradually sliding
> into category b, as business analytics are increasingly done in real
> time.
>
> Category b has an awful lot of painful constraints, and my hat is off
> to anyone who can work successfully with those kinds of requirements.
> Satisfying those requirements must require an awful lot of brain,
> money, and attention-share, and I would strongly prefer to think that
> most computers for technical computing were built by people who were
> only vaguely aware of category b and certainly did not spend most of
> the work week in that mindset.
>
> Itanium was a processor that was clearly built with a category a
> mindset.  That's why itanium got so much of my attention and maybe
> part of why it failed--that, plus the fact that most of the people who
> laid hands on Itanium were by habit category b users.  How much easier
> it would be, it seemed to me, to build a really fast category a
> processor and/or computer because, in most cases, you *do* know the
> future.
>
> By the time you get down to microarchitecture as it is currently
> practiced, the whole world starts to look like category b.  Itanium
> was a toe in the water of a microarchitecture designed more for
> category a, and I've taken up a lot of time and space here asking what
> went wrong because that's the kind of processing that interests me.
> A computer built almost entirely for category a would have serious
> issues dealing with remaining category b needs that it couldn't avoid
> dealing with, but, in my never-sufficiently-humble opinion, if we ever
> build a supercomputer for technical computing that isn't a sour joke,
> it will be because all the category b constraints were left behind.
> That's why I want IBM out of the business.
>
> Robert.


Sorry, I still don't get it.  Itanium was an implementation of VLIW, 
which a number of companies, including IBM were pursuing at the time. 
Itanium failed because Intel/HPQ motives were impure.

If tyou don't know where you are going then any direction will get you 
there.

I worked on Midrange stuff and have my own opinions about the Pok mafia. 
  But I still don't understand why you are so bent out of shape over the 
IBM supercomputer efforts.

When Blue Gene was merely a glimmer of an idea between Yorktown and 
Rochester (they needed Rochester to actually build it) it was an 
interesting idea as to how to put together a bunch of processors to have 
enough power (mips/flops/whatever) to do interesting stuff like 
computational chemistry.

Apparently the government decided it would work for simulating bombs. 
Good for them, it is better than setting them off to see if they still 
work.

The government must not want some other paradigm bad enough or they 
would have coughed up enough money to build Blue Waters.

How did the Red Storm from Cray work out?   Just curious since I worked 
on it for a short time before IBM politics decided we shouldn't.

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

#3398

In article <j3rncq$4tq$1@dont-email.me>,
Del Cecchi  <delcecchi@gmail.com> wrote:

>How did the Red Storm from Cray work out?   Just curious since I worked 
>on it for a short time before IBM politics decided we shouldn't.

It seems to have worked reasonably well; there have subsequently been
XT4, XT5 and XT6 machines, using upgraded versions of the same
interconnect attached to newer generations of Opteron, and I suspect
there will be an XT7 not long after the Interlagos Opteron processors
come out.

The XT machines occupy quite a lot of the Top500, and have sold to
people like the Korean weather bureau and the University of Edinburgh
as well as the obvious US-government institutions; HECTOR, the one at
the University of Edinburgh, appears to have done some quite useful
quantum chemistry, though research projects do tend to have been
things like 'The computationally expensive parallel 3D Fourier
transform was also modified to reduce parallelisation overheads, and
to allow the used of advanced performance planning of the Fastest
Fourier Transform in the West ( FFTW) library.'

http://www.hector.ac.uk/casestudies/turbulent_flows.php might interest
Robert.

I don't get the impression that there are that many jobs being run
taking all of HECTOR; the research papers at
http://www.hector.ac.uk/cse/reports/ are mostly using no more than
2^10 cores, so there's an argument that a pile of rack-scale machines
(nowadays that's a 36-port QDR switch and 36 4x12xOpteron boxes with
64G RAM each, so 1728 8Gflop cores and a couple of terabytes of
memory, probably change from $400k) might not have been an
unreasonable way to go, if probably a lot harder to manage.

Tom

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

#3416

On 9/2/2011 7:16 PM, Thomas Womack wrote:

>
> The XT machines occupy quite a lot of the Top500, and have sold to
> people like the Korean weather bureau and the University of Edinburgh
> as well as the obvious US-government institutions; HECTOR, the one at
> the University of Edinburgh, appears to have done some quite useful
> quantum chemistry, though research projects do tend to have been
> things like 'The computationally expensive parallel 3D Fourier
> transform was also modified to reduce parallelisation overheads, and
> to allow the used of advanced performance planning of the Fastest
> Fourier Transform in the West ( FFTW) library.'
>
> http://www.hector.ac.uk/casestudies/turbulent_flows.php might interest
> Robert.
>
I am indeed very interested.  Thanks for the link.  To say more will 
take some work on my part.

> I don't get the impression that there are that many jobs being run
> taking all of HECTOR; the research papers at
> http://www.hector.ac.uk/cse/reports/ are mostly using no more than
> 2^10 cores, so there's an argument that a pile of rack-scale machines
> (nowadays that's a 36-port QDR switch and 36 4x12xOpteron boxes with
> 64G RAM each, so 1728 8Gflop cores and a couple of terabytes of
> memory, probably change from $400k) might not have been an
> unreasonable way to go, if probably a lot harder to manage.
>

I don't really understand the point of building "supercomputers" if all 
you are doing is plugging more things together.  You plug together 
whatever you need.  Who cares where it sits on the Top500 list?  It's 
almost like people sending out news releases about the Top 500 
warehouses.  Do companies ordinarily brag about building more than they 
can routinely use?

Robert.

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

#3419

In article <Rju8q.15707$qy6.13516@newsfe07.iad>,
Robert Myers  <rbmyersusa@gmail.com> wrote:

>I don't really understand the point of building "supercomputers" if all 
>you are doing is plugging more things together.  You plug together 
>whatever you need.  Who cares where it sits on the Top500 list?

Nobody's very interested in the position on the Top500 list, though
once compiled it's a source of free press releases for pointing out to
your funders that you exist.  Being able to provide the computational
scientists in the UK with resources proportional to their needs is
I suppose quite useful, though defining the needs of computational
scientists is hard.

The queue status is up on the Web at
http://www.hector.ac.uk/service/status/ and I'm really very surprised
that the curve for number-of-active-cores is measurably different from
a plateau at all-44544, and that the machine is more idle at evenings
and weekends.  I do wonder if they've built too large a machine for
their needs, or are finding themselves having to charge more than
their audience supports.

(http://investors.cray.com/phoenix.zhtml?c=98390&p=irol-newsArticle&ID=1561564&highlight=
indicates that there is a phase 2C which will take the machine from 20
wardrobes of Opteron 6100 to 30 wardrobes of Opteron 6200, and I don't
quite see why you do that other than for bragging reasons if the
current machine often has only ten wardrobes used).

[I suspect the Cray is easier to cool and cheaper to power than thirty
stand-alone wardrobes, but I suspect it's a good deal more expensive]

Tom

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

#3429

On 9/2/2011 7:04 PM, Del Cecchi wrote:

>
> Sorry, I still don't get it. Itanium was an implementation of VLIW,
> which a number of companies, including IBM were pursuing at the time.
> Itanium failed because Intel/HPQ motives were impure.
>
> If tyou don't know where you are going then any direction will get you
> there.
>
> I worked on Midrange stuff and have my own opinions about the Pok mafia.
> But I still don't understand why you are so bent out of shape over the
> IBM supercomputer efforts.
>
> When Blue Gene was merely a glimmer of an idea between Yorktown and
> Rochester (they needed Rochester to actually build it) it was an
> interesting idea as to how to put together a bunch of processors to have
> enough power (mips/flops/whatever) to do interesting stuff like
> computational chemistry.
>
> Apparently the government decided it would work for simulating bombs.
> Good for them, it is better than setting them off to see if they still
> work.
>
> The government must not want some other paradigm bad enough or they
> would have coughed up enough money to build Blue Waters.
>

"The government" is an idiot.  Fortunately for us, the Russians were 
even worse.

Most of what is wrong with government stewardship of scientific research 
is mistakes we inherited or copied from the Soviets or the Nazis.

It is not inconceivable that the Soviets and the Nazis learned from IBM 
and General Electric.

When I get my cease and desist letter from IBM legal, I'll start to be 
more careful, but I really don't think they want to go there.  We'll 
see.  I want IBM out of the supercomputer business.  What's so hard to 
understand about that?

Robert.

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

#3430

On 9/3/2011 9:02 PM, Robert Myers wrote:
> On 9/2/2011 7:04 PM, Del Cecchi wrote:
>
>>
>> Sorry, I still don't get it. Itanium was an implementation of VLIW,
>> which a number of companies, including IBM were pursuing at the time.
>> Itanium failed because Intel/HPQ motives were impure.
>>
>> If tyou don't know where you are going then any direction will get you
>> there.
>>
>> I worked on Midrange stuff and have my own opinions about the Pok mafia.
>> But I still don't understand why you are so bent out of shape over the
>> IBM supercomputer efforts.
>>
>> When Blue Gene was merely a glimmer of an idea between Yorktown and
>> Rochester (they needed Rochester to actually build it) it was an
>> interesting idea as to how to put together a bunch of processors to have
>> enough power (mips/flops/whatever) to do interesting stuff like
>> computational chemistry.
>>
>> Apparently the government decided it would work for simulating bombs.
>> Good for them, it is better than setting them off to see if they still
>> work.
>>
>> The government must not want some other paradigm bad enough or they
>> would have coughed up enough money to build Blue Waters.
>>
>
> "The government" is an idiot. Fortunately for us, the Russians were even
> worse.

Pretty much got to agree with you there.  I can see why all those 
liberals get mad at you.  Have you extended this by induction to become 
a conservative?  Voting for Ron Paul?  Libertarian?
>
> Most of what is wrong with government stewardship of scientific research
> is mistakes we inherited or copied from the Soviets or the Nazis.

May I conclude you are also a skeptic about anthropogenic climate change 
since the alarm seems to mostly be a result of computer simulation?

>
> It is not inconceivable that the Soviets and the Nazis learned from IBM
> and General Electric.

Learned what?  Evil been around for a long time.  Mao and Stalin were 
evil all on their own.  As were some of the Brits for that matter. 
Pretty much all countries have awful things in their histories if you 
really look.  What the Romans did to Carthage would be genocide in 
today's vocabulary.  The salt was especially mean.
>
> When I get my cease and desist letter from IBM legal, I'll start to be
> more careful, but I really don't think they want to go there. We'll see.
> I want IBM out of the supercomputer business. What's so hard to
> understand about that?
>
> Robert.

I never said anything about being careful.  Where did that come from?

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

#3431

On 9/3/2011 10:50 PM, Del Cecchi wrote:
> On 9/3/2011 9:02 PM, Robert Myers wrote:
>> On 9/2/2011 7:04 PM, Del Cecchi wrote:
>>

>>>
>>> The government must not want some other paradigm bad enough or they
>>> would have coughed up enough money to build Blue Waters.
>>>
>>
>> "The government" is an idiot. Fortunately for us, the Russians were even
>> worse.
>
> Pretty much got to agree with you there. I can see why all those
> liberals get mad at you. Have you extended this by induction to become a
> conservative? Voting for Ron Paul? Libertarian?

Not likely I would vote for Ron Paul or Libertarian.  I don't want 
people running around starving to death or dying for lack of minimal 
medical care.  Who should I vote for?

>>
>> Most of what is wrong with government stewardship of scientific research
>> is mistakes we inherited or copied from the Soviets or the Nazis.
>
> May I conclude you are also a skeptic about anthropogenic climate change
> since the alarm seems to mostly be a result of computer simulation?
>
You clearly haven't been reading my posts.  My liberal friends all hate 
me for my climate skepticism, but I do have degrees, you know (physics, 
fluid mechanics).  One of the problems is the half-baked attitude toward 
computation (and toward disinterested science, for that matter).


>>
>> It is not inconceivable that the Soviets and the Nazis learned from IBM
>> and General Electric.
>
> Learned what? Evil been around for a long time. Mao and Stalin were evil
> all on their own. As were some of the Brits for that matter. Pretty much
> all countries have awful things in their histories if you really look.
> What the Romans did to Carthage would be genocide in today's vocabulary.
> The salt was especially mean.

If you allow political entities to control science, you get a 
predictable result: science that is exclusively oriented to serve the 
needs of the ruling class.  If that is what science is about, I renounce 
science.  Did you ever read about what Thomas Edison did to try to 
discredit AC?  GE has always been thought of as an MIT company (or at 
least it was)--must be that's the reason there is a bust of Nicola Tesla 
in the Barker Engineering Library.

>>
>> When I get my cease and desist letter from IBM legal, I'll start to be
>> more careful, but I really don't think they want to go there. We'll see.
>> I want IBM out of the supercomputer business. What's so hard to
>> understand about that?
>>
> I never said anything about being careful. Where did that come from?
>

Someone on a different forum suggested I should be more careful when 
making accusations against IBM and LLNL.  I told them I would worry when 
IBM even noticed me, and I didn't expect that to happen.  They couldn't 
withstand thirty seconds of scrutiny.


Robert.

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

#3471

On 9/2/2011 10:10 AM, Robert Myers wrote:

> There are probably many possible taxonomies for computing, but the one
> that drives my dislike of IBM having any significant influence over
> technical supercomputing is that there are
>
> a. Calculations where you know days, and maybe even weeks, months, or
> years ahead of time what will transpire when you run the program.
>
> b. Operations where what the computer does next is entirely at the
> whim of forces completely beyond its control and almost always beyond
> anyone's ability even to predict such that the system will *always*
> even run reliably.
>
> Most technical computing is category a and all but small slices of
> business computing are category b.  More and more business computing
> that might at one time have fit into category a is gradually sliding
> into category b, as business analytics are increasingly done in real
> time.
>
> Category b has an awful lot of painful constraints, and my hat is off
> to anyone who can work successfully with those kinds of requirements.
> Satisfying those requirements must require an awful lot of brain,
> money, and attention-share, and I would strongly prefer to think that
> most computers for technical computing were built by people who were
> only vaguely aware of category b and certainly did not spend most of
> the work week in that mindset.
>
> Itanium was a processor that was clearly built with a category a
> mindset.  That's why itanium got so much of my attention and maybe
> part of why it failed--that, plus the fact that most of the people who
> laid hands on Itanium were by habit category b users.  How much easier
> it would be, it seemed to me, to build a really fast category a
> processor and/or computer because, in most cases, you *do* know the
> future.
>
> By the time you get down to microarchitecture as it is currently
> practiced, the whole world starts to look like category b.  Itanium
> was a toe in the water of a microarchitecture designed more for
> category a, and I've taken up a lot of time and space here asking what
> went wrong because that's the kind of processing that interests me.
> A computer built almost entirely for category a would have serious
> issues dealing with remaining category b needs that it couldn't avoid
> dealing with, but, in my never-sufficiently-humble opinion, if we ever
> build a supercomputer for technical computing that isn't a sour joke,
> it will be because all the category b constraints were left behind.
> That's why I want IBM out of the business.


Interesting.   How do you characterize your category a versus category b?

Real-time?  Server type workloads?  Pointer chasing over linked data 
structures?

I agree that Itanium's targeting of server workloads was odd.

I disagree that "microarchitecture as it is currently practiced" favors 
category b.  If category b is characterized as I said above.

 From my point of view, the last 10-15 years of microarchitecture have 
been characterized by overemphasizing category a stuff --- witness the 
landslide of SIMD packed vector instructions. GPU SIMD style 
architectures.  The  overemphasis on sequential access pattern bandwidth.

And my understanding is that you have not been terribly happy with that.

I think that your categorization needs to be tweaked:

Category a
     a.1 sequential and local
     a.2 non-sequential and non-local

Category b
     Not knowing your definition, I'll suppose  it to be RT, server, 
pointer chasing.

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

#3473

On 9/5/2011 8:26 AM, Andy "Krazy" Glew wrote:
> On 9/2/2011 10:10 AM, Robert Myers wrote:
>
>> There are probably many possible taxonomies for computing, but the one
>> that drives my dislike of IBM having any significant influence over
>> technical supercomputing is that there are
>>
>> a. Calculations where you know days, and maybe even weeks, months, or
>> years ahead of time what will transpire when you run the program.
>>
>> b. Operations where what the computer does next is entirely at the
>> whim of forces completely beyond its control and almost always beyond
>> anyone's ability even to predict such that the system will *always*
>> even run reliably.
>>
>> Most technical computing is category a and all but small slices of
>> business computing are category b. More and more business computing
>> that might at one time have fit into category a is gradually sliding
>> into category b, as business analytics are increasingly done in real
>> time.
>>
>> Category b has an awful lot of painful constraints, and my hat is off
>> to anyone who can work successfully with those kinds of requirements.
>> Satisfying those requirements must require an awful lot of brain,
>> money, and attention-share, and I would strongly prefer to think that
>> most computers for technical computing were built by people who were
>> only vaguely aware of category b and certainly did not spend most of
>> the work week in that mindset.
>>
>> Itanium was a processor that was clearly built with a category a
>> mindset. That's why itanium got so much of my attention and maybe
>> part of why it failed--that, plus the fact that most of the people who
>> laid hands on Itanium were by habit category b users. How much easier
>> it would be, it seemed to me, to build a really fast category a
>> processor and/or computer because, in most cases, you *do* know the
>> future.
>>
>> By the time you get down to microarchitecture as it is currently
>> practiced, the whole world starts to look like category b. Itanium
>> was a toe in the water of a microarchitecture designed more for
>> category a, and I've taken up a lot of time and space here asking what
>> went wrong because that's the kind of processing that interests me.
>> A computer built almost entirely for category a would have serious
>> issues dealing with remaining category b needs that it couldn't avoid
>> dealing with, but, in my never-sufficiently-humble opinion, if we ever
>> build a supercomputer for technical computing that isn't a sour joke,
>> it will be because all the category b constraints were left behind.
>> That's why I want IBM out of the business.
>
>
> Interesting. How do you characterize your category a versus category b?
>
> Real-time? Server type workloads? Pointer chasing over linked data
> structures?
>
> I agree that Itanium's targeting of server workloads was odd.
>
> I disagree that "microarchitecture as it is currently practiced" favors
> category b. If category b is characterized as I said above.
>
>  From my point of view, the last 10-15 years of microarchitecture have
> been characterized by overemphasizing category a stuff --- witness the
> landslide of SIMD packed vector instructions. GPU SIMD style
> architectures. The overemphasis on sequential access pattern bandwidth.
>
> And my understanding is that you have not been terribly happy with that.
>
> I think that your categorization needs to be tweaked:
>
> Category a
> a.1 sequential and local
> a.2 non-sequential and non-local
>
> Category b
> Not knowing your definition, I'll suppose it to be RT, server, pointer
> chasing.

I take Robert's distinction somewhat differently.  I may not have it 
correct, but . .

You can think of category A as a program where you know the exact 
sequence of instructions that will be executed before instruction 
execution starts.  For example, think of a CFD simulation.  You could, 
at least in principle, eliminate (or at least correctly predict) every 
branch, could prefetch every piece of data that would be needed, etc.

Category B would then consist of programs that get unpredictable input 
after the program starts executing.  Yes, this includes servers and RT 
stuff, but also includes such desktop applications as word processing 
(i.e. Is the next character the user going to input a command or some 
input?),

I suspect Robert would characterize those applications where SIMD 
instructions are used for graphics, (e.g. MPEG decoding) as, at least in 
practice, since you design the code for any input, you can't predict the 
input (MPEG stream) ahead of time.

As for pointer chasing, it depends on the context.  If the pointers are 
used for a sparse array that is known ahead of time, then it would be 
category A, but if the pointers were to data items in a database page, 
then it would be category B.

I don't know if this distinction has any consequences for computer 
architecture, but I think this is what he means.  Of course, I welcome 
any corrections from Robert.




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

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

#3476

Stephen Fuld wrote:
> I suspect Robert would characterize those applications where SIMD
> instructions are used for graphics, (e.g. MPEG decoding) as, at least in
> practice, since you design the code for any input, you can't predict the
> input (MPEG stream) ahead of time.

Video/audio decoding is by definition unpredictable:

If it was predictable, then that represent a missed compression opportunity.

What you _can_ do, at least sometimes, is to convert the decoding state 
machine from a series of code dependencies to data dependencies.

Since the latter is an order of magnitude (or more) faster than missed 
branches, I've found that it does help quite a bit on modern (relatively 
deep pipeline) architectures.

Terje

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

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

#3479

On 9/5/2011 2:14 PM, Stephen Fuld wrote:

>
> I don't know if this distinction has any consequences for computer
> architecture, but I think this is what he means. Of course, I welcome
> any corrections from Robert.
>
I wasn't so much trying to advance computer architecture as I was trying 
to offer some kind of rationalization for my obsessions.

When you get right down to it, the really smart people in computer 
science don't find what interests me all that compelling.  They want to 
be working in kernel land, where every nanosecond is a new surprise. 
Maybe my sense that people who are taught to value such considerations 
so highly wouldn't be my first choice for designing computers for 
technical workloads is way off base, but it is what it is.

For example.  What would an itanium that didn't have to worry about 
interrupts look like?  I was horrified when the cray was given a 
real-time interactive interface.  That had to have a price.  A number 
crunching machine should be like God: it talks to mortals only through 
the high priest of the front end.  If all the gears get jammed up 
because the number cruncher can't stop on a dime, no markets will crash.

Graphics workloads are another special case.  The lazy way to build 
graphics hardware and software is to treat it like category b.  Really 
smart graphics hardware and software turns category b problems into 
category a problems whenever possible.

Robert.

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

#3478

On 9/5/2011 11:26 AM, Andy "Krazy" Glew wrote:

>
> Interesting. How do you characterize your category a versus category b?
>
> Real-time? Server type workloads?

Those would be category b workloads.

> Pointer chasing over linked data
> structures?
>
Pointer chasing over linked data where what you are likely to encounter 
can be characterized pretty narrowly ahead of time probably deserves a 
category of its own.

> I agree that Itanium's targeting of server workloads was odd.
>
> I disagree that "microarchitecture as it is currently practiced" favors
> category b. If category b is characterized as I said above.
>
>  From my point of view, the last 10-15 years of microarchitecture have
> been characterized by overemphasizing category a stuff --- witness the
> landslide of SIMD packed vector instructions. GPU SIMD style
> architectures. The overemphasis on sequential access pattern bandwidth.
>
> And my understanding is that you have not been terribly happy with that.
>
No, I haven't.  As you have explained yourself, microarchitecture has 
bent toward that which can be supplied easily and cheaply, and that 
reality favors the sequential access and simd weighting of most of the 
new widgetry.  The stuff I want is hard and expensive.  I got that.

As I have repeated ad nauseum, the Top500 list values cheap, easy flops 
just as highly as expensive, no-so-easy flops.

> I think that your categorization needs to be tweaked:
>
> Category a
> a.1 sequential and local
> a.2 non-sequential and non-local

but still predictable in either case.

>
> Category b
> Not knowing your definition, I'll suppose it to be RT, server, pointer
> chasing.

As I said, I think pointer chasing is a special case.

Robert.

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

#3480

On 9/5/2011 2:16 PM, Robert Myers wrote:
> On 9/5/2011 11:26 AM, Andy "Krazy" Glew wrote:
>
>> Interesting. How do you characterize your category a versus category b?
>>
>> Real-time? Server type workloads?
>
> Those would be category b workloads.
>
>> Pointer chasing over linked data
>> structures?
>>
> Pointer chasing over linked data where what you are likely to encounter
> can be characterized pretty narrowly ahead of time probably deserves a
> category of its own.
>
>> And my understanding is that you have not been terribly happy with that.
>>
> No, I haven't. As you have explained yourself, microarchitecture has
> bent toward that which can be supplied easily and cheaply, and that
> reality favors the sequential access and simd weighting of most of the
> new widgetry. The stuff I want is hard and expensive. I got that.
>
> As I have repeated ad nauseum, the Top500 list values cheap, easy flops
> just as highly as expensive, no-so-easy flops.
>
>> I think that your categorization needs to be tweaked:
>>
>> Category a
>> a.1 sequential and local
>> a.2 non-sequential and non-local
>
> but still predictable in either case.
>
>>
>> Category b
>> Not knowing your definition, I'll suppose it to be RT, server, pointer
>> chasing.
>
> As I said, I think pointer chasing is a special case.
>
> Robert.


On a nearby slightly divergent thread:
On 9/5/2011 11:14 AM, Stephen Fuld wrote:
 >
 > I take Robert's distinction somewhat differently. I may not have it
 > correct, but . .
 >
 > You can think of category A as a program where you know the exact
 > sequence of instructions that will be executed before instruction
 > execution starts. For example, think of a CFD simulation. You could, at
 > least in principle, eliminate (or at least correctly predict) every
 > branch, could prefetch every piece of data that would be needed, etc.
 >
 > Category B would then consist of programs that get unpredictable input
 > after the program starts executing. Yes, this includes servers and RT
 > stuff, but also includes such desktop applications as word processing
 > (i.e. Is the next character the user going to input a command or some
 > input?),
 >
 > As for pointer chasing, it depends on the context. If the pointers are
 > used for a sparse array that is known ahead of time, then it would be
 > category A, but if the pointers were to data items in a database page,
 > then it would be category B.
 >
 > I don't know if this distinction has any consequences for computer
 > architecture, but I think this is what he means. Of course, I welcome
 > any corrections from Robert.



 >>For example, think of a CFD simulation. You could, at
 > least in principle, eliminate (or at least correctly predict) every
 > branch, could prefetch every piece of data that would be needed, etc.

I think that this is NOT true of CFD in general.

I think this is only true of the simplest, regular grid, CFD problems. 
Regular grid, and/or incompressible fluids.

Why I think this: anecdotal interaction with CFD experts.

(1) At UIUC one of the fellows I most valued learning from worked on 
CFD. Eventually he left academia to work on modeling stuff like smoke 
and water for a film company, like ILM (Industrial Light and Magic).

He said that the old, regular, grid type solvers where passe'.  When he 
wanted to work on compressible fluids, gas flow, turbulence, he said 
that it was largely pointer problems - irregular, changing, grids.  And 
because he was interested in turbulence, the structure of the irregular 
grid was not known in advance.

This was the guy who helped me formulate my notion of the ratio of 
compute the pointer chasing.  And while he could not foresee there being 
fewer than circa 100 FLOPS at each grid node, he helped me draw graphs 
showing precipitous decline over time.

(2) Another CFD guy I know of models flows of deformable bags of liquid. 
  Not really  turbulent, but certainly not regular either.




Now, Robert knows more about this field than I do - although I am not 
sure that he knows more about it than the guys I refer to above.

Robert and I share a common interest in bandwidth of non-sequential 
access patterns.  Snarf a few words or a cache line, at a location, and 
then move to a non contiguous location.

FFT style access patterns, such as Robert has talked about, are 
precomputable, prefetchable.

But irregular, dynamic, grid access patterns are much less precomputable.

I wonder how far the commonality between these two workloads can be 
stretched.

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

#3481

On Sep 5, 5:40 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:

> Now, Robert knows more about this field than I do - although I am not
> sure that he knows more about it than the guys I refer to above.
>
Just as it wasn't my intention to fix computer architecture, it isn't
my intention to fix everyday CFD.  I'm a complete heretic: I don't
believe any of it.  As far as I'm concerned, most of it is just
pretty, plausible-looking pictures with very little science and even
less credible mathematics.  Needless to say, I'm no more popular in
the CFD community than I am in the computer architecture community.

Sure, you can stretch grids to fit around weird, moving objects.
Since we don't even understand what's going on in the fully turbulent
free-field case, why would we believe any of this conforming grid
stuff?  Someone who knows no fluid mechanics at all claimed to me that
we know how to predict storm tracks.  That's pure NOAA hype.  We don't
know how to predict anything, and the way we're going, we never will.

As the conversation has drifted, it would probably be better for my
physical and mental health if I just stopped paying attention to the
warehouse computer game.  It's a gigantic waste of money, but there is
little I can do about it.  As discussed here in some detail, the
problems I understand best can, at the moment, best be attacked with
rather small machines.  For whatever it's worth, I think the lattice
QCD people are making the exact same mistake that worries me about
CFD, and I have absolutely no clue as to how much confidence I should
put into into strong-field GR calculations, but I don't believe any of
it, either.

For whatever it's worth, you don't *have* to abandon regular meshes to
accommodate irregular moving boundaries.  I've done such calculations,
but I never bothered to publish because I just became disgusted with
the whole business.  Fully three-d, viscous, separated incompressible
flow around a delta wing.  Which is worse to get wrong: the details of
the boundary, or the mathematics of the free field everywhere else?
Worrying about the details of the boundary makes the most compelling
graphics, that's for sure.

Just to be clear: I don't claim to speak for CFD.  I claim to speak
for computation of a class of highly nonlinear equations that is
important to every field theory that isn't a weak field.

> Robert and I share a common interest in bandwidth of non-sequential
> access patterns.  Snarf a few words or a cache line, at a location, and
> then move to a non contiguous location.
>
> FFT style access patterns, such as Robert has talked about, are
> precomputable, prefetchable.
>
> But irregular, dynamic, grid access patterns are much less precomputable.
>
> I wonder how far the commonality between these two workloads can be
> stretched.

There's much more to say here, but this is a forum about computer
architecture.

Robert.

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

#3508

On 9/5/2011 10:26 AM, Andy "Krazy" Glew wrote:
> On 9/2/2011 10:10 AM, Robert Myers wrote:
>
>> There are probably many possible taxonomies for computing, but the one
>> that drives my dislike of IBM having any significant influence over
>> technical supercomputing is that there are
>>
>> a. Calculations where you know days, and maybe even weeks, months, or
>> years ahead of time what will transpire when you run the program.
>>
>> b. Operations where what the computer does next is entirely at the
>> whim of forces completely beyond its control and almost always beyond
>> anyone's ability even to predict such that the system will *always*
>> even run reliably.
>>
>> Most technical computing is category a and all but small slices of
>> business computing are category b. More and more business computing
>> that might at one time have fit into category a is gradually sliding
>> into category b, as business analytics are increasingly done in real
>> time.
>>
>> Category b has an awful lot of painful constraints, and my hat is off
>> to anyone who can work successfully with those kinds of requirements.
>> Satisfying those requirements must require an awful lot of brain,
>> money, and attention-share, and I would strongly prefer to think that
>> most computers for technical computing were built by people who were
>> only vaguely aware of category b and certainly did not spend most of
>> the work week in that mindset.
>>
>> Itanium was a processor that was clearly built with a category a
>> mindset. That's why itanium got so much of my attention and maybe
>> part of why it failed--that, plus the fact that most of the people who
>> laid hands on Itanium were by habit category b users. How much easier
>> it would be, it seemed to me, to build a really fast category a
>> processor and/or computer because, in most cases, you *do* know the
>> future.
>>
>> By the time you get down to microarchitecture as it is currently
>> practiced, the whole world starts to look like category b. Itanium
>> was a toe in the water of a microarchitecture designed more for
>> category a, and I've taken up a lot of time and space here asking what
>> went wrong because that's the kind of processing that interests me.
>> A computer built almost entirely for category a would have serious
>> issues dealing with remaining category b needs that it couldn't avoid
>> dealing with, but, in my never-sufficiently-humble opinion, if we ever
>> build a supercomputer for technical computing that isn't a sour joke,
>> it will be because all the category b constraints were left behind.
>> That's why I want IBM out of the business.
>
>
> Interesting. How do you characterize your category a versus category b?
>
> Real-time? Server type workloads? Pointer chasing over linked data
> structures?
>
> I agree that Itanium's targeting of server workloads was odd.
>
> I disagree that "microarchitecture as it is currently practiced" favors
> category b. If category b is characterized as I said above.
>
>  From my point of view, the last 10-15 years of microarchitecture have
> been characterized by overemphasizing category a stuff --- witness the
> landslide of SIMD packed vector instructions. GPU SIMD style
> architectures. The overemphasis on sequential access pattern bandwidth.
>
> And my understanding is that you have not been terribly happy with that.
>
> I think that your categorization needs to be tweaked:
>
> Category a
> a.1 sequential and local
> a.2 non-sequential and non-local
>
> Category b
> Not knowing your definition, I'll suppose it to be RT, server, pointer
> chasing.

It is my understanding that VLIW turned out not to be effective on 
server workloads, based on events and stories from the past.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch

csiph-web