On 5/02/2011 12:38 AM, Charles Mills wrote:
@Kirk: I looked at it. I played a little with the in-line TRT to replace an
strchr() or similar. I did not see any performance improvement and backed it
out. (Note *I did not see* a performance improvement; not "there was no ..."
It may have been below my threshold of measurement.)
Charles,
I've noticed quite surprising performance improvements using Metal/C. An
interesting optimziation
is the HGRP compiler option which tells the compiler to use 64-bit
instructions in 31-bit code. A
recent whitepaper I read states "it almost always produces faster code"
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101796
and profiling has proved that to be correct by about 2%. On new hardware
the compiler can use the PFD instruction to
pre-fetch data into a cache line, thus preventing cache misses. You
would have to be a very good assembler programmer
and have in-depth knowledge of the hardware to hand crank that kind of code.
With the explosion of open source code written in C Metal/C can be used
to compile C code into assembler that can be
then called from assembler routines. For example grab this code
http://adtinfo.org/index.html compile it with the Metal/C compiler and
you have a very good balanced binary tree library that can be called
from any language - assembler, COBOL, PL/1 etc.
You might just want to use the malloc()/calloc()/free() memory alloctor
from the Metal/C runtime in your assembler.
To make Metal/C more useful IBM need to provide header files with C
struct equivilents of SYS1.MACLIB/MODGEN.
@Rob: It's not an in-house program, but the CPU time measure is a "hidden"
development-only feature. I'm not using any zIIPs or zAAPs and I am just
interested in some general guidance: "is CPU time for this version in line
with CPU time for the last version when the so-and-so feature is turned on?"
My granularity is CPU time used over hours spent 99% in a wait state.
Nothing I am hearing persuades me that TCBTTIME is inappropriate. (I'm not
avoiding an assembler call to save CPU overhead; I'm avoiding an assembler
call to avoid unnecessary complexity. You could argue the point, but I think
the code I quoted is more obvious and more maintainable than an external
call, especially since I am in a situation where there is more C talent than
assembler talent.)
@Chris: Interesting. Do you suppose the technique you describe is "cheaper"
than TIMEUSED with ECT?
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Kirk Wolf
Sent: Friday, February 04, 2011 8:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TIMEUSED versus TCBTTIME
Charles,
Related to your comment: have you looked at the new assembler gcc-style
inlining in xlc on z/OS?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
