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

Groups > alt.folklore.computers > #156518 > unrolled thread

IBM STRETCH repricing decision?

Back to article view | Back to alt.folklore.computers

Contents

  IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-12 09:37 -0800
    Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-12 15:59 -0800
      Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-12 16:01 -0800
      Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-12 18:50 -0800
        Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-12 23:37 -0800
          Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-13 07:24 -0800
            Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-13 14:37 -0800
        Re: IBM STRETCH repricing decision? Morten Reistad <first@last.name.invalid> - 2016-01-13 08:37 +0100
          Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-13 07:39 -0800
            Re: IBM STRETCH repricing decision? Anne & Lynn Wheeler <lynn@garlic.com> - 2016-01-13 08:17 -0800
              Re: IBM STRETCH repricing decision? Jon Elson <elson@pico-systems.com> - 2016-01-13 18:02 -0600
            Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-13 12:58 -0800
              Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-13 13:53 -0800
                Re: IBM STRETCH repricing decision? Quadibloc <jsavard@ecn.ab.ca> - 2016-01-13 14:31 -0800
                  Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-13 18:38 -0800
                Re: IBM STRETCH repricing decision? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-01-13 22:43 +0000
                  Re: IBM STRETCH repricing decision? "J. Clarke" <j.clarke.873638@gmail.com> - 2016-01-13 20:13 -0500
                  Re: IBM STRETCH repricing decision? Gene Wirchenko <genew@telus.net> - 2016-01-13 17:17 -0800
                  Re: IBM STRETCH repricing decision? hancock4@bbs.cpcn.com - 2016-01-13 18:32 -0800
                    Re: IBM STRETCH repricing decision? "J. Clarke" <j.clarke.873638@gmail.com> - 2016-01-13 21:51 -0500
                      Re: IBM STRETCH repricing decision? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-01-14 18:24 +0000
                Re: IBM STRETCH repricing decision? "J. Clarke" <j.clarke.873638@gmail.com> - 2016-01-13 20:04 -0500
              Re: IBM STRETCH repricing decision? Peter Flass <peter_flass@yahoo.com> - 2016-01-14 08:03 -0500
            Re: IBM STRETCH repricing decision? Jon Elson <elson@pico-systems.com> - 2016-01-13 17:49 -0600
              Re: IBM STRETCH repricing decision? Peter Flass <peter_flass@yahoo.com> - 2016-01-14 08:03 -0500

Page 1 of 2  [1] 2  Next page →

#156518 — IBM STRETCH repricing decision?

As is well known, when IBM discovered that its new STRETCH
super-computer didn't perform as fast as expected, it sharply
lowered the price.  Only a few customers were allowed to buy
it as IBM lost money on each sale.  I think the original
price was $13 million and the new price was $7 million.

Did IBM overreact and lower the price too much?  While
STRETCH throughput wasn't as fast as originally expected,
it was none the less the most powerful machine of its
time, and extremely reliable and easy to use.  Its customers
loved it and kept it in service for many years.

Given customer acceptance, I wonder if the price reduction
was too much.

Also, since IBM was only "in negotiations" with other customers,
why was it obligated to sell a money-losing machine to them?
There apparently was no contract or obligation.  I wonder if
IBM could've offered it at, say construction cost, and if
the customers still wanted it, then go build it.

[toc] | [next] | [standalone]

#156562

On Tuesday, January 12, 2016 at 10:37:51 AM UTC-7, hanc...@bbs.cpcn.com wrote:
 
> Also, since IBM was only "in negotiations" with other customers,
> why was it obligated to sell a money-losing machine to them?

The price cut was basically a fit of pique by Watson.

Otherwise, even if, to maintain his company's reputation, he lowered the price to 
the existing customers by the same factor as the performance was lowered, he 
could still have continued to offer the computer at the old price to those who 
thought it was still worth it.

What I remember is that the old price was $13.5 million, and the new price was 
$7.5 million, but I'll check.

John Savard

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

#156563

On Tuesday, January 12, 2016 at 4:59:37 PM UTC-7, Quadibloc wrote:

> What I remember is that the old price was $13.5 million, and the new price was 
> $7.5 million, but I'll check.

I was half right. The new price was actually $7.78 million.

John Savard

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

#156570

On Tuesday, January 12, 2016 at 6:59:37 PM UTC-5, Quadibloc wrote:

> The price cut was basically a fit of pique by Watson.

Thanks for your comments.

That was my feeling, and what prompted me to introduce the discussion
to see what others thought.

Managers don't like to be surprised with bad news out of the blue.
They throw temper tantrums.

From the IBM history, my impression was that the Stretch designers
were working with many experimental pieces, for which the actual 
performance would not be known until everything was done and put 
together.  The new transistors were fast, but not as fast as expected.
The parallel processing was fast, but not as fast as expected.

Because it was an experimental system, it seemed Watson's anger 
at Dunwell wasn't justified.  Watson finally realized that a 
few years later.

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

#156578

On Tuesday, January 12, 2016 at 7:50:57 PM UTC-7, hanc...@bbs.cpcn.com wrote:

> The parallel processing was fast, but not as fast as expected.

Of course, in hindsight, one wonders how they _expected_ performance gains from 
pipelining when the machine didn't even have general registers - it had a 
memory-accumulator architecture. (And out-of-order execution hadn't been 
invented yet.)

So how on Earth was the machine supposed to work on another instruction until 
it had finished executing the previous one?

However, I also remember reading a statement somewhere to the effect that later 
fixes to the machines in the field got the machines to achieve their expected 
performance, so the customers got their $13.5 million's worth for only $7.78 
million. I'd be interested in finding out just what changes were made to 
achieve that.

John Savard

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

#156584

On Wednesday, January 13, 2016 at 2:37:43 AM UTC-5, Quadibloc wrote:

> Of course, in hindsight, one wonders how they _expected_ performance gains from 
> pipelining when the machine didn't even have general registers - it had a 
> memory-accumulator architecture. (And out-of-order execution hadn't been 
> invented yet.)
 
> So how on Earth was the machine supposed to work on another instruction until 
> it had finished executing the previous one?

The Stretch book ("Planning a Computer System Project Stretch" 
on bitsavers) says:

  Information moves between the input-output devices and the memories
under control of the exchange. The central processing unit (CPU)
actually consists of several units that may operate concurrently: an
instruction unit, which controls the fetching and indexing of instructions
and executes the instructions concerned with indexing arithmetic; a lookahead
unit, which controls fetching and storing of data for several instructions
ahead of the one being executed, so as to minimize memory traffic
delays; a parallel arithmetic unit, for performing binary arithmetic on
floating-point numbers at very high speed ; and a serial arithmetic unit,
for performing binary and decimal arithmetic, alphanumeric operations,
Lind logical-connective operations on fields of varying lengths.


3.1 0. Instruction Look-ahead
  After initiating a reference to memory for a data word, the instruction
unit passes the modified instruction on to the look-ahead unit. This unit
nolds the relevant parts of thc instruction until the data arrive, so that
both the operation and its operand can be sent) to the arithmetic uiiit
together. Since access to the dcsired memory unit takes a relatively long
time, the look-ahead will accept several instructions at a time and
iiiitiate their memory references, so as to smooth out the memory traffic
and obtain a high degree of overlap between memory units. Thus
the unit "looks" several instructions ahead of the instruction being
executed and anticipates the memory references needed. This reduces
delays and keeps the arithmetic unit in as nearly continuous operation
as possible.

  Indexing and branching instructions are completed by the instruction
unit without involving the main arithmetic unit. The instruction unit
receives its own operands, whereas the look-ahead receives operands for
the main arithmetic unit. The look-ahead, however, is responsible for
storing all results for both units, so that permanent modification of stored
information is done in the proper logical sequence. Interlocks in the
look-ahead unit ensure that nothing is altered permanently until all preceding
instructions have been executed successfully.




> However, I also remember reading a statement somewhere to the effect that later 
> fixes to the machines in the field got the machines to achieve their expected 
> performance, so the customers got their $13.5 million's worth for only $7.78 
> million. I'd be interested in finding out just what changes were made to 
> achieve that.

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

#156605

On Wednesday, January 13, 2016 at 8:24:09 AM UTC-7, hanc...@bbs.cpcn.com wrote:
 
> The Stretch book ("Planning a Computer System Project Stretch" 
> on bitsavers) says:

I think I saw that passage. It does show that the Stretch had some features that 
at least relate to out-of-order techniques.

But while a Stretch could be efficiently programmed by mixing variable-length 
field, index arithmetic, and floating-point instructions, given that it had a 
single floating-point accumulator, it doesn't appear that anything described 
there would allow multiple floating-point instructions to be in the execute 
part of the pipeline (they could still be classically overlapped in the coarse 
fetch, decode, execute fashion) at the same time. Because they all go through 
the accumulator.

So the benefits of having a longer pipeline than that of the 7094 II are 
usually not available, as a program doing heavy floating-point calculations 
won't have enough index arithmetic or VLF instructions to interleave.

At least, that's how it seems to me.

John Savard

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

#156579

In article <16b10215-5707-4848-b9dc-74ff48b76b9a@googlegroups.com>,
 <hancock4@bbs.cpcn.com> wrote:
>On Tuesday, January 12, 2016 at 6:59:37 PM UTC-5, Quadibloc wrote:
>
>> The price cut was basically a fit of pique by Watson.
>
>Thanks for your comments.
>
>That was my feeling, and what prompted me to introduce the discussion
>to see what others thought.
>
>Managers don't like to be surprised with bad news out of the blue.
>They throw temper tantrums.
>
>From the IBM history, my impression was that the Stretch designers
>were working with many experimental pieces, for which the actual 
>performance would not be known until everything was done and put 
>together.  The new transistors were fast, but not as fast as expected.
>The parallel processing was fast, but not as fast as expected.
>
>Because it was an experimental system, it seemed Watson's anger 
>at Dunwell wasn't justified.  Watson finally realized that a 
>few years later.

The strategy of IBM in the 360 and early 370 era seems to be one
of shotgun aiming at the market; run a lot of different products, 
and let the customers respond as they would. This way they had
a lot of successes and some failures. This goes with the territory
of such broad aims.

I don't think anyone could have predicted which models would
sell and which wouldn't 5 years ahead of the launch, 8 years
prior to settlement of success/failure. 

This approach was made possible by having a line of program
and (mostly) peripherals compatibility.

-- mrr

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

#156585

On Wednesday, January 13, 2016 at 2:37:55 AM UTC-5, Morten Reistad wrote:

 
> The strategy of IBM in the 360 and early 370 era seems to be one
> of shotgun aiming at the market; run a lot of different products, 
> and let the customers respond as they would. This way they had
> a lot of successes and some failures. This goes with the territory
> of such broad aims.
> 
> I don't think anyone could have predicted which models would
> sell and which wouldn't 5 years ahead of the launch, 8 years
> prior to settlement of success/failure. 
> 
> This approach was made possible by having a line of program
> and (mostly) peripherals compatibility.


The S/360 history goes into detail about IBM's planning processes
that developed what became S/360.  While it was definitely intended
to be a broad spectrum serving the whole DP market, I don't think
it was a "random" or shotgun approach.  Rather, the various models
were _generally_ developed to serve particular markets, based on
IBM's experience with its existing product line, competing models, 
and conversations with its customers.  Certainly, as development was
underway, there were many compromises in what features a given 
model had in order to maintain an orderly product line and pricing.

The marketplace and technology evolved over System/360, and new
models were introduced at both the low end (e.g. model 20) and high
end (85, 91, 95, 195).  

S/360 failed in its goal to be a "universal" architecture because
it was still too cumbersome to be used in the smallest machines.
Thus, the model 20 had a stripped-down instruction set, and the 1130
had its own instruction set; both machines were 'budget' models,
and both were very successful as such.  However, it was still 
necessary for IBM to develop the System/3, which used a completely
different architecture and deliberate low-budget design.

However, S/360 was enormously successful in the marketplace, more
so than IBM expected.  (I don't know the expected and actual sales
counts for specific models.)

System/370 got muddled because IBM was unsure of the future of
various components, and was diverted with Future System.  None
the less, despite the setbacks, IBM generally did well with S/360
successor products.  Sadly, IBM let itself get bloated and almost
suffocated itself.

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

#156587

hancock4@bbs.cpcn.com writes:
> System/370 got muddled because IBM was unsure of the future of
> various components, and was diverted with Future System.  None
> the less, despite the setbacks, IBM generally did well with S/360
> successor products.  Sadly, IBM let itself get bloated and almost
> suffocated itself.

This end of ACS-360 also has some discussion of pricing &
price/performance model ... including shutting down ACS-360 because
executives thot that it would advance the state-of-the-art too fast and
IBM would loose control of the market
http://people.cs.clemson.edu/~mark/acs_end.html


Of the 26,000 IBM computer systems in use, 16,000 were S/360 models
(that is, over 60%). [Fig. 1.311.2]

Of the general-purpose systems having the largest fraction of total
installed value, the IBM S/360 Model 30 was ranked first with 12%
(rising to 17% in 1969). The S/360 Model 40 was ranked second with 11%
(rising to almost 15% in 1970). [Figs. 2.10.4 and 2.10.5]

Of the number of operations per second in use, the IBM S/360 Model 65
ranked first with 23%. The Univac 1108 ranked second with slightly over
14%, and the CDC 6600 ranked third with 10%. [Figs. 2.10.6 and 2.10.7]

... and

To achieve a profit for the ACS program, Amdahl asked IBM management to
approve three ACS-360 models: the high-performance design, a 1/3
performance version, and a 1/9 performance version. He felt that these
performance goals would be a good fit with the System 360 marketing
plans. He remembers that IBM Corporate Marketing evaluated the targets
and reported: "1) the supercomputer alone was a loss leader! 2) the
supercomputer plus the 1/3 performance computer was break-even! And 3)
the supercomputer plus both the 1/3 performance computer and the 1/9
performance computer was normal profit -- 30% pre-tax!"

... snip ...

it also has discussion of ACS-360 features that show up 20yrs later with
es/9000.

this account by former IBM executive says that major motivation for
"Future System" was trying to lock out "clone controllers"
http://www.ecole.org/en/seances/CM07

unfortunately during FS period, internal politics was shutting down 370
efforts ... and the lack of new 370 products during this period is
credited with giving "clone processors" a market foothold.

past posts
http://www.garlic.com/~lynn/submain.html#futuresys

trivia ... as undergraduate I tried to do some stuff with 2702 terminal
controller ... which it couldn't quite do. This was part of the
motivation for the univ. to do a clone controller effort ... starting
with Interdata/3 ... later morphed into a combination of Interdata/4 for
the channel interface and cluster of Interdata/3s for line/port
scanners. Interdata (later acquired by P/E) markets this as commerical
product. Somewhere there is writeup that credits four of us for (some
part of the) clone controller market.
http://www.garlic.com/~lynn/subtopic.html#360pcm

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

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

#156610

Anne & Lynn Wheeler wrote:


> 
> This end of ACS-360 also has some discussion of pricing &
> price/performance model ... including shutting down ACS-360 because
> executives thot that it would advance the state-of-the-art too fast and
> IBM would loose control of the market
> http://people.cs.clemson.edu/~mark/acs_end.html
> 
> 

This never made much sense to me.  If the ACS had worked and been brought 
out at even a much-reduced level of performance, they would have CREAMED the 
competition!  If IBM had been able to deliver a TCM (thermal conduction 
module) ECL based machine in 1970, the rest of the industry would have been 
bowing and genuflecting, and going out of business.  The specs for the ACS 
were completely out of touch with what components were available at the 
time, and some test modules proved it.  ACS had claimed they'd have a 
machine with a 10 ns cycle time and 7 logic levels between registers.  They 
built a 12-bit counter and got, I think, 12 ns clock with what should be 4 
logic levels between registers, which was QUITE good for pre-1970 ECL 
components.  I think with strong effort to reduce the number of logic 
levels, they could have maybe built a machine with a 50 MHz clock, and 
totally blown all competitors away.  Even Seymour Cray would have been 
scrambling to keep up with that.

But, my take is that while they could develop some of this in the lab, they 
were VERY far from hardware that could be mass-produced and maintained in 
the field.  IBM had PLENTY of hassle getting TCM technology to work, it took 
them about a whole decade to really get there.  I think the 308x systems 
were where ACS was headed in hardware packaging, and that's where IBM 
finally got it all together as a technology they could deliver and maintain 
in the field.

Jon

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

#156595

On Wednesday, January 13, 2016 at 8:39:30 AM UTC-7, hanc...@bbs.cpcn.com wrote:

> S/360 failed in its goal to be a "universal" architecture because
> it was still too cumbersome to be used in the smallest machines.

This reminds me. I remember recently reading that the memory-to-memory packed 
decimal instructions were a mistake in the 360 architecture as originally 
conceived.

They're certainly a mistake *nowadays*, with DRAM latency so excruciatingly 
slow.

However, this is now, and that was then.

It's obvious _why_ the decimal instructions were like that on the 360.

The IBM 1401 was *much* more popular than the IBM 7070/7074. IBM's other 
decimal architecture, the 705/7080, also used variable length decimal numbers 
in memory.

The 1401 and the 7080 both did arithmetic on numbers in the form of strings of 
6-bit characters; the 1401 used a bit to mark where a number begins, the 
705/7080 used a terminating character to show were it ended.

So the 360, although it used packed decimal, and had a field in the instruction 
giving the length of a number, was intended to be 1401-like when doing decimal 
arithmetic. This way, it would work well, and be a good fit, for the machines 
in the lower end of the 360 range, which would likely be the most popular for 
commercial customers.

The binary arithmetic and floating-point instructions, on the other hand, while 
they had the additional benefit of multiple general registers to work with, 
were following in the tradition of the 704/7090 line of big scientific 
computers. So they were most efficiently implemented on the largest computers 
in the 360 line.

So the 360 architecture in this respect, although it turned out to be 
long-lived, was very much the product of a particular time.

John Savard

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

#156598

On Wednesday, January 13, 2016 at 3:58:44 PM UTC-5, Quadibloc wrote:

> It's obvious _why_ the decimal instructions were like that on the 360.
> The IBM 1401 was *much* more popular than the IBM 7070/7074. IBM's other 
> decimal architecture, the 705/7080, also used variable length decimal numbers 
> in memory.
> The 1401 and the 7080 both did arithmetic on numbers in the form of strings of 
> 6-bit characters; the 1401 used a bit to mark where a number begins, the 
> 705/7080 used a terminating character to show were it ended.
> So the 360, although it used packed decimal, and had a field in the instruction 
> giving the length of a number, was intended to be 1401-like when doing decimal 
> arithmetic. This way, it would work well, and be a good fit, for the machines 
> in the lower end of the 360 range, which would likely be the most popular for 
> commercial customers.

Historically, IBM computers marketed to business used character and
decimal arithmetic, while computers marketed to sci/eng used
words and binary arithmetic.

I don't think the choice of decimal instruction was because certain
heritage machines used it.  Rather, I think it was because decimal
was more efficient for business calculations.  There wasn't a waste
of CPU to convert the number to binary and back.  While decimal
was slower, it didn't matter as much for the simpler business calculations.

Decimal would be used regardless if the business operation was small
or large.

For S/360, amazingly, many younger COBOL programmers were not aware
of COMP-3 (packed decimal), which would save memory and time.  (Now,
it doesn't matter).


> The binary arithmetic and floating-point instructions, on the other hand, while 
> they had the additional benefit of multiple general registers to work with, 
> were following in the tradition of the 704/7090 line of big scientific 
> computers. So they were most efficiently implemented on the largest computers 
> in the 360 line.

Binary is best for the heavy duty scientific/engineering calculations.
I believe the 1130 is a binary machine, since it was for sci/eng, even
though it was small.  


> So the 360 architecture in this respect, although it turned out to be 
> long-lived, was very much the product of a particular time.

The S/360 architecture was also a product of many compromises in 
order to make it a universal architecture--large and small, sci/eng
and business.  S/360 replaced four separate machine types.

It was not an easy decision, and many in IBM fought it passionately,
feeling dedicated machine types were the preferable way to go.  One
manager quietly built a 'super' 1401 using  S/360 components.  But
the universal machine had to be universal.

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

#156604

On Wednesday, January 13, 2016 at 2:53:39 PM UTC-7, hanc...@bbs.cpcn.com wrote:

> I don't think the choice of decimal instruction was because certain
> heritage machines used it.  Rather, I think it was because decimal
> was more efficient for business calculations.  There wasn't a waste
> of CPU to convert the number to binary and back.

I was not attempting to suggest otherwise.

My point in citing specific machines prior to the 360 was to explain a 
particular tradeoff in how decimal was implemented on the 360.

It could have done decimal arithmetic in registers - a 16-digit decimal number 
could have gone into a pair of general registers. Today, this would seem much 
more efficient and sensible.

So my point was that IBM's prior machines indicated to IBM that commercial 
users would be most interested in smaller machines, while scientific users 
would be interested in bigger ones. So they implemented decimal arithmetic on 
the 360 in a memory-to-memory fashion because that was a good fit for the 
smaller machines.

That decimal is used for business calculations to save time on conversions - 
that I didn't note because it is common background knowledge.

John Savard

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

#156622

On Wednesday, January 13, 2016 at 5:31:16 PM UTC-5, Quadibloc wrote:

[snip]

 
> So my point was that IBM's prior machines indicated to IBM that commercial 
> users would be most interested in smaller machines, while scientific users 
> would be interested in bigger ones. So they implemented decimal arithmetic on 
> the 360 in a memory-to-memory fashion because that was a good fit for the 
> smaller machines.

While IBM did have the 1460 and 1410 for larger customers, I think 
some large business users made use of the 709x series; though I have
no idea how many.  SABRE did it use, for example.

(I know of a few customers who got an 1130 for their business applications,
too, probably because it was cheap.)

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

#156606

On 2016-01-13, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:

> I don't think the choice of decimal instruction was because certain
> heritage machines used it.  Rather, I think it was because decimal
> was more efficient for business calculations.  There wasn't a waste
> of CPU to convert the number to binary and back.  While decimal
> was slower, it didn't matter as much for the simpler business calculations.
>
> Decimal would be used regardless if the business operation was small
> or large.

The other reason packed decimal was used was the size of the fields.
A 32-bit binary field was just not enough to hold financial amounts
of any size; if you used integer pennies you couldn't handle amounts
over $21,474,836.47 - and several orders of magnitude less if you
left room for the guard digits that many calculations require.
Packed decimal fields, on the other hand, could hold up to 31 digits.

(If anyone mentions floating point for monetary amounts, I'll send
a couple of guys from the accounting department over to beat you up.)

> For S/360, amazingly, many younger COBOL programmers were not aware
> of COMP-3 (packed decimal), which would save memory and time.  (Now,
> it doesn't matter).

I once came across just the opposite in a program whose excessive
CPU usage I was called in to analyze - some bright bulb had declared
all subscripts as COMP-3.  Changing them to COMP-4 (binary) cut the
CPU usage by 30%.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

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

#156613

In article <n76jul07ev@news3.newsguy.com>, cgibbs@kltpzyxm.invalid 
says...
> 
> On 2016-01-13, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> 
> > I don't think the choice of decimal instruction was because certain
> > heritage machines used it.  Rather, I think it was because decimal
> > was more efficient for business calculations.  There wasn't a waste
> > of CPU to convert the number to binary and back.  While decimal
> > was slower, it didn't matter as much for the simpler business calculations.
> >
> > Decimal would be used regardless if the business operation was small
> > or large.
> 
> The other reason packed decimal was used was the size of the fields.
> A 32-bit binary field was just not enough to hold financial amounts
> of any size; if you used integer pennies you couldn't handle amounts
> over $21,474,836.47 - and several orders of magnitude less if you
> left room for the guard digits that many calculations require.
> Packed decimal fields, on the other hand, could hold up to 31 digits.
> 
> (If anyone mentions floating point for monetary amounts, I'll send
> a couple of guys from the accounting department over to beat you up.)

I always heard that too.  You know what?  Very late in my career I found 
myself working for a Fortune 100 financial services company with about 
half a trillion in managed assets.  And I was quite surprised to find 
that much of the code that does the managing uses 8-byte floating point.
 
> > For S/360, amazingly, many younger COBOL programmers were not aware
> > of COMP-3 (packed decimal), which would save memory and time.  (Now,
> > it doesn't matter).
> 
> I once came across just the opposite in a program whose excessive
> CPU usage I was called in to analyze - some bright bulb had declared
> all subscripts as COMP-3.  Changing them to COMP-4 (binary) cut the
> CPU usage by 30%.

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

#156614

On 13 Jan 2016 22:43:33 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:

[snip]

>(If anyone mentions floating point for monetary amounts, I'll send
>a couple of guys from the accounting department over to beat you up.)

     Send them then.

     I have done it in JavaScript where the only number type there is
is floating point.

     The trick is to use integers.  These can be represented exactly.

[snip]

Sincerely,

Gene Wirchenko

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

#156621

On Wednesday, January 13, 2016 at 5:44:01 PM UTC-5, Charlie Gibbs wrote:

> (If anyone mentions floating point for monetary amounts, I'll send
> a couple of guys from the accounting department over to beat you up.)

FORTRAN students learn that when they do a simple calculation,
expecting 3.000 as the answer but getting 2.999.

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

#156623

In article <02910022-435c-446e-9ad0-3170bd965d3a@googlegroups.com>, 
hancock4@bbs.cpcn.com says...
> 
> On Wednesday, January 13, 2016 at 5:44:01 PM UTC-5, Charlie Gibbs wrote:
> 
> > (If anyone mentions floating point for monetary amounts, I'll send
> > a couple of guys from the accounting department over to beat you up.)
> 
> FORTRAN students learn that when they do a simple calculation,
> expecting 3.000 as the answer but getting 2.999.

Adjusting rounding is an important aspect of the use of floating point 
in financial calculations.  It's not difficult, just finicky.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web