Right, but what's this "jaba7"? Some inside Star Wars joke :)
On Mon, Apr 7, 2014 at 1:49 PM, Uwe Schindler <[email protected]> wrote: > Hi Mike, > > hehe, as expected. I think, we need to look at stuff like off-heap filters: > https://issues.apache.org/jira/browse/LUCENE-5052 > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > >> -----Original Message----- >> From: Michael McCandless [mailto:[email protected]] >> Sent: Monday, April 07, 2014 10:19 PM >> To: Lucene/Solr dev >> Subject: Re: JDK 8 great performance increase on ByteBuffer read >> performance!? >> >> Here are the results: https://paste.apache.org/cKRW >> >> Baseline is 1.7 u60 ea, comparison is 1.8.0, index is full 33.3 "Wiki medium" >> (English) docs. >> >> Net/net Java 8 seems to love fuzziness :) >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> >> On Mon, Apr 7, 2014 at 1:01 PM, Uwe Schindler <[email protected]> wrote: >> > Thanks Mike. >> > >> > In fact this improvement would help stuff like Yonik's Off-Heap Filters and >> Bitsets, because that code is using Unsafe directly to work around >> ByteBuffers overhead. If those getByte()/getLong() calls are really faster, >> we >> can think about providing those off-heap data structures based on >> DirectByteBuffer in the future. I am thinking about CachedFilter, if we have >> a >> FixedOffHeapBitSet, or using DirectBuffers for FieldCache or DocValues. The >> new FieldCache interface based on DocValues without direct array acess >> makes this easy possible. >> > >> > Uwe >> > >> > ----- >> > Uwe Schindler >> > H.-H.-Meier-Allee 63, D-28213 Bremen >> > http://www.thetaphi.de >> > eMail: [email protected] >> > >> > >> >> -----Original Message----- >> >> From: Michael McCandless [mailto:[email protected]] >> >> Sent: Monday, April 07, 2014 6:55 PM >> >> To: Lucene/Solr dev >> >> Subject: Re: JDK 8 great performance increase on ByteBuffer read >> >> performance!? >> >> >> >> In fact I just recently tested Java 8 GA vs Java 7 (I think 1.7 u25) >> >> and I think there were small improvements, curiously especially to >> >> span and sloppy phrase queries. >> >> >> >> Since we mostly read big byte[] blocks I think gains to >> >> ByteBuffer.getXXX won't help us that much. But I'll retest, with 1.7 >> >> u60 and report back. >> >> >> >> Mike McCandless >> >> >> >> http://blog.mikemccandless.com >> >> >> >> >> >> On Mon, Apr 7, 2014 at 11:59 AM, Uwe Schindler <[email protected]> >> wrote: >> >> > Hi, >> >> > >> >> > On the Hotspot mailing list was the following post by Cleber >> >> > Muramoto. It >> >> might be interesting to check MMapDirectory in Java 8! >> >> > Mike, do you maybe setup another luceneutil test on Lucene on >> >> > Beast >> >> with JDK 8 GA? Can we do a comparison between JDK 7u60 and JDK 8 GA? >> >> It would be very interesting, because one reason some people want to >> >> have the native mmap variants because of the additional slowdown >> >> caused by the ByteBuffer wrapping. >> >> > >> >> > Uwe >> >> > >> >> > === snip === >> >> > Hello, I'm curious to know if there has been any low-level >> >> > optmizations >> >> regarding direct buffers getXXX methods on JDK8 and, if they're >> >> planned to be integrated in JDK7, if applicable. I googled and took a >> >> look at the bug database but I couldn't find anything related. >> >> > >> >> > I have a microbenchmark that does millions of iterations >> >> > serializing and >> >> deserializing objects to/from ByteBuffers and I noticed that read >> >> performance on JDK 8 has increased by almost 45% in comparison to >> >> earliear JDK 7 releases in the serial case and more than 200% on the >> concurrent case! >> >> I think that the concurrent test is perhaps benefiniting from newer >> >> ForkJoinPool/concurrency code, but the difference in the serial case >> >> is still very large! >> >> > >> >> > Bellow are the VM arguments that I'm using for the test: >> >> > >> >> > $JAVA -server -XX:+UseParallelGC \ >> >> > -XX:+UseLargePages -XX:MaxDirectMemorySize=10G -Xmx1g >> >> > -XX:MaxInlineSize=256 \ -XX:+UnlockDiagnosticVMOptions >> >> > -XX:+PrintInlining -XX:+LogCompilation >> >> > >> >> > JDK8 seems to generate much more compiling information than the >> >> previous versions, but I wasn't able to find any indicators for such >> >> huge performance difference. >> >> > >> >> > Here are the test results (collected with the diagnostic flags off, >> >> > on a HP >> >> > G7 48 CPU box). >> >> > >> >> > Concurrent Reads: >> >> > >> >> > 503K Reads/s|Writes/s 161K (jdk7U10) >> >> > 940K Reads/s|Writes/s 165K (jdk7U40) >> >> > 956K Reads/s|Writes/s 159K (jdk7U60 EA) >> >> > 1644K Reads/s|Writes/s 172K (jdk8-more than 3x faster than U10!) >> >> > >> >> > Serial Reads: >> >> > >> >> > 137K Reads/s|Writes/s 146K >> >> > 145K Reads/s|Writes/s 145K >> >> > 143K Reads/s|Writes/s 155K >> >> > 198K Reads/s|Writes/s 172K >> >> > >> >> > Upon deserialization the test does a lot of short-lived >> >> > allocations, but GC >> >> reports show very similar results for every JDK versions used in the >> >> test (about ~500 Young Gen Collections and ~1800ms spent by PS >> Scavenge). >> >> > >> >> > Anyway, great work!!! I hope I can migrate to JDK8 as soon as possible. >> >> > >> >> > Regards >> >> > >> >> > Cleber >> >> > >> >> > ----- >> >> > Uwe Schindler >> >> > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de >> >> > eMail: [email protected] >> >> > >> >> > >> >> > >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] For >> >> > additional commands, e-mail: [email protected] >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] For >> additional >> >> commands, e-mail: [email protected] >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
