On 1/04/2016 8:13 AM, Andrew Rowley wrote:
I do know that the effects of allocation patterns are very different
for GC languages and languages like C/C++. In C++ allocating and
freeing short lived objects is expensive because the memory needs to
be tracked. In GC languages short lived objects are cheap, it is
objects that survive to GC that are expensive. This can make it a bit
difficult to directly compare performance because there might be
different design decisions.
In C++ small object allocation can be done with pool allocators
http://www.boost.org/doc/libs/1_60_0/libs/pool/doc/html/index.html.
Most of my CPU time seems to be I/O related (processing SMF data).
Even removing all the reporting seems to make very little difference
to the CPU consumed. I'm trying to work out if I can reduce the I/O
overhead.
I guess you're using JZOS RecordReader? From what I know of the
implementation it's micro-optimized and it's as good as it gets for Java.
I don't know about JIT overhead - I think it is probably insignificant
because it should only compile the methods you actually invoke.
The FTS1 CPU is running CICS, IMS and that one Java batch job spikes
past it.
Without other work for competition anything CPU bound will max out the
CPU, so that's not necessarily a negative - it just means that it
isn't waiting for other things. E.g. at one site the DBAs greatly
increased Adabas buffer space. CPU contention increased massively as
virtually nothing was waiting for I/O anymore. Caused a few problems,
but it's a good problem to have. It just means that if it can only get
5% CPU instead of 50% it will run ~10 times as long. Total CPU time is
a better measure than CPU%.
Agreed. I probably didn't articulate my point very well. You can't
compare a COBOL batch job to a Java batch job. The COBOL program will
use 200K of memory and use very little CPU where the Java program will
be a multi-threaded monster and gobble up as much memory as it can
devour. That's the nature of the beast. It probably means the density of
Java workloads that can run on a zIIP is far less than conventional
programs on CPs.
My Java program creates Redis pipeline buffers so uses quite a bit of
memory. When I profile the program in APA I see the following.
Name Description Percent of CPU Time * 10.00% +3.9%
*....1....2....3....4....5....6....7....8....9....*
APPLCN Application Code 96.35
************************************************
*PATHNAM Application Program 96.35
************************************************
> Parallel CSECT in *PATHNAM 34.86 *****************
> MarkingS CSECT in *PATHNAM 27.41 **************
> CompactS CSECT in *PATHNAM 17.11 *********
> ObjectHe CSECT in *PATHNAM 6.49 ***
> Concurre CSECT in *PATHNAM 3.80 **
> HeapMapI CSECT in *PATHNAM 1.90 *
> J9ZERZ10 CSECT in *PATHNAM 1.26 *
> Scavenge CSECT in *PATHNAM 0.95
> CardTabl CSECT in *PATHNAM 0.63
Half of the CPU time is spent in GC. Ironically most of this program is
spent running C++ GC code in the VM! ParallelScavenger,
ConcurrentScavenger and MarkingScheme which I assume is part of the
mark-and-sweep GC engine.
What I really want for Christmas is to run C++ programs on a zIIP. But
IBM won't let me :)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
