[
https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335044#comment-17335044
]
Benedict Elliott Smith commented on CASSANDRA-16360:
----------------------------------------------------
The hardware crc32c instruction does not require a lookup table, so a tight
loop measurement provides an unfair advantage to the other implementations that
(all) do. This is hard to avoid, without deliberately (and expensively)
thrashing the cache between every measurement, which would make your tests take
a lot longer. It may be that the lookup table will be in cache in some cases
anyway in real world usage, at least for several temporally proximal
invocations. Given how large CPU caches are it might even be so often. You
might be able to measure this with performance counters, but it would be very
hard, and certainly not worth it.
That said, you may well be benchmarking on a machine without crc32c hardware
support, anyway. Which would explain the very similar performance profile.
In essence, there's lies, damned lies, and benchmarks - unfortunately.
Either way, I don't think this is a decision worth agonising over. It's an easy
and clear win in JDK9+, and not that pressing otherwise.
> CRC32 is inefficient on x86
> ---------------------------
>
> Key: CASSANDRA-16360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16360
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
> Reporter: Avi Kivity
> Assignee: Alexey Zotov
> Priority: Normal
> Labels: protocolv6
> Fix For: 4.0.x
>
>
> The client/server protocol specifies CRC24 and CRC32 as the checksum
> algorithm (cql_protocol_V5_framing.asc). Those however are expensive to
> compute; this affects both the client and the server.
>
> A better checksum algorithm is CRC32C, which has hardware support on x86 (as
> well as other modern architectures).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
