l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2006 Feb 17 14:03

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] benchmarking (again)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] benchmarking (again)

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@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++

Micah J. Cowan
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!