[
https://issues.apache.org/jira/browse/MAPREDUCE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated MAPREDUCE-2841:
-----------------------------------
Attachment: micro-benchmark.txt
Attaching some micro-benchmark results that compare FB's collector
(BlockMapOutputBuffer), the current MR2 collector (MapTask$MapOutputBuffer),
and the new native collector from this JIRA.
The test here is running 30 map tasks within a single JVM, which gives the JIT
a lot of time to warm up. Even the native collector benefits from some warmup
(first run takes 1600ms CPU whereas later runs take 1000ms CPU time). In the
table below, I'll express "Post-JIT" as the fastest runtime of all of the runs.
To summarize results:
*Current collector:*
First task: 7020ms CPU
Post-JIT: 5730ms CPU
*FB collector:*
First task: 4100ms CPU
Post-JIT: 2010ms CPU
*Native collector:*
First task: 1620ms CPU
Post-JIT: 970ms CPU
If you assume that people generally don't use JVM reuse, then the "first task"
runtimes are most interesting. In that case, the native collector is winning by
>4x vs status quo, and still >2x vs the best known Java collector.
Additionally, the FB collector _only_ supports BytesWritable as far as I know,
whereas the native one supports many common writable types and is also user-
(or framework-) extensible.
If you consider the post-JIT results, the difference isn't quite as striking,
but still pretty significant.
> Task level native optimization
> ------------------------------
>
> Key: MAPREDUCE-2841
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2841
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: task
> Environment: x86-64 Linux/Unix
> Reporter: Binglin Chang
> Assignee: Sean Zhong
> Attachments: DESIGN.html, MAPREDUCE-2841.v1.patch,
> MAPREDUCE-2841.v2.patch, dualpivot-0.patch, dualpivotv20-0.patch,
> fb-shuffle.patch, hadoop-3.0-mapreduce-2841-2014-7-17.patch,
> micro-benchmark.txt
>
>
> I'm recently working on native optimization for MapTask based on JNI.
> The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs
> emitted by mapper, therefore sort, spill, IFile serialization can all be done
> in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising
> results:
> 1. Sort is about 3x-10x as fast as java(only binary string compare is
> supported)
> 2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware
> CRC32C is used, things can get much faster(1G/
> 3. Merge code is not completed yet, so the test use enough io.sort.mb to
> prevent mid-spill
> This leads to a total speed up of 2x~3x for the whole MapTask, if
> IdentityMapper(mapper does nothing) is used
> There are limitations of course, currently only Text and BytesWritable is
> supported, and I have not think through many things right now, such as how to
> support map side combine. I had some discussion with somebody familiar with
> hive, it seems that these limitations won't be much problem for Hive to
> benefit from those optimizations, at least. Advices or discussions about
> improving compatibility are most welcome:)
> Currently NativeMapOutputCollector has a static method called canEnable(),
> which checks if key/value type, comparator type, combiner are all compatible,
> then MapTask can choose to enable NativeMapOutputCollector.
> This is only a preliminary test, more work need to be done. I expect better
> final results, and I believe similar optimization can be adopt to reduce task
> and shuffle too.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
