hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Carey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-297) Implement a pure Java CRC32 calculator
Date Wed, 08 Jul 2009 19:07:14 GMT

    [ https://issues.apache.org/jira/browse/HDFS-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728852#action_12728852

Scott Carey commented on HDFS-297:

{quote}I think we now have the fastest crc32 in the west{quote}

There are two ways to still go faster:

1. an 8-byte at a time approach based off the Intel paper.
2. Being able to read 4 consecutive bytes from a byte array without shifting each separately.
 Sort of like ByteBuffer.getInt().  However, I tried ByteBuffers and they were substantially
slower if allocated via ByteBuffer.wrap() in the API here.  An API change with a preallocated
one might work though.   

Honestly, I just wish the JVM had a cleaner way to pull out Integers/Longs from byte arrays
that it could optimize to be like casting a pointer in C and the JVM could optimize if the
load was aligned.  It would make a lot of low level byte-wise algorithms in Java just as fast
as C.

> Implement a pure Java CRC32 calculator
> --------------------------------------
>                 Key: HDFS-297
>                 URL: https://issues.apache.org/jira/browse/HDFS-297
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>            Reporter: Owen O'Malley
>            Assignee: Todd Lipcon
>         Attachments: crc32-results.txt, hadoop-5598-evil.txt, hadoop-5598-hybrid.txt,
hadoop-5598.txt, hadoop-5598.txt, hdfs-297.txt, PureJavaCrc32.java, PureJavaCrc32.java, PureJavaCrc32.java,
TestCrc32Performance.java, TestCrc32Performance.java, TestCrc32Performance.java, TestPureJavaCrc32.java
> We've seen a reducer writing 200MB to HDFS with replication = 1 spending a long time
in crc calculation. In particular, it was spending 5 seconds in crc calculation out of a total
of 6 for the write. I suspect that it is the java-jni border that is causing us grief.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message