Skip to content
Snippets Groups Projects
  1. Nov 06, 2013
  2. Nov 05, 2013
  3. Nov 04, 2013
    • Reynold Xin's avatar
      Merge branch 'master' of github.com:apache/incubator-spark into mergemerge · 551a43fd
      Reynold Xin authored
      Conflicts:
      	README.md
      	core/src/main/scala/org/apache/spark/util/collection/OpenHashMap.scala
      	core/src/main/scala/org/apache/spark/util/collection/OpenHashSet.scala
      	core/src/main/scala/org/apache/spark/util/collection/PrimitiveKeyOpenHashMap.scala
      551a43fd
    • Reynold Xin's avatar
      Merge pull request #130 from aarondav/shuffle · 7a26104a
      Reynold Xin authored
      Memory-optimized shuffle file consolidation
      
      Reduces overhead of each shuffle block for consolidation from >300 bytes to 8 bytes (1 primitive Long). Verified via profiler testing with 1 mil shuffle blocks, net overhead was ~8,400,000 bytes.
      
      Despite the memory-optimized implementation incurring extra CPU overhead, the runtime of the shuffle phase in this test was only around 2% slower, while the reduce phase was 40% faster, when compared to not using any shuffle file consolidation.
      
      This is accomplished by replacing the map from ShuffleBlockId to FileSegment (i.e., block id to where it's located), which had high overhead due to being a gigantic, timestamped, concurrent map with a more space-efficient structure. Namely, the following are introduced (I have omitted the word "Shuffle" from some names for clarity):
      **ShuffleFile** - there is one ShuffleFile per consolidated shuffle file on disk. We store an array of offsets into the physical shuffle file for each ShuffleMapTask that wrote into the file. This is sufficient to reconstruct FileSegments for mappers that are in the file.
      **FileGroup** - contains a set of ShuffleFiles, one per reducer, that a MapTask can use to write its output. There is one FileGroup created per _concurrent_ MapTask. The FileGroup contains an array of the mapIds that have been written to all files in the group. The positions of elements in this array map directly onto the positions in each ShuffleFile's offsets array.
      
      In order to locate the FileSegment associated with a BlockId, we have another structure which maps each reducer to the set of ShuffleFiles that were created for it. (There will be as many ShuffleFiles per reducer as there are FileGroups.) To lookup a given ShuffleBlockId (shuffleId, reducerId, mapId), we thus search through all ShuffleFiles associated with that reducer.
      
      As a time optimization, we ensure that FileGroups are only reused for MapTasks with monotonically increasing mapIds. This allows us to perform a binary search to locate a mapId inside a group, and also enables potential future optimization (based on the usual monotonic access order).
      7a26104a
    • Aaron Davidson's avatar
      Minor cleanup in ShuffleBlockManager · 1ba11b1c
      Aaron Davidson authored
      1ba11b1c
    • Aaron Davidson's avatar
      Refactor ShuffleBlockManager to reduce public interface · 6201e5e2
      Aaron Davidson authored
      - ShuffleBlocks has been removed and replaced by ShuffleWriterGroup.
      - ShuffleWriterGroup no longer contains a reference to a ShuffleFileGroup.
      - ShuffleFile has been removed and its contents are now within ShuffleFileGroup.
      - ShuffleBlockManager.forShuffle has been replaced by a more stateful forMapTask.
      6201e5e2
    • Aaron Davidson's avatar
      Add javadoc and remove unused code · b0cf19fe
      Aaron Davidson authored
      b0cf19fe
  4. Nov 03, 2013
    • Aaron Davidson's avatar
      Clean up test files properly · 39d93ed4
      Aaron Davidson authored
      For some reason, even calling
      java.nio.Files.createTempDirectory().getFile.deleteOnExit()
      does not delete the directory on exit. Guava's analagous function
      seems to work, however.
      39d93ed4
    • Aaron Davidson's avatar
    • Aaron Davidson's avatar
      Address Reynold's comments · 8703898d
      Aaron Davidson authored
      8703898d
    • Aaron Davidson's avatar
      Fix test breakage · 3ca52309
      Aaron Davidson authored
      3ca52309
    • Aaron Davidson's avatar
      1592adfa
    • Aaron Davidson's avatar
      7d44dec9
    • Aaron Davidson's avatar
      Address minor comments · 7453f311
      Aaron Davidson authored
      7453f311
    • Aaron Davidson's avatar
      Memory-optimized shuffle file consolidation · 84991a1b
      Aaron Davidson authored
      Overhead of each shuffle block for consolidation has been reduced from >300 bytes
      to 8 bytes (1 primitive Long). Verified via profiler testing with 1 mil shuffle blocks,
      net overhead was ~8,400,000 bytes.
      
      Despite the memory-optimized implementation incurring extra CPU overhead, the runtime
      of the shuffle phase in this test was only around 2% slower, while the reduce phase
      was 40% faster, when compared to not using any shuffle file consolidation.
      84991a1b
    • Reynold Xin's avatar
      Merge pull request #70 from rxin/hash1 · b5dc3393
      Reynold Xin authored
      Fast, memory-efficient hash set, hash table implementations optimized for primitive data types.
      
      This pull request adds two hash table implementations optimized for primitive data types. For primitive types, the new hash tables are much faster than the current Spark AppendOnlyMap (3X faster - note that the current AppendOnlyMap is already much better than the Java map) while uses much less space (1/4 of the space).
      
      Details:
      
      This PR first adds a open hash set implementation (OpenHashSet) optimized for primitive types (using Scala's specialization feature). This OpenHashSet is designed to serve as building blocks for more advanced structures. It is currently used to build the following two hash tables, but can be used in the future to build multi-valued hash tables as well (GraphX has this use case). Note that there are some peculiarities in the code for working around some Scala compiler bugs.
      
      Building on top of OpenHashSet, this PR adds two different hash tables implementations:
      1. OpenHashSet: for nullable keys, optional specialization for primitive values
      2. PrimitiveKeyOpenHashMap: for primitive keys that are not nullable, and optional specialization for primitive values
      
      I tested the update speed of these two implementations using the changeValue function (which is what Aggregator and cogroup would use). Runtime relative to AppendOnlyMap for inserting 10 million items:
      
      Int to Int: ~30%
      java.lang.Integer to java.lang.Integer: ~100%
      Int to java.lang.Integer: ~50%
      java.lang.Integer to Int: ~85%
      b5dc3393
    • Reynold Xin's avatar
      Code review feedback. · eb5f8a3f
      Reynold Xin authored
      eb5f8a3f
    • Reynold Xin's avatar
      Fixed a bug that uses twice amount of memory for the primitive arrays due to a scala compiler bug. · 1e9543b5
      Reynold Xin authored
      Also addressed Matei's code review comment.
      1e9543b5
    • Reynold Xin's avatar
      Merge branch 'master' into hash1 · da6bb0ae
      Reynold Xin authored
      da6bb0ae
  5. Nov 02, 2013
  6. Nov 01, 2013
  7. Oct 31, 2013
Loading