Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Jan Burse Newsgroups: comp.lang.java.programmer Subject: Re: Bulk Array Element Allocation, is it faster? Date: Sun, 25 Sep 2011 21:25:18 +0200 Organization: albasani.net Lines: 47 Message-ID: References: <31815149.2253.1316975280430.JavaMail.geo-discussion-forums@prfp13> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 9OXs3TNzQAdLSnLgoNs+HA8Z5XEsz8IWr2uHpGH4v8c9t8aF4lDWpHyhG5Ssb/JT94vF8bHFCIS7O1BL0isjeixXoaBSwmiqRd4widJRQ8hqNY3wo3YSz6L3KkOro00r NNTP-Posting-Date: Sun, 25 Sep 2011 19:25:19 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="2vo0L7e/p3oOiiXfQyobC4XJ02VeqVJqwJ0v6rqnyM7XUnOeDfEPNg960rBAPsI0oDGtGQLomdEIlDS2+N6AE8o6/4LwtsD3IJT4saZpJCnAv7Tpb6Vjemkavwlmxzlw"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3 In-Reply-To: <31815149.2253.1316975280430.JavaMail.geo-discussion-forums@prfp13> Cancel-Lock: sha1:V61R7Dga0jNkemePEVuHihmJZKk= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8311 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 X is the space for the Bla record, not the space for the Bla point. 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. 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? Bye