[vox-tech] benchmarking (again)

[Micah J. Cowan]

On Fri, Feb 17, 2006 at 04:16:29PM -0500, Peter Jay Salzman wrote:
> On Fri 17 Feb 06, 12:00 PM, Mark K. Kim <lugod at cbreak.org> said:
> > On Fri, Feb 17, 2006 at 11:13:42AM -0500, Peter Jay Salzman wrote:
> > 
> > > And I've read that java allocates
> > > memory for all data items on the heap, which is never stored in L1 cache
> > > while for C and C++, temporary objects are often put into the L1 cache.
> > 
> > I think you mean CPU registers?  L1/L2/L3 caches are just buffers
> > between RAM and the CPU registers, and all data allocated in RAM, stack
> > or heap, go through L1 cache at some point.  Programming languages or
> > compilers have no direct memory allocation access of the caches.
>  
> I was under the impression that this is what computer scientists call
> "locality of data" -- if data is used once, it'll be used again soon.  The
> strategy that attempts to exploit locality of data is to hold recent data in
> L1 cache.
> 
> I read that in an article on Java World on optimizing Java programs.

Yes, but to my understanding, there is no direct software access to the
L1 or L2 (etc) caches: the CPU does all the decision making regarding
what gets into the cache, and there are no (to my knowledge)
instructions to give direction on this.

> > Anyway, wouldn't the details of data items getting allocated in the
> > heap/stack/register depend on the JVM and the JIT compiler?  Objects,
> > would have to be allocated in the heap, but simple data types like
> > "double" can certainly be temporarily allocated in a CPU register until
> > it's out of scope, no matter what the Java standard may say, if the JIT
> > compiler, for example, determines it can be done safely and can speed up
> > the execution.
> 
> I see what you mean.  Yeah, but the question still remains -- what's going
> on with the user time in java apps, and why does the program run faster in
> Java than C++?  Certainly C++ compilers know how to do all that stuff too.

The Cygwin argument somebody put forth seems like it might be an
explanation... I really don't want to comment too much until I actually
get to see what assembly code gets generated from a given C or C++
test...

-- 
Micah J. Cowan
micah at cowan.name