25 Oct
2011
25 Oct
'11
3:39 a.m.
From: Joost van de Griek <gyorpb at gmail.com>
A long time ago, I was instructed that the
"native" S/370 (integer) data
format was S9(4) COMP and that it should be used whenever possible for
fastest performance (counters, indices, etc.).
I don't believe this was ever true on System 370 and as far as I know, not
on S/360 either. In IBM COBOL S9(4) COMP is a signed, halfword binary
integer. There are instructions to do halfword adds, subtracts, etc. but
the fullword version is probably faster or cheaper since the halfword
instructions produce a fullword result. You may as well get the full
operand width and use the fullword instructions. More than performance, the
issue was probably storage in those days. A fullword is twice as big as a
halfword and when you have less than a meg of core every couple of bytes
counts. Halfword counters have a pretty small range so you have to make sure
whatever you're counting will fit or that rollover doesn't hurt your code.
Counters in COBOL are usually non-negative and indices should be
non-negative unless you like taking chances with unsupported features. I
know at least one guy who did this. He exceeded the permissible size of a
table so he defined another one before it and used negative indexing (or
subscripting) to point to the previous table in storage even thought the
code referred to the second! Anyway in the counter or index case you would
normally be better off with an unsigned 9(4) COMP where 0 to 65535 was
enough range or 9(8) COMP if you need 0...(2^32)-1. Again this is all for
counters and indices as you said, for money it's inappropriate.
I've now worked on non-IBM iron long enough that
when I go back to the
360 family, I'll have to resort to the manuals to see if that still holds
true and what formats are preferred these days on the fancy Z hardware.
Nothing has changed, there are data types for all occasions and the only
thing added was the IEEE floating point with either XA or ESA, long ago.
Use packed decimal for money, fixed point binary for counters and indexes,
zoned for display fields, and hex or binary floating point if you like to
go head to head with Chuck on number crunching benchmarks!
Programming with performance in mind is a vanishing
art and an unpopular
skill (in practice, that is; on paper, everybody pays lip service to it)
these days. The solution is almost invariably to throw new hardware at
the problem. Can't blame them, really. I mean, if I were in charge and a
programmer told me, "give me three years and I'll have it running twice
as fast on the current hardware," I'm pretty sure my reaction wouldn't be
to give the go-ahead on that one.
In practice choosing the right approach and coding sanely seems to produce
satisfactory results in critical pieces of code. I'm talking about the
commercial space because that's where you and I work and this may not apply
to embedded or other environments where the pipelining and
microoptimizations are better understood than where we work. Nobody should
think performance isn't a deadly serious thing in our environment, as you
said, the batch window is a factor and system availability is no joke
because of the fines, loss of revenue, and loss of customers that occur
when production is not up on time. Sometimes that is all the time. Companies
are willing to spend millions of dollars on one product to measure their
throughput or improve their transaction rate.