COBOL vs. C Performance
bwin...@delphi.com
Question #2 : What is it about Microfocus COBOL (or COBOL) that
that causes it to produce slower executable code?
Thanks
Harry Graham
:
: Question #2 : What is it about Microfocus COBOL (or COBOL) that
: that causes it to produce slower executable code?
In benchmarks done last year with MS C6.0 and Realia COBOL, COBOL was
faster at everything (it was expected to be slower) but prime number
calculations. You know how ofter we do that in business.
Even MF COBOL with the right compile directives can be as fast as C.
C used to be fast and small, now its slow and huge, what ever happened?
bwin...@delphi.com
RS/6000 AIX platform. We found that C was between 5 and 2000 times faster
for various operations (file io, calculations, branching, etc.).
Questions: 1. I realize that Microfocus clains to equivalent to C in
performance, and they have some tests to prove it. What can
I do to acheive the same performance with C (compiler
directives, etc)?
) that causes
it to produce slower executable code?
Bill Wingrove
Lawrence Free/ A.F. Software Services
: Recently, we did some benchmarking of Microfocus COBOL and the C compiler on a
A lot of this depends on the toolsets you are using. If you are using
pure C code for file I/O, C will generally be faster in sequential access,
may or may not be faster in random indexed access depending on algorithm.
In math, C can be faster.
If you are using a database for file I/O, on average I've seen COBOL 4 - 10
times faster.
C is generally harder to code a good business application than COBOL.
C has the potential of running faster than COBOL on large files if the coding
is exclusively C.
COBOL can be much faster to execute than C in the above if the file I/O is
not done exclusively in C.
What is best depends on what you want to do and how much work you are willing
to do.
Lawrence A. Free | Email: fr...@mcs.com
A.F.Software Services, Inc. | Your MS/DOS, UNIX
(708) 232-0790 | business software developer
Phil Paxton
>Question #2 : What is it about Microfocus COBOL (or COBOL) that
>that causes it to produce slower executable code?
Programmers would ask this back when I did mainframe work fulltime and it
was fairly easy to demonstrate why. (those compilers produced assembler
as output when desired and still produced listings)
Anyway, if you take an extremely short ( equivalent to "Hello, World!")
and told it to compile with assembler as output. If someone doesn't have
a good idea of what happens in the background of a compiler and what's
really involved, it can be quite staggering. A single WRITE statement can
generate a page or more of code whereas other "lower-level" languages much
fewer instructions.
I could be shot for making an overgeneralization, but most HLLs
(higher-level languages) have a bad ratio of source::code instructions.
Think about it this way: if a computer can increment a value by 1 as
desired by doing something like INC(R1), will the COBOL compiler be smart
enough to translate something like "ADD 1 TO X" to INC(R1) or will it use
a rather round-about method?
--
---------------------
"If a man appears out of step with those about him, then perhaps it is
because he marches to the beat of a different drummer." -Thoreau
---------------------
Charles Godwin
very interesting. COBOL compiles faster executes faster or no slower (that is C won none of
the tests) and of couse C cound not perform half of thr COBOL test suite. (display aritmatic,
inxed file access SORt etc.)
The test suite is available by request via email.
I work for Computer Associates CA-Realia group.
--
Charles Godwin
(613)761-1430 Work
(613)761-1422 Fax
Gordon Degrandis
>bwin...@delphi.com writes:
>>Question #2 : What is it about Microfocus COBOL (or COBOL) that
>>that causes it to produce slower executable code?
>Programmers would ask this back when I did mainframe work fulltime and it
>was fairly easy to demonstrate why. (those compilers produced assembler
>as output when desired and still produced listings)
>Anyway, if you take an extremely short ( equivalent to "Hello, World!")
>and told it to compile with assembler as output. If someone doesn't have
>a good idea of what happens in the background of a compiler and what's
>really involved, it can be quite staggering. A single WRITE statement can
>generate a page or more of code whereas other "lower-level" languages much
>fewer instructions.
>I could be shot for making an overgeneralization, but most HLLs
>(higher-level languages) have a bad ratio of source::code instructions.
>Think about it this way: if a computer can increment a value by 1 as
>desired by doing something like INC(R1), will the COBOL compiler be smart
>enough to translate something like "ADD 1 TO X" to INC(R1) or will it use
>a rather round-about method?
This seems to me to be completely compiler dependent. Most compilers on most
platforms have some kind of optimization so code is optimized for that
environment. If the compiler does not support a facility like this then you
should ask your supplier for one.
COBOL sometimes generates much more object code for the simple reason that it is
doing more for you with the same syntax. For example, when you write to a file
COBOL will check if the file is open, it will also make sure that the write
completed successfully! Languages like C and Assembler this is left up to the
developer to perform this task. So I my opinion comparisons should be made on
the TOTAL operation performed and not just one statement.
Thanks
Gord
------------------------------------------------------
Internet: Gordon.D...@ping.be
Compuserve: 100273,1562
Snappy quote for this week: Meskimen's Law:
There's never time to do it right, but there's always time to do it over.
Jim Ford
> : Recently, we did some benchmarking of Microfocus COBOL and the C compiler on a
> : RS/6000 AIX platform. We found that C was between 5 and 2000 times faster
> : for various operations (file io, calculations, branching, etc.).
> :
> : Questions: 1. I realize that Microfocus clains to equivalent to C in
> : performance, and they have some tests to prove it. What can
> : I do to acheive the same performance with C (compiler
> : directives, etc)?
> :
> : it to produce slower executable code?
> :
> : Thanks-
> : Bill Wingrove
>
Regarding file I/O speed, we've found that MF Cobol is *extremely*
slow if you code your SELECT statements (or allow them to default) to
ORGANIZATION IS LINE SEQUENTIAL. The other option, RECORD SEQUENTIAL,
does file I/O much faster. In addition, the extra time when using
RECORD SEQUENTIAL appears to be spent using the CPU, so a busy machine
may incur an even bigger performance hit. LINE SEQUENTIAL does make
the programmers responsible for coding their own line feed characters
(hex 0A) at the end of the record, if they are needed. BTW, we also
run MF COBOL on an RS/6000.