Scott,
I completely agree with your comments on zAAP economics.... the zAAP engine
is actually *the* reason that we wrote JZOS.
If you are going to do a synthetic benchmark of record I/O in JZOS, I
suggest that you look at the new RecordReader and RecordWriter classes that
are in the latest alphaWorks build. These uses *significantly* less CPU
(some customers have reported as much as 7X) and on is par with COBOL
record I/O performance.
So, for the synthetic test that you chose, you might try something like:
public class RecordFieldAverage {
private long nRecs = 0;
private long total = 0;
private long min = 0;
private long max = 0;
public static void main(String[] args) throws Exception {
String ddname = "INPUT"; // default
if (args.length > 0) {
ddname = args[0];
}
RecordFieldAverage instance = new RecordFieldAverage();
instance.processFile(ddname);
instance.printTotals();
}
private void processFile(String ddname) throws Exception {
String encoding = ZUtil.getCodePageCurrentLocale();
RecordReader reader = RecordReader.newReaderForDD(ddname);
byte buf[] = new byte[reader.getLrecl()];
int rlen;
try {
while ((rlen = reader.read(buf)) >= 0) {
String line = new String(buf, 0, rlen, encoding);
processLine(line);
}
} finally {
reader.close();
}
}
private void processLine(String line) {
StringTokenizer toker = new StringTokenizer(line);
toker.nextToken();
toker.nextToken();
String third = toker.nextToken();
long value = Long.parseLong(third);
nRecs++;
min = Math.min(min, value);
max = Math.max(max,value);
total += value;
}
private void printTotals() {
System.out.println(
"recs="+nRecs
+" min="+min
+" max="+max
+" total="+total
+" average="+(total/nRecs));
}
}
On Tue, Mar 8, 2011 at 8:52 AM, Scott Chapman <sachap...@aep.com> wrote:
> Kirk:
>
> I agree completely:
>
> This wasn't intended to be a benchmark, but rather a general indication
> that Java performance isn't necessarily completely outside the ballpark
> (not even in the same county) any more. I think there's a general
> perception that Java is a horribly bloated mess that should be avoided
> whenever possible. That was at least partly true 10 years ago, maybe
> less. But it's a lot better today. I can use JZOS (thanks!) to start the
> JVM and run a trivial JS script in less than a second today. I remember
> when standing up a JVM took minutes!
>
> And I definitely agree that the code in question, regardless of the
> language, is likely the most important factor in the performance of any
> solution to a particular problem. Well mostly--I can probably come up
> with a scenario where bad Java code on a zAAP is better overall than good
> (pick your language code) on the GCP. At least when the zAAPs run faster
> than the GCPs. And then there's the capacity/cost implications of running
> code on the zAAP vs. the GCP.
>
> The funny thing is I personally really don't like Java as a language,
> regardless of performance. But I have excess zAAP capacity at the moment,
> so I'm looking at what it might be useful for.
>
> Scott Chapman
>
>
>
> ----------------------------------------------------------------------
> 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
