Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: Bulk Array Element Allocation, is it faster?
Date: Sun, 25 Sep 2011 16:04:07 +0200
Organization: albasani.net
Lines: 70
Message-ID: <j5ncco$hl$1@news.albasani.net>
References: <j5lvf0$bhl$1@news.albasani.net> <Ypydnd8C3rt7G-PTnZ2dnUVZ_iydnZ2d@earthlink.com> <9e8fplF19bU1@mid.individual.net> <j5n3qv$dbo$1@news.albasani.net> <9e8kdhF6lmU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net eoUJd8uk9OaAV74QN6FZxIjK6IkaIWrqccQSXnoWz+6MfTPRQ1qFJ0w6wtTfycuhBM9o+5ixCkXccYt/VLn//A==
NNTP-Posting-Date: Sun, 25 Sep 2011 14:04:08 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="YETDUP1kTmHggCgd/0FbMJWL4QuNRLGNSBhLRoGb7MXxPefnU2JLYkl+dNTZKCVxpU8nJZiTWcRUmHDLDlWFHu5DMz4vsUoWnFIzHhLlk+1+OwAV67x/20oDcb4h044V"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3
In-Reply-To: <9e8kdhF6lmU1@mid.individual.net>
Cancel-Lock: sha1:KdPbZ8MMMwwB+qezvbXyRS1Fp0w=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8293

Robert Klemme schrieb:
> Yes, but the cost is not in the check but in the branching on processor
> level (see what Patricia wrote).

Depends on the processor and on the branch. If
new is just heap -= size, what some papers suggest,
then it might not be important.

But if new is much more, then sure the branch
interrupts the normal code flow so much that
instruction piplining gets out of sync. And
the speed gain by instruction overlapping
is lost.

But my hypothesis is more that something
algorithmically on a higher level happens than
something on the lower hardware level.

So I also found something about "Lock
coarsening"(*), so if the new needs some lock
this lock could be aquired before the initialization
loop and released after the initialization
loop. So that:

     Bla[] bla = new Bla[n];
     for (int i=0; i<n; i++) {
         bla[i] = new Bla();
     }

Would only need 1 locking instruction pair,
where as:

     Bla[] bla = new Bla[n];

     ...

     if (bla[i]==null)
        bla[i] = new Bla();

     ..

Would need n locking instruction pairs. But I
would still need some confirmation that JITs
are able to do such an optimization on a higher
level in the present case.

I am also not sure whether the bounded for
counts as a looping control flow, so that "Lock
coarsening" would not be applicable. But
I guess it can be deemed non looping, so that
the technique would be applicable.

Currently I am planning to change the loop
to something like that:

     Bla[] bla = new Bla[n];
     for (int i=0; i<n; i++) {
         bla[i] = createBla();
     }

So that the JIT has less information on what
the loop is about, and to do some new
measurements. To be fair I would also use
createBla() in the lazy scenario. Lets see
what happens.

Best Regards

(*)
http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.2