Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!post02.iad!not-for-mail
From: lbrt chx _ gemale kom
Newsgroups: comp.lang.java.programmer
Subject: baseline performance test using java ...
In-Reply-To: <1309646728.550644@nntp.aceinnovative.com>
X-Newsreader: NetComponents
Organization: Acecape, Inc.
Organization: Newshosting.com - Highest quality at a great price! www.newshosting.com
X-Complaints-To: abuse(at)newshosting.com
Message-ID: <1309715588.716395@nntp.aceinnovative.com>
Cache-Post-Path: nntp.aceinnovative.com!unknown@p70-44.acedsl.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
Date: 03 Jul 2011 17:53:08 GMT
Lines: 56
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5832

>> ~ I have searched to no avail for some kind of hardware baseline
>> performance test for a piece of code. ~ Notice that I don't mean to
>> "profile" code, with "baseline" I mean that the actual performance of
>> an algorithm should me gauged against its  underlying hardware and
>> OS, like its I/O subsystem (RAM (types, speed, amount), file access,
>> ...)
~ 
> As far as I know, performance should be measured relatively ...
> It's relative speed increase that matters.  Speed on your system doesn't mean much to me.
~ 
 Exactly the point I am trying to make, that is why I was taking about profiling first -your particular applications- for the types of system calls it does, right below your logical stack
~ 
>> ~ We have all learned we should avoid String(s) and use
>> StringBuffer(s) or better yet StringBuilder(s) but there is
~ 
> Er, no.  Strings are great ...
~ 
 I (obviously) meant to say String(s) if you need to build them and StringBuilder(s) if you are working (most of us by now) on some multiprocessing core
~ 
>> java -version>>  version.txt java -verbose:class
>> -XX:+PrintGCTimeStamps -XX:+PrintGCDetails code class.txt 2>&1
~ 
> No sure I follow the GC related stuffs.  Is garbage collection somehow related to running speed?
~ 
 Indirectly so, checking the (code) points where GC sets in you will have a better idea of where your code is getting demanding
~ 
> As for the rest of it, I'm not really convinced a general methodology or
> set of parameters could be produced.  Too many variables.  The devil in
> the details, and since code is little else but details, by substitution
> we can establish that in fact Satan is loose in your system.
~ 
 Ach, no! I know "where you re coming from", but I think you are taking these truths to extremes. I do believe profiling, as well sample- and stress testing your code, etc does point out quite a bit about how much of your mind "Satan" has sucked (including using those illusions you mentioned ;-))
~ 
> In general, benchmarking, like any experiment, only makes sense if you
> have some questions you want answered, and the measurements will answer
> those questions. I'm not at all clear what your questions are.
~ 
 The q is then. How much more (as a relative measure/percentage) does my logical stack taxes the underlying (hw + sw) baseline?
~ 
> "Performance of an algorithm" is a non-trivial concept ... matter of analysis, not measurement.
~ 
 I am not sure if I got that one, but if we are talking here about the implementation of an algo then surely can we for instance check how much memory and time needs to run
~ 
> Of course, one often needs to know how fast an algorithm will run for a
> specific problem size on a specific system. In that case, measurement is
> definitely the way to go.
~ 
 Well, yes. Now we are on the same page
~ 
> With modern computers, any sort of isolated measurement can be
> misleading. There is so much caching and prediction that code can behave
> very differently in different contexts.
~ 
 Yes, Patricia. But give a little thinking to the type of measurement I am talking about. Right on top of all system calls and under your logical stack. There can and should be utilities to automate this
~ 
 lbrtchx