[
https://issues.apache.org/jira/browse/CASSANDRA-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-8614:
--------------------------------------
Attachment: 8614.patch
New patch addressing a few things.
I had to put in a fake Checksum class to compile against with the JDK 8 methods
for byte buffers. javac is surprisingly OK with just pointing at a source file.
Fixed formatting and added a test to make sure JDK detection is actually
detecting and giving up the goodness.
I think this should go in so we at least get it for the commit log. It looks
like Adler is not fast in JDK 8 on Linux. It is inexplicably fast on OS X. The
same speed as CRC32.
I don't have an explanation for the funky performance numbers on OS X. On Linux
I get the expected behavior where disabling the intrinsic is slow and switching
to JDK 7 is slow.
I will create a separate ticket for discussion of the right way to replace
Adler32 with CRC32 in SSTables.
> Select optimal CRC32 implementation at runtime
> ----------------------------------------------
>
> Key: CASSANDRA-8614
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8614
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Labels: performance
> Attachments: 8614.patch, Sample.java
>
>
> JDK 8 has support for an intrinsic for CRC32 that runs at 12-13 gigabytes/sec
> per core in my quick and dirty test. PureJavaCRC32 is < 800 megabytes/sec if
> I recall and it has a lookup table that evicts random cache lines every time
> it runs.
> In order to capture the benefit of that when it is available we can select a
> CRC32 implementation at startup in a static block.
> If JDK 8 is not what is running we can fall back to the existing
> PureJavaCRC32 implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
