Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8316

Re: Bulk Array Element Allocation, is it faster?

Show all headers | View raw

On Sunday, September 25, 2011 12:25:18 PM UTC-7, Jan Burse wrote:
> Lew schrieb:
> > How would you imagine the JIT would optimize this
>  > without taking semantics into account?  Each 'Bla'
>  > is required to be independently GC-able, you know.
> 
> In my posts I mentioned two possible optimizations.
> Optimization 1: Moveing the locking outside of the
> loop, Optimization 2: Allocating at once n*X where

That's not an optimization because things might need to happen in between loop cycles, so you can't "lock the heap" that long and call it an "optimization".

Semantically an array of n references is an array of n separate references.  You can't count on the memory allocations to be contiguous, shouldn't have to count on that, and you certainly can't count on each reference becoming eligible for GC at the same time.  GC in turn moves things around anyway, so any "benefit" of contiguous allocation will be gone quite quickly, if it ever existed in the first place.

And the point you ignore is that the "benefit" of contiguous allocation is questionable, let alone of your rather bizarre suggestion to move the "locking of the heap" outside the loop.  Each 'new' just bumps up the heap pointer, so it's not much faster to bump it once than n times, in the grand scheme of things.  Not when your tiny advantage is quickly eaten up by circumstances immediately afterward anyway.


> X is the space for the Bla record, not the space
> for the Bla point.
> 

But that's the thing that's semantically different!

You can't "optimize" allocation of n references to also create a block of n instances.  The optimizer cannot know that that is the intended use of the array.  You can't "optimize" the allocation of n instances consecutively either, because you have to know a whole lot about what those n constructors will try to do, including possibly allocate heap themselves or except out prematurely.  For the few cases where block allocation *might* provide negligible speedup, it's not worth the analysis effort to determine that this one time is one of those rare exceptions when allocation might be sped up enough for anyone to notice.

As people keep pointing out in this conversation.

> Since after allocation, we have the assignment
> bla[i] = new Bla(), the object cannot escape as
> long as bla does not escape, so there should be
> not much problem with GC, but I am not 100% sure
> what the problems with GC should be.

What do you even mean by this?  What do you mean by the object "escaping"?

I don't know about "problems" with GC, but you cannot be sure that the individual instances pointed to by the 'bla[i]' pointers will be descoped at the same time.  Ergo you cannot know ahead of time when they will be eligible for GC.  Instances that survive GC will be moved to contiguous memory blocks, but not their original ones.  Whatever negligible benefit you might have gotten, but more likely did not, from contiguous allocation of the 'Bla' instances will be wiped out.

> But anyway, let speak the figures, and lets stop
> musing too much. I did some testing and it shows
> that the 64bit can do the "speed up" whereby the
> 32bit cannot do it:
> 
> OS	JDK	Arch	Bulk	Lazy	Delta %
> Win 	1.6 	64bit	8'771	9'805	11.8%
> Win 	1.6 	32bit	14'587	14'744	1.1%
> Win	1.5 	32bit	17'139	17'405	1.6%
> Mac	1.6	64bit	11'003	12'363	12.4%
> Unix	1.6	32bit	26'517	26'858	1.3%
> 
> Still this leaves open the question whether the
> 64-bit JIT is clever or the 64-bit JVM is clever
> or the 64-bit CPU is clever.
> 
> Definitely it seems that the 32-bit is not clever,
> there we all see a small overhead for the lazy,
> which I interpret as the additional checks, eventually
> done repeatedly, for the lazy.
> 
>> The answer is "nothing", because the semantics
>> of the operation are such that the current
>> mechanism is already quite close to optimal.
>> This is what people have been explaining to you,
>> that you dismissed as irrelevant.
> 
> Where do you see "nothing" in the above figures?

Everywhere.  You have some questionable method of timing something that you do not describe, let alone with any precision, using doubtful methodology and suspect reasoning without reference to experimental error or confidence analysis.  Your numbers literally tell me nothing.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 03:17 +0200
  Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-24 21:37 -0400
    Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 10:39 +0200
  Re: Bulk Array Element Allocation, is it faster? Patricia Shanahan <pats@acm.org> - 2011-09-24 18:41 -0700
    Re: Bulk Array Element Allocation, is it faster? Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 12:57 +0200
      Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 13:38 +0200
        Re: Bulk Array Element Allocation, is it faster? Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 14:16 +0200
          Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 16:04 +0200
            Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 16:11 +0200
              Re: Bulk Array Element Allocation, is it faster? Patricia Shanahan <pats@acm.org> - 2011-09-25 09:30 -0700
            Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 10:59 -0400
              Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 17:14 +0200
                Re: Bulk Array Element Allocation, is it faster? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-25 15:26 +0000
                Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:02 -0700
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 20:19 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 20:21 +0200
                Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 17:48 -0400
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 00:10 +0200
  Re: Bulk Array Element Allocation, is it faster? Roedy Green <see_website@mindprod.com.invalid> - 2011-09-24 19:05 -0700
    Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-24 23:22 -0700
      Re: Bulk Array Element Allocation, is it faster? Roedy Green <see_website@mindprod.com.invalid> - 2011-09-25 00:23 -0700
        Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:17 -0700
        Re: Bulk Array Element Allocation, is it faster? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-25 14:00 -0500
    Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 10:47 +0200
      Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 08:07 -0400
        Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 19:21 +0200
          Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 19:41 +0200
          Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:28 -0700
            Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 21:25 +0200
              Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 23:50 +0200
              Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 15:43 -0700
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 01:06 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 01:21 +0200
                Re: Bulk Array Element Allocation, is it faster? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-26 06:00 +0000
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 14:52 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 15:02 +0200

csiph-web