Re: Cobol Myth Busters

On Tue, 04 Sep 2007 05:10:29 GMT, "William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote:

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.)

It says an index is 30% faster than a binary subscript. Subscripts require a
multiplication. Both require the addition of base + offset, which is usually 'free', i.e.
the referencing operand is base:index. So the difference is multiply versus load. Machines
can do either in one execution frame. The difference is pipelining -- the load might be
done before the instruction executes.

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

I don't understand why 9 and 18 digits are special cases. A 32 bit number holds 4294967296
(9.4 digits) ; a 64 bit number holds 18446744073709551616 (19.1 digits). It appears that
IBM 'reserves' 2 bits out of 32 and 5 bits out of 64.


.

Relevant Pages

  • Re: Data type question
    ... Teresa Robinson wrote: ... > I've been reading about various data types on Oracle.com and in ... by comparing an ID field. ... > been reading shows it's not *too* much different in Oracle. ...
    (comp.databases.oracle.tools)
  • Data type question
    ... I've been reading about various data types on Oracle.com and in ... by comparing an ID field. ... been reading shows it's not *too* much different in Oracle. ... question is about the Varray: can I somehow change the size of it ...
    (comp.databases.oracle.tools)
  • Re: The quibble over nibbles (was Re: MVS Packed Decimal with no sign nibble?)
    ... Sounds like it is time for some "performance facts" from the (IBM) performance ... When selecting your data types, it is important to understand the performance ... | Performance considerations for comparing data types ): ... Perhaps it should reasonably> be deprecated *on IBM systems* because it requires the space for unsigned> data to allow for the presence of a sign contrary to its declaration, but> there is no particular reason to deprecate it on systems that do not share ...
    (comp.lang.cobol)
  • Re: This calculation is just wrong / computer cant count!
    ... question stands - how do I (or perhaps I should ask what data types should I use) to program this decimal mathematics? ... We do not understand the rationale behind your desire to compare the computer arithmetics to "real math" or decimal arithmetics. ... I then take the final result and format it myself to the number of decimal digits I need to present to the user. ...
    (microsoft.public.vc.mfc)
  • Re: Testing for numeric input
    ... The "3 digits to the right" is not reallly meaningful for floating point ... data types, and you don't mention negatives, so perhaps you could try ... Allen Browne - Microsoft MVP. ...
    (microsoft.public.access.formscoding)