[llvm-dev] Improve the performance of JamCRC
Scott Smith via llvm-dev
llvm-dev at lists.llvm.org
Thu Apr 13 03:03:27 PDT 2017
Ooops, I have no idea how I read that (and the preceding section) and
determined I should send it to the *-dev list instead. Sorry!
On Thu, Apr 13, 2017 at 1:00 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> Hi Scott,
> Usually patches are sent to llvm-commits (unless I missed a specific
> reason to send this patch to llvm-dev instead), see: http://llvm.org/docs/
> (we also have a phabricator instance: http://llvm.org/
> On Apr 12, 2017, at 6:52 PM, Scott Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> Sorry, that last patch didn't handle endianness very well. Here's an
> updated patch that uses llvm::support::endian. I assume unaligned input,
> which is safer. I have no idea whether one can expect aligned input to
> this function. It also wouldn't take much to process the first <=3 bytes
> one at a time, then blast through assuming aligned reads, and then finish
> up with another <=3 bytes. Let me know if you prefer that.
> On Wed, Apr 12, 2017 at 8:49 PM, Scott Smith <scott.smith at purestorage.com>
>> Lldb relies heavily on crc when loading shared libraries. The existing
>> implementation is quite slow as it computes a byte at a time, creating a
>> long dependency chain.
>> Unfortunately the polynomial is not the same as the one implemented by
>> x86 processors in SSE 4.2, but there's another way to make it faster by
>> using more lookup tables.
>> Zlib implements this, but rather than require zlib, I instead added the
>> relevant code to compute four bytes at a time in parallel.
>> A separate patch changes lldb to rely on JamCRC instead of its own
>> implementation. This patch improves the performance, which brings my test
>> (starting lldb, breaking at main) from 47 seconds down to 36 seconds.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev