| Re: "commercial instruction set" ... I'm not sure that the emulation
of packed decimal and some string functions are limited to commercial
environments as much as they are to the use of these datatypes
and functions by COBOL programmers.
Re: faster VAX 6000-510 ... I don't believe there have been significant
changes in the 6000-5xx cpu chips with respect to packed decimal and
string instructions. The mix of emulated vs hardware instructions may
have changed some but the problem (and performance hit) are still very
much alive in the 6000-5xx systems.
re: Oracle does not support packed decimal nor does it support VAX
datatypes ...Oracle uses its own numeric format for integers,
floating point, and dates. Specifically, a couple of years ago I
helped a customer run Oracle V6 benchmarks on 8840, 8550, 6420, and
6240. The programs were written in COBOL. There was NO performance
hit between the systems that could be contributed to emulated VAX
instructions. (The performance hits were in Oracle's poor handling
of SMP scaling.) Generally, we saw x throughput per VUP regardless
of processor.
Remember, Oracle is written in C and since they don't support our
data types, applications and Oracle performance should be just fine
as there were with my customer. In fact, with the recent changes
in the COBOL compiler, I don't even bother the customer with this
issue any more even though I consider it when doing a config.
After all, with the 6000 product line, you're only one cpu upgrade
away from happiness !!!
-- gerry
|
| Being a COBOL programmer for many years... (among other things...)
In general, as long as the user employs COMP (binary), rather than
COMP-3 (packed) for all of their numeric data, they should not have a
problem. Everything you can do with COMP-3 you can do with COMP and
COMP will be faster and require less space. (Yes Virginia, COBOL even
supports quadwords!)
Unfortunately, I have often encountered a great deal of resistance from
customers coming from traditional mainframes to use COMP rather than
COMP-3. If they insist on using COMP-3, at least have them use the
/INSTRUCTION_SET=NODECIMAL or /INSTRUCTION_SET=GENERIC switch on the
COBOL compiler. But I digress...
The real question that no-one has answered yet is:
"Does the ORACLE pre-compiler support the use of COMP for numeric
fields? If so, how?" (i.e. does it use a temporary COMP-3 field and
then move it to the final COMP field?)
|
| I'm the engineering manager for VAX COBOL. I appreciate all the interest
shown in COBOL performance! A lot of work has been done over the last
year in partnership between
- software engineering and
- hardware engineering and
- the field and
- real live customers and
- IM&T (specifically, DEC's own Payroll group)
to try to understand the performance issues better, and to create
improvements in COBOL V4.4. V4.4 will be submitted to the SSB this
month.
A few specific comments about the discussion thus far:
> the VAX 6000s have the commercial instruction set in firmware
Hmm, I think I'd say "software", not firmware. (But perhaps
different people use these terms slightly differently.) The
instructions are performed under the instruction "emulator",
SYS$LOADABLE_IMAGES:VAXEMUL.EXE.
> The result
> of this is that applications WHICH USE THE COMMERCIAL INSTRUCTION SET
> EXTENSIVELY (typically those written in COBOL, PL/1, & BASIC) don't run
> especially well on the 6000
This statement is literally correct, but the implication of the word
"typically" may be that the problem occurs frequently. Our
experience of the last 3 years indicates that the problem is NOT
typical.
However, when the problem _does_ occur it has enough severity to be
painful, memorable, visible and subject to bad feelings and
groaning. The reason for this is that the applications most
affected are usually very large batch "cruncher" applications which
are required to finish within a given time window. If they don't,
people are legitimately upset.
The perception of the problem is thus worse than the problem. The
perception if of course real and legitimate! If the customer is
unhappy, then he's unhappy! But only a small minority of customers
have actually experienced significant slowdowns, because only a
small minority have real "cruncher" COBOL programs that crunch away
in packed.
PL/1 and BASIC problems are extremely rare. I'm also the mgr for
BASIC and remember only one (1) 6000/BASIC performance complaint
that has reached engineering.
> (similar speed to an 8700, which has half the VUPS).
Of course, this depends which 6000 you're discussing. "Worst case"
performance on a 6000-510 is indeed at about the 8700 level; but
this worst case performance has always been rare and with COBOL V4.4
becomes more rare.
> but the problem (and performance hit) are still very
> much alive in the 6000-5xx systems.
Ah, but try COBOL V4.4 and you'll be happier. Maybe not perfectly
happy, but happier. An official summary of what's new with V4.4
performance will appear before long in the COBOL conference
(CLT::COBOL).
>The major comercial instruction
>missing ar instructions to support the packed decimal datatype.
>This is the COMP-3 datatype in COBOL. Many Comercial applications
>built in the IBM environment use COMP-3. As far as I know this is
>the only performance problem remaining with regard to the commercial
>instruction set.
Rich is right, but there is a subtle wrinkle. Versions of COBOL
_prior_ to V4.4 sometimes used packed-decimal instructions even
when the variable had been declared binary, for reasons of
precision (see also below). "The" major theme of COBOL V4.4 is
to eliminate such usages of packed.
>I am told
>this is because of the extra precision in packed decimal arithmetic.
>(!?)
Um, sort of. The issue here is that packed decimal instructions
will conveniently handle 31 decimal digits in a single instruction.
Binary instructions can handle big numbers too, but you have to
string groups of them together to get the same effect. A single
binary instruction will run out of precision at the longword or
quadword level (roughly equals 9 or 18 decimal digits).
COBOL V4.4 uses groups of binary (non-emulated) instructions to
handle up to 128 bit quantities (roughly 38 decimal digits). Using
groups of binary (native) instructions to replace 1 packed
(emulated) instruction is a _big_ win in COBOL V4.4 (about 20 times
faster).
>Everything you can do with COMP-3 you can do with COMP and
>COMP will be faster and require less space. (Yes Virginia, COBOL even
>supports quadwords!)
Yes, yes, I couldn't have said it better myself! The only thing to
add is that before V4.4 there were exceptions to the rule of going
faster; V4.4 fixes those exceptions and makes COMP consistently
faster on the 6000.
>Unfortunately, I have often encountered a great deal of resistance from
>customers coming from traditional mainframes to use COMP rather than
>COMP-3.
Right. But they might be swayed if you can point out to them that
the industry trend - even among traditional mainframe vendors - is
to move toward smaller, simpler instruction sets. Using binary
datatypes is good on more than just Digital platforms!
For example, see Paul Jalics' "Realizing the Performance Potential
of Cobol", IEEE Software, September 1989, which shows that on the
Unisys 1100/90 COMP is faster than COMP-3. (If you do look this
article up, ignore the graph on the IMB PS/2 Model 80; the graph is
in error [Paul Jalics, private communication, September 1990].)
Also, there will soon be in circulation a SCAN tool that can assist
with conversion of dusty deck COMP-3 programs. (See CLT::COBOL
sometime this month for an announcement)
>I doubt that the commercial instruction set problem would effect
>Oracle or any other database for that matter, unless the application
>was using packed decimal.
Right. But I think that there is a specific question about ORACLE
vs. Rdb here.
With VAX COBOL, you can have SCALED INTEGERS stored in any of three
ways:
- DISPLAY (ascii)
- PACKED
- BINARY
Each can store the same size number. Binary is much more efficient
for processing on 6000s, and does _not_ lose any precision compared
to the other two. Each can be scaled (i.e. implicitly have a
decimal point).
VAX Rdb/VMS supports scaled binary.
ORACLE, according to one of our COBOL FT sites, does not support
scaled binary. So your COBOL application working with an ORACLE
database might have to pick a less efficient datatype.
I asked 2 ORACLE employees about this at DECUS, and got a confusing
answer, so I'm still not sure whether this is an issue with ORACLE
or not.
Does anyone know for sure whether ORACLE supports scaled binary?
>The real question that no-one has answered yet is:
>
>"Does the ORACLE pre-compiler support the use of COMP for numeric
>fields? If so, how?" (i.e. does it use a temporary COMP-3 field and
>then move it to the final COMP field?)
Right again. And in particular, does it support _scaled_ COMP?
I hope these discussions are helpful.
/john
|
| Thanks John, for the most complete & best explanation of this subject I have
seen yet.
As for my original note, and your reply:
>> The result
>> of this is that applications WHICH USE THE COMMERCIAL INSTRUCTION SET
>> EXTENSIVELY (typically those written in COBOL, PL/1, & BASIC) don't run
>> especially well on the 6000
>
> This statement is literally correct, but the implication of the word
> "typically" may be that the problem occurs frequently. Our
> experience of the last 3 years indicates that the problem is NOT
> typical.
By "typically" I didn't mean to imply that it was a common problem; sorry if
it read that way. I was trying to say that applications which use the comml
instrn set **EXTENSIVELY** are often written in COBOL, due to their use of
packed decimal etc.
Thanks again for a very useful reply.
Nige L.
|