[
https://issues.apache.org/jira/browse/HADOOP-11466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14279169#comment-14279169
]
Colin Patrick McCabe commented on HADOOP-11466:
-----------------------------------------------
I thought about this some more, and I think instead of "whitelisting" the
architectures that should use UNSAFE_COMPARER_NAME, we should "blacklist" the
architectures that should not use it. This seems more robust since
architectures like ARM now support unaligned access (in their later revisions).
Also, x86 has gone by many names over its lifetime, and I'm a little nervous
that we might not have caught all of them. Yeah, there's i386, x86, and
x86_64, but is anyone returning x686, i386, etc. any more? I think let's
special-case SPARC, not x86.
Thanks, Suman.
> Newer Fast byte comparison is slower in SUN SPARC machines
> ----------------------------------------------------------
>
> Key: HADOOP-11466
> URL: https://issues.apache.org/jira/browse/HADOOP-11466
> Project: Hadoop Common
> Issue Type: Improvement
> Components: io, performance, util
> Environment: Linux X86 and Solaris SPARC
> Reporter: Suman Somasundar
> Assignee: Suman Somasundar
> Priority: Minor
> Labels: patch
> Attachments: HADOOP-11466.001.patch
>
>
> One difference between Hadoop 2.x and Hadoop 1.x is a utility to compare two
> byte arrays at coarser 8-byte granularity instead of at the byte-level. The
> discussion at HADOOP-7761 says this fast byte comparison is somewhat faster
> for longer arrays and somewhat slower for smaller arrays ( AVRO-939). In
> order to do 8-byte reads on addresses not aligned to 8-byte boundaries, the
> patch uses Unsafe.getLong. The problem is that this call is incredibly
> expensive on SPARC. The reason is that the Studio compiler detects an
> unaligned pointer read and handles this read in software. x86 supports
> unaligned reads, so there is no penalty for this call on x86.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
