Re: Cobol Myth Busters

Binary (when working with other Binary) may or may not be faster than PD for
some cases on zSeries. However, there are even MORE options that impact this
than just TRUNC (wich has 3 flavors on IBM zSeries). Furthermore, PD is usually
(not always) BEST when working with "combined" usages (such as input from a
"screen" in the same operation as something stored in a Database).

The following is the information on "comapring data types" for the Enterprise
COBOL Performance paper available at:
http://www-1.ibm.com/support/docview.wss?rs=203&q=7001475&uid=swg27001475

(You might want to look at the entire paper to see what a COMPREHENVISE set of
performance test covers - in the way of "variations. Also it has some firm
statistics on indexes vs subscripts with this compiler.)

***

Comparing Data Types

When selecting your data types, it is important to understand the performance
characteristics of them before you use them. Shown below are some performance
considerations of doing several ADDs and SUBTRACTs on the various data types of
the specified precision.

Performance considerations for comparing data types (using ARITH(COMPAT)):

Packed decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(STD)
using 1 to 9 digits: packed decimal is 30% to 60% slower than binary
using 10 to 17 digits: packed decimal is 55% to 65% faster than binary
using 18 digits: packed decimal is 74% faster than binary

Packed decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(OPT)
using 1 to 8 digits: packed decimal is 160% to 200% slower than binary
using 9 digits: packed decimal is 60% slower than binary
using 10 to 17 digits: packed decimal is 150% to 180% slower than binary
using 18 digits: packed decimal is 74% faster than binary

Packed decimal (COMP-3) compared to binary (COMP or COMP-4) with TRUNC(BIN) or
COMP-5
using 1 to 8 digits: packed decimal is 130% to 200% slower than binary
using 9 digits: packed decimal is 85% slower than binary
using 10 to 18 digits: packed decimal is 88% faster than binary

DISPLAY compared to packed decimal (COMP-3)
using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
using 17 to 18 digits: DISPLAY is 150% to 200% slower than packed decimal

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(STD)
using 1 to 8 digits: DISPLAY is 150% slower than binary
using 9 digits: DISPLAY is 125% slower than binary
using 10 to 16 digits: DISPLAY is 20% faster than binary
using 17 digits: DISPLAY is 8% slower than binary
using 18 digits: DISPLAY is 25% faster than binary

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(OPT)
using 1 to 8 digits: DISPLAY is 350% slower than binary
using 9 digits: DISPLAY is 225% slower than binary
using 10 to 16 digits: DISPLAY is 380% slower than binary
using 17 digits: DISPLAY is 580% slower than binary
using 18 digits: DISPLAY is 35% faster than binary

DISPLAY compared to binary (COMP or COMP-4) with TRUNC(BIN) or COMP-5
using 1 to 4 digits: DISPLAY is 400% to 440% slower than binary
using 5 to 9 digits: DISPLAY is 240% to 280% slower than binary
using 10 to 18 digits: DISPLAY is 70% to 80% faster than binary

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@xxxxxx> wrote in message
news:iu8pd39fh6huj8r55ksnpd6g2s6ildmdvd@xxxxxxxxxx
On Mon, 03 Sep 2007 13:26:53 -0300, Clark F Morris <cfmpublic@xxxxxxxxxxxxxxx>
wrote:

On Fri, 31 Aug 2007 21:22:35 -0500, Robert <no@xxxxxx> wrote:

Test:
05 display-number pic 9(09).
05 packed-number comp-3 pic s9(09).

add 1 to display-number *> 174 us
add 1 to packed-number *> 160 us

Finding: CONFIRMED. Packed is almost as slow as display. It was fast on
1970-era
mainframes. There is no longer any reason to use it. If you want to save
space, look at
space-filled strings and filler-padding.

There may be other good reasons to go to display but if you are using
a z series computer (latest evolution of the IBM 360), packed decimal
is still faster than display.

I would expect binary to be the fastest on a z series, as it is on every other
computer.

Most results depend on the computer architecture.

The program shouldn't be tied to a specific machine, especially when the
feature is out of
step with industry norms. Doing so locks users into one manufacturer, which is
contrary to
the spirit of high level languages.

I suspect in answer to your next question that
alignment still matters on some currently sold computers with an
architecture different from the ones tested on.

Yes, some CPUs don't require alignment e.g. IBM, Motorola, Intel 16/32 bit.
Some throw an
exception and expect the operating system to handle it in software
(expensively)
i.e.IA-64, most RISC machines including PA, PowerPC and Alpha. A few
operating systems
abort the process when they get a misalignment fault e.g. old Apple.

Micro Focus' use of IBMCOMP for the compiler option that turns on memory
boundary
awareness gives the impression that is (or was) a concern in the IBM mainframe
world. Not
in my experience. I've never seen a mainframe, IBM or other, throw a fault for
misalignment. It doesn't seem appropriate for ANY machine with an L2 cache to
do so. I
wrote the speed program primarily to test whether a modern PA processor
(88xx/89xx, which
have L2) is slowed down by misalignment, secondarily to disprove (or not)
Cobol myths
such as ODO being slow and demonstrate real inefficiencies such as packed
decimal.

FWIW, IBM coined the word cache in the context of memory in 1967. The S/360
model 85 was
probably the first computer to use memory cache.
http://en.wikipedia.org/wiki/Memory_cache



.

Relevant Pages

  • Re: FPGA Journal Article
    ... 10 decimal digits fixed-point display, ... Above 1 MHz limited by time base accuracy, below 1 MHz by display ... but clutter up the design. ... A 20 times more accurate time base would cost <$20 extra. ...
    (comp.arch.fpga)
  • Re: Price Data Formatting
    ... When you load in a datafile of a stock or commodity, ... only 3 digits following the decimal rather than 4. ... So when I display prices in my application, I want to use the SAME format as ... It doesn't fit well in my textboxes for display. ...
    (microsoft.public.vb.general.discussion)
  • Re: Reducing load for LAMP app?
    ... Using microtime() as-is: 2.6941299438477E-5 ... 2.6941299438477E-5 is standard scientific notation for display of very large or very small numbers. ... Another point here is that floating point numbers have up to 15 significant digits ... I'd suggest you follow up in the Linux admin groups - where the experts hang out. ...
    (comp.lang.php)
  • Re: 7-bar display
    ... I would like to display digits with a 7-bar display, ... mitred just like on a pocket calculator. ... Maybe the font solution would be best. ... I just thought of another way you could do your calculator digits. ...
    (comp.infosystems.www.authoring.html)
  • Re: 7-bar display
    ... I would like to display digits with a 7-bar display, ... mitred just like on a pocket calculator. ... Maybe the font solution would be best. ... I just thought of another way you could do your calculator digits. ...
    (comp.infosystems.www.authoring.html)