2011-03-18 17:14:15 +00:00
|
|
|
// Copyright 2005 Google Inc. All Rights Reserved.
|
|
|
|
//
|
2011-03-26 02:34:34 +00:00
|
|
|
// Redistribution and use in source and binary forms, with or without
|
|
|
|
// modification, are permitted provided that the following conditions are
|
|
|
|
// met:
|
2011-03-18 17:14:15 +00:00
|
|
|
//
|
2011-03-26 02:34:34 +00:00
|
|
|
// * Redistributions of source code must retain the above copyright
|
|
|
|
// notice, this list of conditions and the following disclaimer.
|
|
|
|
// * Redistributions in binary form must reproduce the above
|
|
|
|
// copyright notice, this list of conditions and the following disclaimer
|
|
|
|
// in the documentation and/or other materials provided with the
|
|
|
|
// distribution.
|
|
|
|
// * Neither the name of Google Inc. nor the names of its
|
|
|
|
// contributors may be used to endorse or promote products derived from
|
|
|
|
// this software without specific prior written permission.
|
2011-03-18 17:14:15 +00:00
|
|
|
//
|
2011-03-26 02:34:34 +00:00
|
|
|
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
#include "snappy.h"
|
|
|
|
#include "snappy-internal.h"
|
|
|
|
#include "snappy-sinksource.h"
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
|
|
|
|
namespace snappy {
|
|
|
|
|
2015-08-19 09:37:51 +00:00
|
|
|
using internal::COPY_1_BYTE_OFFSET;
|
|
|
|
using internal::COPY_2_BYTE_OFFSET;
|
|
|
|
using internal::COPY_4_BYTE_OFFSET;
|
|
|
|
using internal::LITERAL;
|
|
|
|
using internal::char_table;
|
|
|
|
using internal::kMaximumTagLength;
|
|
|
|
using internal::wordmask;
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
// Any hash function will produce a valid compressed bitstream, but a good
|
|
|
|
// hash function reduces the number of collisions and thus yields better
|
|
|
|
// compression for compressible input, and more speed for incompressible
|
|
|
|
// input. Of course, it doesn't hurt if the hash function is reasonably fast
|
|
|
|
// either, as it gets called a lot.
|
|
|
|
static inline uint32 HashBytes(uint32 bytes, int shift) {
|
|
|
|
uint32 kMul = 0x1e35a7bd;
|
|
|
|
return (bytes * kMul) >> shift;
|
|
|
|
}
|
|
|
|
static inline uint32 Hash(const char* p, int shift) {
|
|
|
|
return HashBytes(UNALIGNED_LOAD32(p), shift);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t MaxCompressedLength(size_t source_len) {
|
|
|
|
// Compressed data can be defined as:
|
|
|
|
// compressed := item* literal*
|
|
|
|
// item := literal* copy
|
|
|
|
//
|
|
|
|
// The trailing literal sequence has a space blowup of at most 62/60
|
|
|
|
// since a literal of length 60 needs one tag byte + one extra byte
|
|
|
|
// for length information.
|
|
|
|
//
|
|
|
|
// Item blowup is trickier to measure. Suppose the "copy" op copies
|
|
|
|
// 4 bytes of data. Because of a special check in the encoding code,
|
|
|
|
// we produce a 4-byte copy only if the offset is < 65536. Therefore
|
|
|
|
// the copy op takes 3 bytes to encode, and this type of item leads
|
|
|
|
// to at most the 62/60 blowup for representing literals.
|
|
|
|
//
|
|
|
|
// Suppose the "copy" op copies 5 bytes of data. If the offset is big
|
|
|
|
// enough, it will take 5 bytes to encode the copy op. Therefore the
|
|
|
|
// worst case here is a one-byte literal followed by a five-byte copy.
|
|
|
|
// I.e., 6 bytes of input turn into 7 bytes of "compressed" data.
|
|
|
|
//
|
|
|
|
// This last factor dominates the blowup, so the final estimate is:
|
|
|
|
return 32 + source_len + source_len/6;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Copy "len" bytes from "src" to "op", one byte at a time. Used for
|
|
|
|
// handling COPY operations where the input and output regions may
|
|
|
|
// overlap. For example, suppose:
|
|
|
|
// src == "ab"
|
|
|
|
// op == src + 2
|
|
|
|
// len == 20
|
|
|
|
// After IncrementalCopy(src, op, len), the result will have
|
|
|
|
// eleven copies of "ab"
|
|
|
|
// ababababababababababab
|
|
|
|
// Note that this does not match the semantics of either memcpy()
|
|
|
|
// or memmove().
|
2013-06-14 21:42:26 +00:00
|
|
|
static inline void IncrementalCopy(const char* src, char* op, ssize_t len) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(len > 0);
|
2011-03-18 17:14:15 +00:00
|
|
|
do {
|
|
|
|
*op++ = *src++;
|
|
|
|
} while (--len > 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Equivalent to IncrementalCopy except that it can write up to ten extra
|
|
|
|
// bytes after the end of the copy, and that it is faster.
|
|
|
|
//
|
|
|
|
// The main part of this loop is a simple copy of eight bytes at a time until
|
|
|
|
// we've copied (at least) the requested amount of bytes. However, if op and
|
|
|
|
// src are less than eight bytes apart (indicating a repeating pattern of
|
|
|
|
// length < 8), we first need to expand the pattern in order to get the correct
|
|
|
|
// results. For instance, if the buffer looks like this, with the eight-byte
|
|
|
|
// <src> and <op> patterns marked as intervals:
|
|
|
|
//
|
|
|
|
// abxxxxxxxxxxxx
|
|
|
|
// [------] src
|
|
|
|
// [------] op
|
|
|
|
//
|
|
|
|
// a single eight-byte copy from <src> to <op> will repeat the pattern once,
|
|
|
|
// after which we can move <op> two bytes without moving <src>:
|
|
|
|
//
|
|
|
|
// ababxxxxxxxxxx
|
|
|
|
// [------] src
|
|
|
|
// [------] op
|
|
|
|
//
|
|
|
|
// and repeat the exercise until the two no longer overlap.
|
|
|
|
//
|
|
|
|
// This allows us to do very well in the special case of one single byte
|
|
|
|
// repeated many times, without taking a big hit for more general cases.
|
|
|
|
//
|
|
|
|
// The worst case of extra writing past the end of the match occurs when
|
|
|
|
// op - src == 1 and len == 1; the last copy will read from byte positions
|
|
|
|
// [0..7] and write to [4..11], whereas it was only supposed to write to
|
|
|
|
// position 1. Thus, ten excess bytes.
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
const int kMaxIncrementCopyOverflow = 10;
|
|
|
|
|
2013-06-14 21:42:26 +00:00
|
|
|
inline void IncrementalCopyFastPath(const char* src, char* op, ssize_t len) {
|
2015-06-22 13:41:30 +00:00
|
|
|
while (PREDICT_FALSE(op - src < 8)) {
|
2012-02-21 17:02:17 +00:00
|
|
|
UnalignedCopy64(src, op);
|
2011-03-18 17:14:15 +00:00
|
|
|
len -= op - src;
|
|
|
|
op += op - src;
|
|
|
|
}
|
|
|
|
while (len > 0) {
|
2012-02-21 17:02:17 +00:00
|
|
|
UnalignedCopy64(src, op);
|
2011-03-18 17:14:15 +00:00
|
|
|
src += 8;
|
|
|
|
op += 8;
|
|
|
|
len -= 8;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-14 21:42:26 +00:00
|
|
|
} // namespace
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
static inline char* EmitLiteral(char* op,
|
|
|
|
const char* literal,
|
|
|
|
int len,
|
|
|
|
bool allow_fast_path) {
|
|
|
|
int n = len - 1; // Zero-length literals are disallowed
|
|
|
|
if (n < 60) {
|
|
|
|
// Fits in tag byte
|
|
|
|
*op++ = LITERAL | (n << 2);
|
|
|
|
|
|
|
|
// The vast majority of copies are below 16 bytes, for which a
|
|
|
|
// call to memcpy is overkill. This fast path can sometimes
|
|
|
|
// copy up to 15 bytes too much, but that is okay in the
|
|
|
|
// main loop, since we have a bit to go on for both sides:
|
|
|
|
//
|
|
|
|
// - The input will always have kInputMarginBytes = 15 extra
|
|
|
|
// available bytes, as long as we're in the main loop, and
|
|
|
|
// if not, allow_fast_path = false.
|
|
|
|
// - The output will always have 32 spare bytes (see
|
|
|
|
// MaxCompressedLength).
|
|
|
|
if (allow_fast_path && len <= 16) {
|
2012-02-21 17:02:17 +00:00
|
|
|
UnalignedCopy64(literal, op);
|
|
|
|
UnalignedCopy64(literal + 8, op + 8);
|
2011-03-18 17:14:15 +00:00
|
|
|
return op + len;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Encode in upcoming bytes
|
|
|
|
char* base = op;
|
|
|
|
int count = 0;
|
|
|
|
op++;
|
|
|
|
while (n > 0) {
|
|
|
|
*op++ = n & 0xff;
|
|
|
|
n >>= 8;
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
assert(count >= 1);
|
|
|
|
assert(count <= 4);
|
|
|
|
*base = LITERAL | ((59+count) << 2);
|
|
|
|
}
|
|
|
|
memcpy(op, literal, len);
|
|
|
|
return op + len;
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
static inline char* EmitCopyLessThan64(char* op, size_t offset, int len) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(len <= 64);
|
|
|
|
assert(len >= 4);
|
|
|
|
assert(offset < 65536);
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
if ((len < 12) && (offset < 2048)) {
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t len_minus_4 = len - 4;
|
2011-03-18 17:14:15 +00:00
|
|
|
assert(len_minus_4 < 8); // Must fit in 3 bits
|
2013-01-04 11:54:20 +00:00
|
|
|
*op++ = COPY_1_BYTE_OFFSET + ((len_minus_4) << 2) + ((offset >> 8) << 5);
|
2011-03-18 17:14:15 +00:00
|
|
|
*op++ = offset & 0xff;
|
|
|
|
} else {
|
2013-01-04 11:54:20 +00:00
|
|
|
*op++ = COPY_2_BYTE_OFFSET + ((len-1) << 2);
|
2011-03-18 17:14:15 +00:00
|
|
|
LittleEndian::Store16(op, offset);
|
|
|
|
op += 2;
|
|
|
|
}
|
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
static inline char* EmitCopy(char* op, size_t offset, int len) {
|
2011-03-18 17:14:15 +00:00
|
|
|
// Emit 64 byte copies but make sure to keep at least four bytes reserved
|
2015-06-22 13:41:30 +00:00
|
|
|
while (PREDICT_FALSE(len >= 68)) {
|
2011-03-18 17:14:15 +00:00
|
|
|
op = EmitCopyLessThan64(op, offset, 64);
|
|
|
|
len -= 64;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit an extra 60 byte copy if have too much data to fit in one copy
|
|
|
|
if (len > 64) {
|
|
|
|
op = EmitCopyLessThan64(op, offset, 60);
|
|
|
|
len -= 60;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit remainder
|
|
|
|
op = EmitCopyLessThan64(op, offset, len);
|
|
|
|
return op;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool GetUncompressedLength(const char* start, size_t n, size_t* result) {
|
|
|
|
uint32 v = 0;
|
|
|
|
const char* limit = start + n;
|
|
|
|
if (Varint::Parse32WithLimit(start, limit, &v) != NULL) {
|
|
|
|
*result = v;
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace internal {
|
|
|
|
uint16* WorkingMemory::GetHashTable(size_t input_size, int* table_size) {
|
|
|
|
// Use smaller hash table when input.size() is smaller, since we
|
|
|
|
// fill the table, incurring O(hash table size) overhead for
|
|
|
|
// compression, and if the input is short, we won't need that
|
|
|
|
// many hash table entries anyway.
|
|
|
|
assert(kMaxHashTableSize >= 256);
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t htsize = 256;
|
2011-03-18 17:14:15 +00:00
|
|
|
while (htsize < kMaxHashTableSize && htsize < input_size) {
|
|
|
|
htsize <<= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint16* table;
|
|
|
|
if (htsize <= ARRAYSIZE(small_table_)) {
|
|
|
|
table = small_table_;
|
|
|
|
} else {
|
|
|
|
if (large_table_ == NULL) {
|
|
|
|
large_table_ = new uint16[kMaxHashTableSize];
|
|
|
|
}
|
|
|
|
table = large_table_;
|
|
|
|
}
|
|
|
|
|
|
|
|
*table_size = htsize;
|
|
|
|
memset(table, 0, htsize * sizeof(*table));
|
|
|
|
return table;
|
|
|
|
}
|
|
|
|
} // end namespace internal
|
|
|
|
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
// For 0 <= offset <= 4, GetUint32AtOffset(GetEightBytesAt(p), offset) will
|
2011-03-18 17:14:15 +00:00
|
|
|
// equal UNALIGNED_LOAD32(p + offset). Motivation: On x86-64 hardware we have
|
|
|
|
// empirically found that overlapping loads such as
|
|
|
|
// UNALIGNED_LOAD32(p) ... UNALIGNED_LOAD32(p+1) ... UNALIGNED_LOAD32(p+2)
|
|
|
|
// are slower than UNALIGNED_LOAD64(p) followed by shifts and casts to uint32.
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
//
|
|
|
|
// We have different versions for 64- and 32-bit; ideally we would avoid the
|
|
|
|
// two functions and just inline the UNALIGNED_LOAD64 call into
|
|
|
|
// GetUint32AtOffset, but GCC (at least not as of 4.6) is seemingly not clever
|
|
|
|
// enough to avoid loading the value multiple times then. For 64-bit, the load
|
|
|
|
// is done when GetEightBytesAt() is called, whereas for 32-bit, the load is
|
|
|
|
// done at GetUint32AtOffset() time.
|
|
|
|
|
|
|
|
#ifdef ARCH_K8
|
|
|
|
|
|
|
|
typedef uint64 EightBytesReference;
|
|
|
|
|
|
|
|
static inline EightBytesReference GetEightBytesAt(const char* ptr) {
|
|
|
|
return UNALIGNED_LOAD64(ptr);
|
|
|
|
}
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
static inline uint32 GetUint32AtOffset(uint64 v, int offset) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(offset >= 0);
|
|
|
|
assert(offset <= 4);
|
2011-03-18 17:14:15 +00:00
|
|
|
return v >> (LittleEndian::IsLittleEndian() ? 8 * offset : 32 - 8 * offset);
|
|
|
|
}
|
|
|
|
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
#else
|
|
|
|
|
|
|
|
typedef const char* EightBytesReference;
|
|
|
|
|
|
|
|
static inline EightBytesReference GetEightBytesAt(const char* ptr) {
|
|
|
|
return ptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline uint32 GetUint32AtOffset(const char* v, int offset) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(offset >= 0);
|
|
|
|
assert(offset <= 4);
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
return UNALIGNED_LOAD32(v + offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
// Flat array compression that does not emit the "uncompressed length"
|
|
|
|
// prefix. Compresses "input" string to the "*op" buffer.
|
|
|
|
//
|
|
|
|
// REQUIRES: "input" is at most "kBlockSize" bytes long.
|
|
|
|
// REQUIRES: "op" points to an array of memory that is at least
|
|
|
|
// "MaxCompressedLength(input.size())" in size.
|
|
|
|
// REQUIRES: All elements in "table[0..table_size-1]" are initialized to zero.
|
|
|
|
// REQUIRES: "table_size" is a power of two
|
|
|
|
//
|
|
|
|
// Returns an "end" pointer into "op" buffer.
|
|
|
|
// "end - op" is the compressed size of "input".
|
|
|
|
namespace internal {
|
2011-06-28 11:40:25 +00:00
|
|
|
char* CompressFragment(const char* input,
|
|
|
|
size_t input_size,
|
2011-03-18 17:14:15 +00:00
|
|
|
char* op,
|
|
|
|
uint16* table,
|
|
|
|
const int table_size) {
|
|
|
|
// "ip" is the input pointer, and "op" is the output pointer.
|
|
|
|
const char* ip = input;
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(input_size <= kBlockSize);
|
|
|
|
assert((table_size & (table_size - 1)) == 0); // table must be power of two
|
2011-03-18 17:14:15 +00:00
|
|
|
const int shift = 32 - Bits::Log2Floor(table_size);
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(static_cast<int>(kuint32max >> shift) == table_size - 1);
|
2011-03-18 17:14:15 +00:00
|
|
|
const char* ip_end = input + input_size;
|
|
|
|
const char* base_ip = ip;
|
|
|
|
// Bytes in [next_emit, ip) will be emitted as literal bytes. Or
|
|
|
|
// [next_emit, ip_end) after the main loop.
|
|
|
|
const char* next_emit = ip;
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t kInputMarginBytes = 15;
|
2011-03-18 17:14:15 +00:00
|
|
|
if (PREDICT_TRUE(input_size >= kInputMarginBytes)) {
|
|
|
|
const char* ip_limit = input + input_size - kInputMarginBytes;
|
|
|
|
|
|
|
|
for (uint32 next_hash = Hash(++ip, shift); ; ) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(next_emit < ip);
|
2011-03-18 17:14:15 +00:00
|
|
|
// The body of this loop calls EmitLiteral once and then EmitCopy one or
|
|
|
|
// more times. (The exception is that when we're close to exhausting
|
|
|
|
// the input we goto emit_remainder.)
|
|
|
|
//
|
|
|
|
// In the first iteration of this loop we're just starting, so
|
|
|
|
// there's nothing to copy, so calling EmitLiteral once is
|
|
|
|
// necessary. And we only start a new iteration when the
|
|
|
|
// current iteration has determined that a call to EmitLiteral will
|
|
|
|
// precede the next call to EmitCopy (if any).
|
|
|
|
//
|
|
|
|
// Step 1: Scan forward in the input looking for a 4-byte-long match.
|
|
|
|
// If we get close to exhausting the input then goto emit_remainder.
|
|
|
|
//
|
|
|
|
// Heuristic match skipping: If 32 bytes are scanned with no matches
|
|
|
|
// found, start looking only at every other byte. If 32 more bytes are
|
Make heuristic match skipping more aggressive.
This causes compression to be much faster on incompressible inputs
(such as the jpeg and pdf tests), and is neutral or even positive on the other
tests. The test set shows only microscopic density regressions; I attempted to
construct a worst-case test set containing ~1500 different cases of mixed
plaintext + /dev/urandom, and even those seemed to be only 0.38 percentage
points less dense on average (the single worst case was 87.8% -> 89.0%), which
we can live with given that this is already an edge case.
The original idea is by Klaus Post; I only tweaked the implementation.
Ironically, the new implementation is almost more in line with the
comment that was there, so I've left that largely alone, albeit
with a small modification.
Microbenchmark results (opt mode, 64-bit, static linking):
Ivy Bridge:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 120284 115480 847.0MB/s html (22.31 %) +4.2%
BM_ZFlat/1 1527911 1522242 440.7MB/s urls (47.78 %) +0.4%
BM_ZFlat/2 17591 10582 10.9GB/s jpg (99.95 %) +66.2%
BM_ZFlat/3 323 322 593.3MB/s jpg_200 (73.00 %) +0.3%
BM_ZFlat/4 53691 14063 6.8GB/s pdf (83.30 %) +281.8%
BM_ZFlat/5 495442 492347 794.8MB/s html4 (22.52 %) +0.6%
BM_ZFlat/6 473523 473622 306.7MB/s txt1 (57.88 %) -0.0%
BM_ZFlat/7 421406 420120 284.5MB/s txt2 (61.91 %) +0.3%
BM_ZFlat/8 1265632 1270538 320.8MB/s txt3 (54.99 %) -0.4%
BM_ZFlat/9 1742688 1737894 264.8MB/s txt4 (66.26 %) +0.3%
BM_ZFlat/10 107950 103404 1095.1MB/s pb (19.68 %) +4.4%
BM_ZFlat/11 372660 371818 473.5MB/s gaviota (37.72 %) +0.2%
BM_ZFlat/12 53239 49528 474.4MB/s cp (48.12 %) +7.5%
BM_ZFlat/13 18940 17349 613.9MB/s c (42.47 %) +9.2%
BM_ZFlat/14 5155 5075 700.3MB/s lsp (48.37 %) +1.6%
BM_ZFlat/15 1474757 1474471 667.2MB/s xls (41.23 %) +0.0%
BM_ZFlat/16 363 362 528.0MB/s xls_200 (78.00 %) +0.3%
BM_ZFlat/17 453849 456931 1073.2MB/s bin (18.11 %) -0.7%
BM_ZFlat/18 90 87 2.1GB/s bin_200 (7.50 %) +3.4%
BM_ZFlat/19 82163 80498 453.7MB/s sum (48.96 %) +2.1%
BM_ZFlat/20 7174 7124 566.7MB/s man (59.21 %) +0.7%
Sum of all benchmarks 8694831 8623857 +0.8%
Sandy Bridge:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 117426 112649 868.2MB/s html (22.31 %) +4.2%
BM_ZFlat/1 1517095 1498522 447.5MB/s urls (47.78 %) +1.2%
BM_ZFlat/2 18601 10649 10.8GB/s jpg (99.95 %) +74.7%
BM_ZFlat/3 359 356 536.0MB/s jpg_200 (73.00 %) +0.8%
BM_ZFlat/4 60249 13832 6.9GB/s pdf (83.30 %) +335.6%
BM_ZFlat/5 481246 475571 822.7MB/s html4 (22.52 %) +1.2%
BM_ZFlat/6 460541 455693 318.8MB/s txt1 (57.88 %) +1.1%
BM_ZFlat/7 407751 404147 295.8MB/s txt2 (61.91 %) +0.9%
BM_ZFlat/8 1228255 1222519 333.4MB/s txt3 (54.99 %) +0.5%
BM_ZFlat/9 1678299 1666379 276.2MB/s txt4 (66.26 %) +0.7%
BM_ZFlat/10 106499 101715 1113.4MB/s pb (19.68 %) +4.7%
BM_ZFlat/11 361913 360222 488.7MB/s gaviota (37.72 %) +0.5%
BM_ZFlat/12 53137 49618 473.6MB/s cp (48.12 %) +7.1%
BM_ZFlat/13 18801 17812 597.8MB/s c (42.47 %) +5.6%
BM_ZFlat/14 5394 5383 660.2MB/s lsp (48.37 %) +0.2%
BM_ZFlat/15 1435411 1432870 686.4MB/s xls (41.23 %) +0.2%
BM_ZFlat/16 389 395 483.3MB/s xls_200 (78.00 %) -1.5%
BM_ZFlat/17 447255 445510 1100.4MB/s bin (18.11 %) +0.4%
BM_ZFlat/18 86 86 2.2GB/s bin_200 (7.50 %) +0.0%
BM_ZFlat/19 82555 79512 459.3MB/s sum (48.96 %) +3.8%
BM_ZFlat/20 7527 7553 534.5MB/s man (59.21 %) -0.3%
Sum of all benchmarks 8488789 8360993 +1.5%
Haswell:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 107512 105621 925.6MB/s html (22.31 %) +1.8%
BM_ZFlat/1 1344306 1332479 503.1MB/s urls (47.78 %) +0.9%
BM_ZFlat/2 14752 9471 12.1GB/s jpg (99.95 %) +55.8%
BM_ZFlat/3 287 275 694.0MB/s jpg_200 (73.00 %) +4.4%
BM_ZFlat/4 48810 12263 7.8GB/s pdf (83.30 %) +298.0%
BM_ZFlat/5 443013 442064 884.6MB/s html4 (22.52 %) +0.2%
BM_ZFlat/6 429239 432124 336.0MB/s txt1 (57.88 %) -0.7%
BM_ZFlat/7 381765 383681 311.5MB/s txt2 (61.91 %) -0.5%
BM_ZFlat/8 1136667 1154304 353.0MB/s txt3 (54.99 %) -1.5%
BM_ZFlat/9 1579925 1592431 288.9MB/s txt4 (66.26 %) -0.8%
BM_ZFlat/10 98345 92411 1.2GB/s pb (19.68 %) +6.4%
BM_ZFlat/11 340397 340466 516.8MB/s gaviota (37.72 %) -0.0%
BM_ZFlat/12 47076 43536 539.5MB/s cp (48.12 %) +8.1%
BM_ZFlat/13 16680 15637 680.8MB/s c (42.47 %) +6.7%
BM_ZFlat/14 4616 4539 782.6MB/s lsp (48.37 %) +1.7%
BM_ZFlat/15 1331231 1334094 736.9MB/s xls (41.23 %) -0.2%
BM_ZFlat/16 326 322 593.5MB/s xls_200 (78.00 %) +1.2%
BM_ZFlat/17 404383 400326 1.2GB/s bin (18.11 %) +1.0%
BM_ZFlat/18 69 69 2.7GB/s bin_200 (7.50 %) +0.0%
BM_ZFlat/19 74771 71348 511.7MB/s sum (48.96 %) +4.8%
BM_ZFlat/20 6461 6383 632.2MB/s man (59.21 %) +1.2%
Sum of all benchmarks 7810631 7773844 +0.5%
I've done a quick test that there are no performance regressions on external
GCC (4.9.2, Debian, Haswell, 64-bit), too.
2016-04-05 09:50:26 +00:00
|
|
|
// scanned (or skipped), look at every third byte, etc.. When a match is
|
|
|
|
// found, immediately go back to looking at every byte. This is a small
|
|
|
|
// loss (~5% performance, ~0.1% density) for compressible data due to more
|
2011-03-18 17:14:15 +00:00
|
|
|
// bookkeeping, but for non-compressible data (such as JPEG) it's a huge
|
|
|
|
// win since the compressor quickly "realizes" the data is incompressible
|
|
|
|
// and doesn't bother looking for matches everywhere.
|
|
|
|
//
|
|
|
|
// The "skip" variable keeps track of how many bytes there are since the
|
|
|
|
// last match; dividing it by 32 (ie. right-shifting by five) gives the
|
|
|
|
// number of bytes to move ahead for each iteration.
|
|
|
|
uint32 skip = 32;
|
|
|
|
|
|
|
|
const char* next_ip = ip;
|
|
|
|
const char* candidate;
|
|
|
|
do {
|
|
|
|
ip = next_ip;
|
|
|
|
uint32 hash = next_hash;
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(hash == Hash(ip, shift));
|
Make heuristic match skipping more aggressive.
This causes compression to be much faster on incompressible inputs
(such as the jpeg and pdf tests), and is neutral or even positive on the other
tests. The test set shows only microscopic density regressions; I attempted to
construct a worst-case test set containing ~1500 different cases of mixed
plaintext + /dev/urandom, and even those seemed to be only 0.38 percentage
points less dense on average (the single worst case was 87.8% -> 89.0%), which
we can live with given that this is already an edge case.
The original idea is by Klaus Post; I only tweaked the implementation.
Ironically, the new implementation is almost more in line with the
comment that was there, so I've left that largely alone, albeit
with a small modification.
Microbenchmark results (opt mode, 64-bit, static linking):
Ivy Bridge:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 120284 115480 847.0MB/s html (22.31 %) +4.2%
BM_ZFlat/1 1527911 1522242 440.7MB/s urls (47.78 %) +0.4%
BM_ZFlat/2 17591 10582 10.9GB/s jpg (99.95 %) +66.2%
BM_ZFlat/3 323 322 593.3MB/s jpg_200 (73.00 %) +0.3%
BM_ZFlat/4 53691 14063 6.8GB/s pdf (83.30 %) +281.8%
BM_ZFlat/5 495442 492347 794.8MB/s html4 (22.52 %) +0.6%
BM_ZFlat/6 473523 473622 306.7MB/s txt1 (57.88 %) -0.0%
BM_ZFlat/7 421406 420120 284.5MB/s txt2 (61.91 %) +0.3%
BM_ZFlat/8 1265632 1270538 320.8MB/s txt3 (54.99 %) -0.4%
BM_ZFlat/9 1742688 1737894 264.8MB/s txt4 (66.26 %) +0.3%
BM_ZFlat/10 107950 103404 1095.1MB/s pb (19.68 %) +4.4%
BM_ZFlat/11 372660 371818 473.5MB/s gaviota (37.72 %) +0.2%
BM_ZFlat/12 53239 49528 474.4MB/s cp (48.12 %) +7.5%
BM_ZFlat/13 18940 17349 613.9MB/s c (42.47 %) +9.2%
BM_ZFlat/14 5155 5075 700.3MB/s lsp (48.37 %) +1.6%
BM_ZFlat/15 1474757 1474471 667.2MB/s xls (41.23 %) +0.0%
BM_ZFlat/16 363 362 528.0MB/s xls_200 (78.00 %) +0.3%
BM_ZFlat/17 453849 456931 1073.2MB/s bin (18.11 %) -0.7%
BM_ZFlat/18 90 87 2.1GB/s bin_200 (7.50 %) +3.4%
BM_ZFlat/19 82163 80498 453.7MB/s sum (48.96 %) +2.1%
BM_ZFlat/20 7174 7124 566.7MB/s man (59.21 %) +0.7%
Sum of all benchmarks 8694831 8623857 +0.8%
Sandy Bridge:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 117426 112649 868.2MB/s html (22.31 %) +4.2%
BM_ZFlat/1 1517095 1498522 447.5MB/s urls (47.78 %) +1.2%
BM_ZFlat/2 18601 10649 10.8GB/s jpg (99.95 %) +74.7%
BM_ZFlat/3 359 356 536.0MB/s jpg_200 (73.00 %) +0.8%
BM_ZFlat/4 60249 13832 6.9GB/s pdf (83.30 %) +335.6%
BM_ZFlat/5 481246 475571 822.7MB/s html4 (22.52 %) +1.2%
BM_ZFlat/6 460541 455693 318.8MB/s txt1 (57.88 %) +1.1%
BM_ZFlat/7 407751 404147 295.8MB/s txt2 (61.91 %) +0.9%
BM_ZFlat/8 1228255 1222519 333.4MB/s txt3 (54.99 %) +0.5%
BM_ZFlat/9 1678299 1666379 276.2MB/s txt4 (66.26 %) +0.7%
BM_ZFlat/10 106499 101715 1113.4MB/s pb (19.68 %) +4.7%
BM_ZFlat/11 361913 360222 488.7MB/s gaviota (37.72 %) +0.5%
BM_ZFlat/12 53137 49618 473.6MB/s cp (48.12 %) +7.1%
BM_ZFlat/13 18801 17812 597.8MB/s c (42.47 %) +5.6%
BM_ZFlat/14 5394 5383 660.2MB/s lsp (48.37 %) +0.2%
BM_ZFlat/15 1435411 1432870 686.4MB/s xls (41.23 %) +0.2%
BM_ZFlat/16 389 395 483.3MB/s xls_200 (78.00 %) -1.5%
BM_ZFlat/17 447255 445510 1100.4MB/s bin (18.11 %) +0.4%
BM_ZFlat/18 86 86 2.2GB/s bin_200 (7.50 %) +0.0%
BM_ZFlat/19 82555 79512 459.3MB/s sum (48.96 %) +3.8%
BM_ZFlat/20 7527 7553 534.5MB/s man (59.21 %) -0.3%
Sum of all benchmarks 8488789 8360993 +1.5%
Haswell:
Benchmark Base (ns) New (ns) Improvement
----------------------------------------------------------------------------------------
BM_ZFlat/0 107512 105621 925.6MB/s html (22.31 %) +1.8%
BM_ZFlat/1 1344306 1332479 503.1MB/s urls (47.78 %) +0.9%
BM_ZFlat/2 14752 9471 12.1GB/s jpg (99.95 %) +55.8%
BM_ZFlat/3 287 275 694.0MB/s jpg_200 (73.00 %) +4.4%
BM_ZFlat/4 48810 12263 7.8GB/s pdf (83.30 %) +298.0%
BM_ZFlat/5 443013 442064 884.6MB/s html4 (22.52 %) +0.2%
BM_ZFlat/6 429239 432124 336.0MB/s txt1 (57.88 %) -0.7%
BM_ZFlat/7 381765 383681 311.5MB/s txt2 (61.91 %) -0.5%
BM_ZFlat/8 1136667 1154304 353.0MB/s txt3 (54.99 %) -1.5%
BM_ZFlat/9 1579925 1592431 288.9MB/s txt4 (66.26 %) -0.8%
BM_ZFlat/10 98345 92411 1.2GB/s pb (19.68 %) +6.4%
BM_ZFlat/11 340397 340466 516.8MB/s gaviota (37.72 %) -0.0%
BM_ZFlat/12 47076 43536 539.5MB/s cp (48.12 %) +8.1%
BM_ZFlat/13 16680 15637 680.8MB/s c (42.47 %) +6.7%
BM_ZFlat/14 4616 4539 782.6MB/s lsp (48.37 %) +1.7%
BM_ZFlat/15 1331231 1334094 736.9MB/s xls (41.23 %) -0.2%
BM_ZFlat/16 326 322 593.5MB/s xls_200 (78.00 %) +1.2%
BM_ZFlat/17 404383 400326 1.2GB/s bin (18.11 %) +1.0%
BM_ZFlat/18 69 69 2.7GB/s bin_200 (7.50 %) +0.0%
BM_ZFlat/19 74771 71348 511.7MB/s sum (48.96 %) +4.8%
BM_ZFlat/20 6461 6383 632.2MB/s man (59.21 %) +1.2%
Sum of all benchmarks 7810631 7773844 +0.5%
I've done a quick test that there are no performance regressions on external
GCC (4.9.2, Debian, Haswell, 64-bit), too.
2016-04-05 09:50:26 +00:00
|
|
|
uint32 bytes_between_hash_lookups = skip >> 5;
|
|
|
|
skip += bytes_between_hash_lookups;
|
2011-03-18 17:14:15 +00:00
|
|
|
next_ip = ip + bytes_between_hash_lookups;
|
|
|
|
if (PREDICT_FALSE(next_ip > ip_limit)) {
|
|
|
|
goto emit_remainder;
|
|
|
|
}
|
|
|
|
next_hash = Hash(next_ip, shift);
|
|
|
|
candidate = base_ip + table[hash];
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(candidate >= base_ip);
|
|
|
|
assert(candidate < ip);
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
table[hash] = ip - base_ip;
|
|
|
|
} while (PREDICT_TRUE(UNALIGNED_LOAD32(ip) !=
|
|
|
|
UNALIGNED_LOAD32(candidate)));
|
|
|
|
|
|
|
|
// Step 2: A 4-byte match has been found. We'll later see if more
|
|
|
|
// than 4 bytes match. But, prior to the match, input
|
|
|
|
// bytes [next_emit, ip) are unmatched. Emit them as "literal bytes."
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(next_emit + 16 <= ip_end);
|
2011-03-18 17:14:15 +00:00
|
|
|
op = EmitLiteral(op, next_emit, ip - next_emit, true);
|
|
|
|
|
|
|
|
// Step 3: Call EmitCopy, and then see if another EmitCopy could
|
|
|
|
// be our next move. Repeat until we find no match for the
|
|
|
|
// input immediately after what was consumed by the last EmitCopy call.
|
|
|
|
//
|
|
|
|
// If we exit this loop normally then we need to call EmitLiteral next,
|
|
|
|
// though we don't yet know how big the literal will be. We handle that
|
|
|
|
// by proceeding to the next iteration of the main loop. We also can exit
|
|
|
|
// this loop via goto if we get close to exhausting the input.
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
EightBytesReference input_bytes;
|
2011-03-18 17:14:15 +00:00
|
|
|
uint32 candidate_bytes = 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
// We have a 4-byte match at ip, and no need to emit any
|
|
|
|
// "literal bytes" prior to ip.
|
|
|
|
const char* base = ip;
|
|
|
|
int matched = 4 + FindMatchLength(candidate + 4, ip + 4, ip_end);
|
|
|
|
ip += matched;
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t offset = base - candidate;
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(0 == memcmp(base, candidate, matched));
|
2011-03-18 17:14:15 +00:00
|
|
|
op = EmitCopy(op, offset, matched);
|
|
|
|
// We could immediately start working at ip now, but to improve
|
|
|
|
// compression we first update table[Hash(ip - 1, ...)].
|
|
|
|
const char* insert_tail = ip - 1;
|
|
|
|
next_emit = ip;
|
|
|
|
if (PREDICT_FALSE(ip >= ip_limit)) {
|
|
|
|
goto emit_remainder;
|
|
|
|
}
|
For 32-bit platforms, do not try to accelerate multiple neighboring
32-bit loads with a 64-bit load during compression (it's not a win).
The main target for this optimization is ARM, but 32-bit x86 gets
a small gain, too, although there is noise in the microbenchmarks.
It's a no-op for 64-bit x86. It does not affect decompression.
Microbenchmark results on a Cortex-A9 1GHz, using g++ 4.6.2 (from
Ubuntu/Linaro), -O2 -DNDEBUG -Wa,-march=armv7a -mtune=cortex-a9
-mthumb-interwork, minimum 1000 iterations:
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 1158277 1160000 1000 84.2MB/s html (23.57 %) [ +4.3%]
BM_ZFlat/1 14861782 14860000 1000 45.1MB/s urls (50.89 %) [ +1.1%]
BM_ZFlat/2 393595 390000 1000 310.5MB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 650583 650000 1000 138.4MB/s pdf (82.13 %) [ +3.1%]
BM_ZFlat/4 4661480 4660000 1000 83.8MB/s html4 (23.55 %) [ +4.3%]
BM_ZFlat/5 491973 490000 1000 47.9MB/s cp (48.12 %) [ +2.0%]
BM_ZFlat/6 193575 192678 1038 55.2MB/s c (42.40 %) [ +9.0%]
BM_ZFlat/7 62343 62754 3187 56.5MB/s lsp (48.37 %) [ +2.6%]
BM_ZFlat/8 17708468 17710000 1000 55.5MB/s xls (41.34 %) [ -0.3%]
BM_ZFlat/9 3755345 3760000 1000 38.6MB/s txt1 (59.81 %) [ +8.2%]
BM_ZFlat/10 3324217 3320000 1000 36.0MB/s txt2 (64.07 %) [ +4.2%]
BM_ZFlat/11 10139932 10140000 1000 40.1MB/s txt3 (57.11 %) [ +6.4%]
BM_ZFlat/12 13532109 13530000 1000 34.0MB/s txt4 (68.35 %) [ +5.0%]
BM_ZFlat/13 4690847 4690000 1000 104.4MB/s bin (18.21 %) [ +4.1%]
BM_ZFlat/14 830682 830000 1000 43.9MB/s sum (51.88 %) [ +1.2%]
BM_ZFlat/15 84784 85011 2235 47.4MB/s man (59.36 %) [ +1.1%]
BM_ZFlat/16 1293254 1290000 1000 87.7MB/s pb (23.15 %) [ +2.3%]
BM_ZFlat/17 2775155 2780000 1000 63.2MB/s gaviota (38.27 %) [+12.2%]
Core i7 in 32-bit mode (only one run and 100 iterations, though, so noisy):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_ZFlat/0 227582 223464 3043 437.0MB/s html (23.57 %) [ +7.4%]
BM_ZFlat/1 2982430 2918455 233 229.4MB/s urls (50.89 %) [ +2.9%]
BM_ZFlat/2 46967 46658 15217 2.5GB/s jpg (99.88 %) [ +0.0%]
BM_ZFlat/3 115298 114864 5833 783.2MB/s pdf (82.13 %) [ +1.5%]
BM_ZFlat/4 913440 899743 778 434.2MB/s html4 (23.55 %) [ +0.3%]
BM_ZFlat/5 110302 108571 7000 216.1MB/s cp (48.12 %) [ +0.0%]
BM_ZFlat/6 44409 43372 15909 245.2MB/s c (42.40 %) [ +0.8%]
BM_ZFlat/7 15713 15643 46667 226.9MB/s lsp (48.37 %) [ +2.7%]
BM_ZFlat/8 2625539 2602230 269 377.4MB/s xls (41.34 %) [ +1.4%]
BM_ZFlat/9 808884 811429 875 178.8MB/s txt1 (59.81 %) [ -3.9%]
BM_ZFlat/10 709532 700000 1000 170.5MB/s txt2 (64.07 %) [ +0.0%]
BM_ZFlat/11 2177682 2162162 333 188.2MB/s txt3 (57.11 %) [ -1.4%]
BM_ZFlat/12 2849640 2840000 250 161.8MB/s txt4 (68.35 %) [ -1.4%]
BM_ZFlat/13 849760 835476 778 585.8MB/s bin (18.21 %) [ +1.2%]
BM_ZFlat/14 165940 164571 4375 221.6MB/s sum (51.88 %) [ +1.4%]
BM_ZFlat/15 20939 20571 35000 196.0MB/s man (59.36 %) [ +2.1%]
BM_ZFlat/16 239209 236544 2917 478.1MB/s pb (23.15 %) [ +4.2%]
BM_ZFlat/17 616206 610000 1000 288.2MB/s gaviota (38.27 %) [ -1.6%]
R=sanjay
git-svn-id: https://snappy.googlecode.com/svn/trunk@60 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2012-02-23 17:00:36 +00:00
|
|
|
input_bytes = GetEightBytesAt(insert_tail);
|
2011-03-18 17:14:15 +00:00
|
|
|
uint32 prev_hash = HashBytes(GetUint32AtOffset(input_bytes, 0), shift);
|
|
|
|
table[prev_hash] = ip - base_ip - 1;
|
|
|
|
uint32 cur_hash = HashBytes(GetUint32AtOffset(input_bytes, 1), shift);
|
|
|
|
candidate = base_ip + table[cur_hash];
|
|
|
|
candidate_bytes = UNALIGNED_LOAD32(candidate);
|
|
|
|
table[cur_hash] = ip - base_ip;
|
|
|
|
} while (GetUint32AtOffset(input_bytes, 1) == candidate_bytes);
|
|
|
|
|
|
|
|
next_hash = HashBytes(GetUint32AtOffset(input_bytes, 2), shift);
|
|
|
|
++ip;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
emit_remainder:
|
|
|
|
// Emit the remaining bytes as a literal
|
|
|
|
if (next_emit < ip_end) {
|
|
|
|
op = EmitLiteral(op, next_emit, ip_end - next_emit, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
return op;
|
|
|
|
}
|
|
|
|
} // end namespace internal
|
|
|
|
|
|
|
|
// Signature of output types needed by decompression code.
|
|
|
|
// The decompression code is templatized on a type that obeys this
|
|
|
|
// signature so that we do not pay virtual function call overhead in
|
|
|
|
// the middle of a tight decompression loop.
|
|
|
|
//
|
|
|
|
// class DecompressionWriter {
|
|
|
|
// public:
|
|
|
|
// // Called before decompression
|
|
|
|
// void SetExpectedLength(size_t length);
|
|
|
|
//
|
|
|
|
// // Called after decompression
|
|
|
|
// bool CheckLength() const;
|
|
|
|
//
|
|
|
|
// // Called repeatedly during decompression
|
2012-01-04 13:10:46 +00:00
|
|
|
// bool Append(const char* ip, size_t length);
|
|
|
|
// bool AppendFromSelf(uint32 offset, size_t length);
|
2011-03-18 17:14:15 +00:00
|
|
|
//
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
// // The rules for how TryFastAppend differs from Append are somewhat
|
|
|
|
// // convoluted:
|
2011-11-23 11:14:17 +00:00
|
|
|
// //
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
// // - TryFastAppend is allowed to decline (return false) at any
|
|
|
|
// // time, for any reason -- just "return false" would be
|
|
|
|
// // a perfectly legal implementation of TryFastAppend.
|
|
|
|
// // The intention is for TryFastAppend to allow a fast path
|
|
|
|
// // in the common case of a small append.
|
|
|
|
// // - TryFastAppend is allowed to read up to <available> bytes
|
|
|
|
// // from the input buffer, whereas Append is allowed to read
|
|
|
|
// // <length>. However, if it returns true, it must leave
|
|
|
|
// // at least five (kMaximumTagLength) bytes in the input buffer
|
|
|
|
// // afterwards, so that there is always enough space to read the
|
|
|
|
// // next tag without checking for a refill.
|
|
|
|
// // - TryFastAppend must always return decline (return false)
|
|
|
|
// // if <length> is 61 or more, as in this case the literal length is not
|
|
|
|
// // decoded fully. In practice, this should not be a big problem,
|
|
|
|
// // as it is unlikely that one would implement a fast path accepting
|
|
|
|
// // this much data.
|
2011-11-23 11:14:17 +00:00
|
|
|
// //
|
2012-01-04 13:10:46 +00:00
|
|
|
// bool TryFastAppend(const char* ip, size_t available, size_t length);
|
2011-11-23 11:14:17 +00:00
|
|
|
// };
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
|
|
|
|
// Helper class for decompression
|
|
|
|
class SnappyDecompressor {
|
|
|
|
private:
|
|
|
|
Source* reader_; // Underlying source of bytes to decompress
|
|
|
|
const char* ip_; // Points to next buffered byte
|
|
|
|
const char* ip_limit_; // Points just past buffered bytes
|
|
|
|
uint32 peeked_; // Bytes peeked from reader (need to skip)
|
|
|
|
bool eof_; // Hit end of input without an error?
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
char scratch_[kMaximumTagLength]; // See RefillTag().
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
// Ensure that all of the tag metadata for the next tag is available
|
|
|
|
// in [ip_..ip_limit_-1]. Also ensures that [ip,ip+4] is readable even
|
|
|
|
// if (ip_limit_ - ip_ < 5).
|
|
|
|
//
|
|
|
|
// Returns true on success, false on error or end of input.
|
|
|
|
bool RefillTag();
|
|
|
|
|
|
|
|
public:
|
|
|
|
explicit SnappyDecompressor(Source* reader)
|
|
|
|
: reader_(reader),
|
|
|
|
ip_(NULL),
|
|
|
|
ip_limit_(NULL),
|
|
|
|
peeked_(0),
|
|
|
|
eof_(false) {
|
|
|
|
}
|
|
|
|
|
|
|
|
~SnappyDecompressor() {
|
|
|
|
// Advance past any bytes we peeked at from the reader
|
|
|
|
reader_->Skip(peeked_);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns true iff we have hit the end of the input without an error.
|
|
|
|
bool eof() const {
|
|
|
|
return eof_;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Read the uncompressed length stored at the start of the compressed data.
|
|
|
|
// On succcess, stores the length in *result and returns true.
|
|
|
|
// On failure, returns false.
|
|
|
|
bool ReadUncompressedLength(uint32* result) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(ip_ == NULL); // Must not have read anything yet
|
2011-03-18 17:14:15 +00:00
|
|
|
// Length is encoded in 1..5 bytes
|
|
|
|
*result = 0;
|
|
|
|
uint32 shift = 0;
|
|
|
|
while (true) {
|
|
|
|
if (shift >= 32) return false;
|
|
|
|
size_t n;
|
|
|
|
const char* ip = reader_->Peek(&n);
|
|
|
|
if (n == 0) return false;
|
|
|
|
const unsigned char c = *(reinterpret_cast<const unsigned char*>(ip));
|
|
|
|
reader_->Skip(1);
|
2016-01-04 11:52:15 +00:00
|
|
|
uint32 val = c & 0x7f;
|
|
|
|
if (((val << shift) >> shift) != val) return false;
|
|
|
|
*result |= val << shift;
|
2011-03-18 17:14:15 +00:00
|
|
|
if (c < 128) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
shift += 7;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Process the next item found in the input.
|
|
|
|
// Returns true if successful, false on error or end of input.
|
|
|
|
template <class Writer>
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
void DecompressAllTags(Writer* writer) {
|
2011-03-18 17:14:15 +00:00
|
|
|
const char* ip = ip_;
|
|
|
|
|
2011-12-05 21:27:26 +00:00
|
|
|
// We could have put this refill fragment only at the beginning of the loop.
|
|
|
|
// However, duplicating it at the end of each branch gives the compiler more
|
|
|
|
// scope to optimize the <ip_limit_ - ip> expression based on the local
|
|
|
|
// context, which overall increases speed.
|
|
|
|
#define MAYBE_REFILL() \
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
if (ip_limit_ - ip < kMaximumTagLength) { \
|
2011-12-05 21:27:26 +00:00
|
|
|
ip_ = ip; \
|
|
|
|
if (!RefillTag()) return; \
|
|
|
|
ip = ip_; \
|
|
|
|
}
|
|
|
|
|
|
|
|
MAYBE_REFILL();
|
|
|
|
for ( ;; ) {
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
const unsigned char c = *(reinterpret_cast<const unsigned char*>(ip++));
|
|
|
|
|
|
|
|
if ((c & 0x3) == LITERAL) {
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t literal_length = (c >> 2) + 1u;
|
2011-11-23 11:14:17 +00:00
|
|
|
if (writer->TryFastAppend(ip, ip_limit_ - ip, literal_length)) {
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(literal_length < 61);
|
2011-11-23 11:14:17 +00:00
|
|
|
ip += literal_length;
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
// NOTE(user): There is no MAYBE_REFILL() here, as TryFastAppend()
|
|
|
|
// will not return true unless there's already at least five spare
|
|
|
|
// bytes in addition to the literal.
|
2011-11-23 11:14:17 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (PREDICT_FALSE(literal_length >= 61)) {
|
2011-06-03 20:47:14 +00:00
|
|
|
// Long literal.
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t literal_length_length = literal_length - 60;
|
2011-06-03 20:47:14 +00:00
|
|
|
literal_length =
|
2011-11-23 11:14:17 +00:00
|
|
|
(LittleEndian::Load32(ip) & wordmask[literal_length_length]) + 1;
|
2011-06-03 20:47:14 +00:00
|
|
|
ip += literal_length_length;
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t avail = ip_limit_ - ip;
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
while (avail < literal_length) {
|
2011-11-23 11:14:17 +00:00
|
|
|
if (!writer->Append(ip, avail)) return;
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
literal_length -= avail;
|
|
|
|
reader_->Skip(peeked_);
|
|
|
|
size_t n;
|
|
|
|
ip = reader_->Peek(&n);
|
|
|
|
avail = n;
|
|
|
|
peeked_ = avail;
|
2011-06-02 18:06:54 +00:00
|
|
|
if (avail == 0) return; // Premature end of input
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
ip_limit_ = ip + avail;
|
|
|
|
}
|
2011-11-23 11:14:17 +00:00
|
|
|
if (!writer->Append(ip, literal_length)) {
|
2011-06-02 18:06:54 +00:00
|
|
|
return;
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
}
|
|
|
|
ip += literal_length;
|
2011-12-05 21:27:26 +00:00
|
|
|
MAYBE_REFILL();
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
} else {
|
2011-06-03 20:47:14 +00:00
|
|
|
const uint32 entry = char_table[c];
|
|
|
|
const uint32 trailer = LittleEndian::Load32(ip) & wordmask[entry >> 11];
|
|
|
|
const uint32 length = entry & 0xff;
|
|
|
|
ip += entry >> 11;
|
|
|
|
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
// copy_offset/256 is encoded in bits 8..10. By just fetching
|
|
|
|
// those bits, we get copy_offset (since the bit-field starts at
|
|
|
|
// bit 8).
|
|
|
|
const uint32 copy_offset = entry & 0x700;
|
|
|
|
if (!writer->AppendFromSelf(copy_offset + trailer, length)) {
|
2011-06-02 18:06:54 +00:00
|
|
|
return;
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
}
|
2011-12-05 21:27:26 +00:00
|
|
|
MAYBE_REFILL();
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
}
|
2011-12-05 21:27:26 +00:00
|
|
|
|
|
|
|
#undef MAYBE_REFILL
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
bool SnappyDecompressor::RefillTag() {
|
|
|
|
const char* ip = ip_;
|
|
|
|
if (ip == ip_limit_) {
|
|
|
|
// Fetch a new fragment from the reader
|
|
|
|
reader_->Skip(peeked_); // All peeked bytes are used up
|
|
|
|
size_t n;
|
|
|
|
ip = reader_->Peek(&n);
|
|
|
|
peeked_ = n;
|
|
|
|
if (n == 0) {
|
|
|
|
eof_ = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
ip_limit_ = ip + n;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Read the tag character
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(ip < ip_limit_);
|
2011-03-18 17:14:15 +00:00
|
|
|
const unsigned char c = *(reinterpret_cast<const unsigned char*>(ip));
|
|
|
|
const uint32 entry = char_table[c];
|
|
|
|
const uint32 needed = (entry >> 11) + 1; // +1 byte for 'c'
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(needed <= sizeof(scratch_));
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
// Read more bytes from reader if needed
|
|
|
|
uint32 nbuf = ip_limit_ - ip;
|
|
|
|
if (nbuf < needed) {
|
|
|
|
// Stitch together bytes from ip and reader to form the word
|
|
|
|
// contents. We store the needed bytes in "scratch_". They
|
|
|
|
// will be consumed immediately by the caller since we do not
|
|
|
|
// read more than we need.
|
|
|
|
memmove(scratch_, ip, nbuf);
|
|
|
|
reader_->Skip(peeked_); // All peeked bytes are used up
|
|
|
|
peeked_ = 0;
|
|
|
|
while (nbuf < needed) {
|
|
|
|
size_t length;
|
|
|
|
const char* src = reader_->Peek(&length);
|
|
|
|
if (length == 0) return false;
|
|
|
|
uint32 to_add = min<uint32>(needed - nbuf, length);
|
|
|
|
memcpy(scratch_ + nbuf, src, to_add);
|
|
|
|
nbuf += to_add;
|
|
|
|
reader_->Skip(to_add);
|
|
|
|
}
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(nbuf == needed);
|
2011-03-18 17:14:15 +00:00
|
|
|
ip_ = scratch_;
|
|
|
|
ip_limit_ = scratch_ + needed;
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
} else if (nbuf < kMaximumTagLength) {
|
2011-03-18 17:14:15 +00:00
|
|
|
// Have enough bytes, but move into scratch_ so that we do not
|
|
|
|
// read past end of input
|
|
|
|
memmove(scratch_, ip, nbuf);
|
|
|
|
reader_->Skip(peeked_); // All peeked bytes are used up
|
|
|
|
peeked_ = 0;
|
|
|
|
ip_ = scratch_;
|
|
|
|
ip_limit_ = scratch_ + nbuf;
|
|
|
|
} else {
|
|
|
|
// Pass pointer to buffer returned by reader_.
|
|
|
|
ip_ = ip;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename Writer>
|
2013-06-12 19:51:15 +00:00
|
|
|
static bool InternalUncompress(Source* r, Writer* writer) {
|
2011-03-18 17:14:15 +00:00
|
|
|
// Read the uncompressed length from the front of the compressed input
|
|
|
|
SnappyDecompressor decompressor(r);
|
|
|
|
uint32 uncompressed_len = 0;
|
|
|
|
if (!decompressor.ReadUncompressedLength(&uncompressed_len)) return false;
|
2013-06-12 19:51:15 +00:00
|
|
|
return InternalUncompressAllTags(&decompressor, writer, uncompressed_len);
|
2012-01-08 17:55:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
template <typename Writer>
|
|
|
|
static bool InternalUncompressAllTags(SnappyDecompressor* decompressor,
|
|
|
|
Writer* writer,
|
2013-06-12 19:51:15 +00:00
|
|
|
uint32 uncompressed_len) {
|
2011-03-18 17:14:15 +00:00
|
|
|
writer->SetExpectedLength(uncompressed_len);
|
|
|
|
|
|
|
|
// Process the entire input
|
2012-01-08 17:55:48 +00:00
|
|
|
decompressor->DecompressAllTags(writer);
|
2015-06-22 14:03:28 +00:00
|
|
|
writer->Flush();
|
2012-01-08 17:55:48 +00:00
|
|
|
return (decompressor->eof() && writer->CheckLength());
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool GetUncompressedLength(Source* source, uint32* result) {
|
|
|
|
SnappyDecompressor decompressor(source);
|
|
|
|
return decompressor.ReadUncompressedLength(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t Compress(Source* reader, Sink* writer) {
|
|
|
|
size_t written = 0;
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t N = reader->Available();
|
2011-03-18 17:14:15 +00:00
|
|
|
char ulength[Varint::kMax32];
|
|
|
|
char* p = Varint::Encode32(ulength, N);
|
|
|
|
writer->Append(ulength, p-ulength);
|
|
|
|
written += (p - ulength);
|
|
|
|
|
|
|
|
internal::WorkingMemory wmem;
|
|
|
|
char* scratch = NULL;
|
|
|
|
char* scratch_output = NULL;
|
|
|
|
|
|
|
|
while (N > 0) {
|
|
|
|
// Get next block to compress (without copying if possible)
|
|
|
|
size_t fragment_size;
|
|
|
|
const char* fragment = reader->Peek(&fragment_size);
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(fragment_size != 0); // premature end of input
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t num_to_read = min(N, kBlockSize);
|
2011-03-18 17:14:15 +00:00
|
|
|
size_t bytes_read = fragment_size;
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
size_t pending_advance = 0;
|
2011-03-18 17:14:15 +00:00
|
|
|
if (bytes_read >= num_to_read) {
|
|
|
|
// Buffer returned by reader is large enough
|
|
|
|
pending_advance = num_to_read;
|
|
|
|
fragment_size = num_to_read;
|
|
|
|
} else {
|
|
|
|
// Read into scratch buffer
|
|
|
|
if (scratch == NULL) {
|
|
|
|
// If this is the last iteration, we want to allocate N bytes
|
|
|
|
// of space, otherwise the max possible kBlockSize space.
|
|
|
|
// num_to_read contains exactly the correct value
|
|
|
|
scratch = new char[num_to_read];
|
|
|
|
}
|
|
|
|
memcpy(scratch, fragment, bytes_read);
|
|
|
|
reader->Skip(bytes_read);
|
|
|
|
|
|
|
|
while (bytes_read < num_to_read) {
|
|
|
|
fragment = reader->Peek(&fragment_size);
|
|
|
|
size_t n = min<size_t>(fragment_size, num_to_read - bytes_read);
|
|
|
|
memcpy(scratch + bytes_read, fragment, n);
|
|
|
|
bytes_read += n;
|
|
|
|
reader->Skip(n);
|
|
|
|
}
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(bytes_read == num_to_read);
|
2011-03-18 17:14:15 +00:00
|
|
|
fragment = scratch;
|
|
|
|
fragment_size = num_to_read;
|
|
|
|
}
|
2012-05-22 09:32:50 +00:00
|
|
|
assert(fragment_size == num_to_read);
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
// Get encoding table for compression
|
|
|
|
int table_size;
|
|
|
|
uint16* table = wmem.GetHashTable(num_to_read, &table_size);
|
|
|
|
|
|
|
|
// Compress input_fragment and append to dest
|
|
|
|
const int max_output = MaxCompressedLength(num_to_read);
|
|
|
|
|
|
|
|
// Need a scratch buffer for the output, in case the byte sink doesn't
|
|
|
|
// have room for us directly.
|
|
|
|
if (scratch_output == NULL) {
|
|
|
|
scratch_output = new char[max_output];
|
|
|
|
} else {
|
|
|
|
// Since we encode kBlockSize regions followed by a region
|
|
|
|
// which is <= kBlockSize in length, a previously allocated
|
|
|
|
// scratch_output[] region is big enough for this iteration.
|
|
|
|
}
|
|
|
|
char* dest = writer->GetAppendBuffer(max_output, scratch_output);
|
|
|
|
char* end = internal::CompressFragment(fragment, fragment_size,
|
|
|
|
dest, table, table_size);
|
|
|
|
writer->Append(dest, end - dest);
|
|
|
|
written += (end - dest);
|
|
|
|
|
|
|
|
N -= num_to_read;
|
|
|
|
reader->Skip(pending_advance);
|
|
|
|
}
|
|
|
|
|
|
|
|
delete[] scratch;
|
|
|
|
delete[] scratch_output;
|
|
|
|
|
|
|
|
return written;
|
|
|
|
}
|
|
|
|
|
2013-06-13 16:19:52 +00:00
|
|
|
// -----------------------------------------------------------------------
|
|
|
|
// IOVec interfaces
|
|
|
|
// -----------------------------------------------------------------------
|
|
|
|
|
|
|
|
// A type that writes to an iovec.
|
|
|
|
// Note that this is not a "ByteSink", but a type that matches the
|
|
|
|
// Writer template argument to SnappyDecompressor::DecompressAllTags().
|
|
|
|
class SnappyIOVecWriter {
|
|
|
|
private:
|
|
|
|
const struct iovec* output_iov_;
|
|
|
|
const size_t output_iov_count_;
|
|
|
|
|
|
|
|
// We are currently writing into output_iov_[curr_iov_index_].
|
2015-08-03 11:17:04 +00:00
|
|
|
size_t curr_iov_index_;
|
2013-06-13 16:19:52 +00:00
|
|
|
|
|
|
|
// Bytes written to output_iov_[curr_iov_index_] so far.
|
|
|
|
size_t curr_iov_written_;
|
|
|
|
|
|
|
|
// Total bytes decompressed into output_iov_ so far.
|
|
|
|
size_t total_written_;
|
|
|
|
|
|
|
|
// Maximum number of bytes that will be decompressed into output_iov_.
|
|
|
|
size_t output_limit_;
|
|
|
|
|
2015-08-03 11:17:04 +00:00
|
|
|
inline char* GetIOVecPointer(size_t index, size_t offset) {
|
2013-06-13 16:19:52 +00:00
|
|
|
return reinterpret_cast<char*>(output_iov_[index].iov_base) +
|
|
|
|
offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
// Does not take ownership of iov. iov must be valid during the
|
|
|
|
// entire lifetime of the SnappyIOVecWriter.
|
|
|
|
inline SnappyIOVecWriter(const struct iovec* iov, size_t iov_count)
|
|
|
|
: output_iov_(iov),
|
|
|
|
output_iov_count_(iov_count),
|
|
|
|
curr_iov_index_(0),
|
|
|
|
curr_iov_written_(0),
|
|
|
|
total_written_(0),
|
|
|
|
output_limit_(-1) {
|
|
|
|
}
|
|
|
|
|
|
|
|
inline void SetExpectedLength(size_t len) {
|
|
|
|
output_limit_ = len;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool CheckLength() const {
|
|
|
|
return total_written_ == output_limit_;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool Append(const char* ip, size_t len) {
|
|
|
|
if (total_written_ + len > output_limit_) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
assert(curr_iov_written_ <= output_iov_[curr_iov_index_].iov_len);
|
|
|
|
if (curr_iov_written_ >= output_iov_[curr_iov_index_].iov_len) {
|
|
|
|
// This iovec is full. Go to the next one.
|
|
|
|
if (curr_iov_index_ + 1 >= output_iov_count_) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
curr_iov_written_ = 0;
|
|
|
|
++curr_iov_index_;
|
|
|
|
}
|
|
|
|
|
|
|
|
const size_t to_write = std::min(
|
|
|
|
len, output_iov_[curr_iov_index_].iov_len - curr_iov_written_);
|
|
|
|
memcpy(GetIOVecPointer(curr_iov_index_, curr_iov_written_),
|
|
|
|
ip,
|
|
|
|
to_write);
|
|
|
|
curr_iov_written_ += to_write;
|
|
|
|
total_written_ += to_write;
|
|
|
|
ip += to_write;
|
|
|
|
len -= to_write;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool TryFastAppend(const char* ip, size_t available, size_t len) {
|
|
|
|
const size_t space_left = output_limit_ - total_written_;
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
if (len <= 16 && available >= 16 + kMaximumTagLength && space_left >= 16 &&
|
2013-06-13 16:19:52 +00:00
|
|
|
output_iov_[curr_iov_index_].iov_len - curr_iov_written_ >= 16) {
|
|
|
|
// Fast path, used for the majority (about 95%) of invocations.
|
|
|
|
char* ptr = GetIOVecPointer(curr_iov_index_, curr_iov_written_);
|
|
|
|
UnalignedCopy64(ip, ptr);
|
|
|
|
UnalignedCopy64(ip + 8, ptr + 8);
|
|
|
|
curr_iov_written_ += len;
|
|
|
|
total_written_ += len;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool AppendFromSelf(size_t offset, size_t len) {
|
|
|
|
if (offset > total_written_ || offset == 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
const size_t space_left = output_limit_ - total_written_;
|
|
|
|
if (len > space_left) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Locate the iovec from which we need to start the copy.
|
2015-08-03 11:17:04 +00:00
|
|
|
size_t from_iov_index = curr_iov_index_;
|
2013-06-13 16:19:52 +00:00
|
|
|
size_t from_iov_offset = curr_iov_written_;
|
|
|
|
while (offset > 0) {
|
|
|
|
if (from_iov_offset >= offset) {
|
|
|
|
from_iov_offset -= offset;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
offset -= from_iov_offset;
|
2015-08-03 11:17:04 +00:00
|
|
|
assert(from_iov_index > 0);
|
2013-06-13 16:19:52 +00:00
|
|
|
--from_iov_index;
|
|
|
|
from_iov_offset = output_iov_[from_iov_index].iov_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Copy <len> bytes starting from the iovec pointed to by from_iov_index to
|
|
|
|
// the current iovec.
|
|
|
|
while (len > 0) {
|
|
|
|
assert(from_iov_index <= curr_iov_index_);
|
|
|
|
if (from_iov_index != curr_iov_index_) {
|
|
|
|
const size_t to_copy = std::min(
|
|
|
|
output_iov_[from_iov_index].iov_len - from_iov_offset,
|
|
|
|
len);
|
|
|
|
Append(GetIOVecPointer(from_iov_index, from_iov_offset), to_copy);
|
|
|
|
len -= to_copy;
|
|
|
|
if (len > 0) {
|
|
|
|
++from_iov_index;
|
|
|
|
from_iov_offset = 0;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
assert(curr_iov_written_ <= output_iov_[curr_iov_index_].iov_len);
|
|
|
|
size_t to_copy = std::min(output_iov_[curr_iov_index_].iov_len -
|
|
|
|
curr_iov_written_,
|
|
|
|
len);
|
|
|
|
if (to_copy == 0) {
|
|
|
|
// This iovec is full. Go to the next one.
|
|
|
|
if (curr_iov_index_ + 1 >= output_iov_count_) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
++curr_iov_index_;
|
|
|
|
curr_iov_written_ = 0;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (to_copy > len) {
|
|
|
|
to_copy = len;
|
|
|
|
}
|
|
|
|
IncrementalCopy(GetIOVecPointer(from_iov_index, from_iov_offset),
|
|
|
|
GetIOVecPointer(curr_iov_index_, curr_iov_written_),
|
|
|
|
to_copy);
|
|
|
|
curr_iov_written_ += to_copy;
|
|
|
|
from_iov_offset += to_copy;
|
|
|
|
total_written_ += to_copy;
|
|
|
|
len -= to_copy;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-06-22 14:03:28 +00:00
|
|
|
inline void Flush() {}
|
2013-06-13 16:19:52 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
bool RawUncompressToIOVec(const char* compressed, size_t compressed_length,
|
|
|
|
const struct iovec* iov, size_t iov_cnt) {
|
|
|
|
ByteArraySource reader(compressed, compressed_length);
|
|
|
|
return RawUncompressToIOVec(&reader, iov, iov_cnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool RawUncompressToIOVec(Source* compressed, const struct iovec* iov,
|
|
|
|
size_t iov_cnt) {
|
|
|
|
SnappyIOVecWriter output(iov, iov_cnt);
|
|
|
|
return InternalUncompress(compressed, &output);
|
|
|
|
}
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
// -----------------------------------------------------------------------
|
|
|
|
// Flat array interfaces
|
|
|
|
// -----------------------------------------------------------------------
|
|
|
|
|
|
|
|
// A type that writes to a flat array.
|
|
|
|
// Note that this is not a "ByteSink", but a type that matches the
|
Speed up decompression by caching ip_.
It is seemingly hard for the compiler to understand that ip_, the current input
pointer into the compressed data stream, can not alias on anything else, and
thus using it directly will incur memory traffic as it cannot be kept in a
register. The code already knew about this and cached it into a local
variable, but since Step() only decoded one tag, it had to move ip_ back into
place between every tag. This seems to have cost us a significant amount of
performance, so changing Step() into a function that decodes as much as it can
before it saves ip_ back and returns. (Note that Step() was already inlined,
so it is not the manual inlining that buys the performance here.)
The wins are about 3-6% for Core 2, 6-13% on Core i7 and 5-12% on Opteron
(for plain array-to-array decompression, in 64-bit opt mode).
There is a tiny difference in the behavior here; if an invalid literal is
encountered (ie., the writer refuses the Append() operation), ip_ will now
point to the byte past the tag byte, instead of where the literal was
originally thought to end. However, we don't use ip_ for anything after
DecompressAllTags() has returned, so this should not change external behavior
in any way.
Microbenchmark results for Core i7, 64-bit (Opteron results are similar):
Benchmark Time(ns) CPU(ns) Iterations
---------------------------------------------------
BM_UFlat/0 79134 79110 8835 1.2GB/s html [ +6.2%]
BM_UFlat/1 786126 786096 891 851.8MB/s urls [+10.0%]
BM_UFlat/2 9948 9948 69125 11.9GB/s jpg [ -1.3%]
BM_UFlat/3 31999 31998 21898 2.7GB/s pdf [ +6.5%]
BM_UFlat/4 318909 318829 2204 1.2GB/s html4 [ +6.5%]
BM_UFlat/5 31384 31390 22363 747.5MB/s cp [ +9.2%]
BM_UFlat/6 14037 14034 49858 757.7MB/s c [+10.6%]
BM_UFlat/7 4612 4612 151395 769.5MB/s lsp [ +9.5%]
BM_UFlat/8 1203174 1203007 582 816.3MB/s xls [+19.3%]
BM_UFlat/9 253869 253955 2757 571.1MB/s txt1 [+11.4%]
BM_UFlat/10 219292 219290 3194 544.4MB/s txt2 [+12.1%]
BM_UFlat/11 672135 672131 1000 605.5MB/s txt3 [+11.2%]
BM_UFlat/12 902512 902492 776 509.2MB/s txt4 [+12.5%]
BM_UFlat/13 372110 371998 1881 1.3GB/s bin [ +5.8%]
BM_UFlat/14 50407 50407 10000 723.5MB/s sum [+13.5%]
BM_UFlat/15 5699 5701 100000 707.2MB/s man [+12.4%]
BM_UFlat/16 83448 83424 8383 1.3GB/s pb [ +5.7%]
BM_UFlat/17 256958 256963 2723 684.1MB/s gaviota [ +7.9%]
BM_UValidate/0 42795 42796 16351 2.2GB/s html [+25.8%]
BM_UValidate/1 490672 490622 1427 1.3GB/s urls [+22.7%]
BM_UValidate/2 237 237 2950297 499.0GB/s jpg [+24.9%]
BM_UValidate/3 14610 14611 47901 6.0GB/s pdf [+26.8%]
BM_UValidate/4 171973 171990 4071 2.2GB/s html4 [+25.7%]
git-svn-id: https://snappy.googlecode.com/svn/trunk@38 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2011-06-02 17:59:40 +00:00
|
|
|
// Writer template argument to SnappyDecompressor::DecompressAllTags().
|
2011-03-18 17:14:15 +00:00
|
|
|
class SnappyArrayWriter {
|
|
|
|
private:
|
|
|
|
char* base_;
|
|
|
|
char* op_;
|
|
|
|
char* op_limit_;
|
|
|
|
|
|
|
|
public:
|
|
|
|
inline explicit SnappyArrayWriter(char* dst)
|
|
|
|
: base_(dst),
|
2015-06-22 14:10:47 +00:00
|
|
|
op_(dst),
|
|
|
|
op_limit_(dst) {
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inline void SetExpectedLength(size_t len) {
|
|
|
|
op_limit_ = op_ + len;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool CheckLength() const {
|
|
|
|
return op_ == op_limit_;
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool Append(const char* ip, size_t len) {
|
2011-03-18 17:14:15 +00:00
|
|
|
char* op = op_;
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t space_left = op_limit_ - op;
|
2011-11-23 11:14:17 +00:00
|
|
|
if (space_left < len) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
memcpy(op, ip, len);
|
|
|
|
op_ = op + len;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool TryFastAppend(const char* ip, size_t available, size_t len) {
|
2011-11-23 11:14:17 +00:00
|
|
|
char* op = op_;
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t space_left = op_limit_ - op;
|
In the fast path for decompressing literals, instead of checking
whether there's 16 bytes free and then checking right afterwards
(when having subtracted the literal size) that there are now
5 bytes free, just check once for 21 bytes. This skips a compare
and a branch; although it is easily predictable, it is still
a few cycles on a fast path that we would like to get rid of.
Benchmarking this yields very confusing results. On open-source
GCC 4.8.1 on Haswell, we get exactly the expected results; the
benchmarks where we hit the fast path for literals (in particular
the two HTML benchmarks and the protobuf benchmark) give very nice
speedups, and the others are not really affected.
However, benchmarks with Google's GCC branch on other hardware
is much less clear. It seems that we have a weak loss in some cases
(and the win for the “typical” win cases are not nearly as clear),
but that it depends on microarchitecture and plain luck in how we run
the benchmark. Looking at the generated assembler, it seems that
the removal of the if causes other large-scale changes in how the
function is laid out, which makes it likely that this is just bad luck.
Thus, we should keep this change, even though its exact current impact is
unclear; it's a sensible change per se, and dropping it on the basis of
microoptimization for a given compiler (or even branch of a compiler)
would seem like a bad strategy in the long run.
Microbenchmark results (all in 64-bit, opt mode):
Nehalem, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 76747 75591 1.3GB/s html +1.5%
BM_UFlat/1 765756 757040 886.3MB/s urls +1.2%
BM_UFlat/2 10867 10893 10.9GB/s jpg -0.2%
BM_UFlat/3 124 131 1.4GB/s jpg_200 -5.3%
BM_UFlat/4 31663 31596 2.8GB/s pdf +0.2%
BM_UFlat/5 314162 308176 1.2GB/s html4 +1.9%
BM_UFlat/6 29668 29746 790.6MB/s cp -0.3%
BM_UFlat/7 12958 13386 796.4MB/s c -3.2%
BM_UFlat/8 3596 3682 966.0MB/s lsp -2.3%
BM_UFlat/9 1019193 1033493 953.3MB/s xls -1.4%
BM_UFlat/10 239 247 775.3MB/s xls_200 -3.2%
BM_UFlat/11 236411 240271 606.9MB/s txt1 -1.6%
BM_UFlat/12 206639 209768 571.2MB/s txt2 -1.5%
BM_UFlat/13 627803 635722 641.4MB/s txt3 -1.2%
BM_UFlat/14 845932 857816 538.2MB/s txt4 -1.4%
BM_UFlat/15 402107 391670 1.2GB/s bin +2.7%
BM_UFlat/16 283 279 683.6MB/s bin_200 +1.4%
BM_UFlat/17 46070 46815 781.5MB/s sum -1.6%
BM_UFlat/18 5053 5163 782.0MB/s man -2.1%
BM_UFlat/19 79721 76581 1.4GB/s pb +4.1%
BM_UFlat/20 251158 252330 697.5MB/s gaviota -0.5%
Sum of all benchmarks 4966150 4980396 -0.3%
Sandy Bridge, Google GCC:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 42850 42182 2.3GB/s html +1.6%
BM_UFlat/1 525660 515816 1.3GB/s urls +1.9%
BM_UFlat/2 7173 7283 16.3GB/s jpg -1.5%
BM_UFlat/3 92 91 2.1GB/s jpg_200 +1.1%
BM_UFlat/4 15147 14872 5.9GB/s pdf +1.8%
BM_UFlat/5 199936 192116 2.0GB/s html4 +4.1%
BM_UFlat/6 12796 12443 1.8GB/s cp +2.8%
BM_UFlat/7 6588 6400 1.6GB/s c +2.9%
BM_UFlat/8 2010 1951 1.8GB/s lsp +3.0%
BM_UFlat/9 761124 763049 1.3GB/s xls -0.3%
BM_UFlat/10 186 189 1016.1MB/s xls_200 -1.6%
BM_UFlat/11 159354 158460 918.6MB/s txt1 +0.6%
BM_UFlat/12 139732 139950 856.1MB/s txt2 -0.2%
BM_UFlat/13 429917 425027 961.7MB/s txt3 +1.2%
BM_UFlat/14 585255 587324 785.8MB/s txt4 -0.4%
BM_UFlat/15 276186 266173 1.8GB/s bin +3.8%
BM_UFlat/16 205 207 925.5MB/s bin_200 -1.0%
BM_UFlat/17 24925 24935 1.4GB/s sum -0.0%
BM_UFlat/18 2632 2576 1.5GB/s man +2.2%
BM_UFlat/19 40546 39108 2.8GB/s pb +3.7%
BM_UFlat/20 175803 168209 1048.9MB/s gaviota +4.5%
Sum of all benchmarks 3408117 3368361 +1.2%
Haswell, upstream GCC 4.8.1:
Benchmark Base (ns) New (ns) Improvement
------------------------------------------------------------------------------
BM_UFlat/0 46308 40641 2.3GB/s html +13.9%
BM_UFlat/1 513385 514706 1.3GB/s urls -0.3%
BM_UFlat/2 6197 6151 19.2GB/s jpg +0.7%
BM_UFlat/3 61 61 3.0GB/s jpg_200 +0.0%
BM_UFlat/4 13551 13429 6.5GB/s pdf +0.9%
BM_UFlat/5 198317 190243 2.0GB/s html4 +4.2%
BM_UFlat/6 14768 12560 1.8GB/s cp +17.6%
BM_UFlat/7 6453 6447 1.6GB/s c +0.1%
BM_UFlat/8 1991 1980 1.8GB/s lsp +0.6%
BM_UFlat/9 766947 770424 1.2GB/s xls -0.5%
BM_UFlat/10 170 169 1.1GB/s xls_200 +0.6%
BM_UFlat/11 164350 163554 888.7MB/s txt1 +0.5%
BM_UFlat/12 145444 143830 832.1MB/s txt2 +1.1%
BM_UFlat/13 437849 438413 929.2MB/s txt3 -0.1%
BM_UFlat/14 603587 605309 759.8MB/s txt4 -0.3%
BM_UFlat/15 249799 248067 1.9GB/s bin +0.7%
BM_UFlat/16 191 188 1011.4MB/s bin_200 +1.6%
BM_UFlat/17 26064 24778 1.4GB/s sum +5.2%
BM_UFlat/18 2620 2601 1.5GB/s man +0.7%
BM_UFlat/19 44551 37373 3.0GB/s pb +19.2%
BM_UFlat/20 165408 164584 1.0GB/s gaviota +0.5%
Sum of all benchmarks 3408011 3385508 +0.7%
git-svn-id: https://snappy.googlecode.com/svn/trunk@78 03e5f5b5-db94-4691-08a0-1a8bf15f6143
2013-06-30 19:24:03 +00:00
|
|
|
if (len <= 16 && available >= 16 + kMaximumTagLength && space_left >= 16) {
|
2011-11-23 11:14:17 +00:00
|
|
|
// Fast path, used for the majority (about 95%) of invocations.
|
2012-02-21 17:02:17 +00:00
|
|
|
UnalignedCopy64(ip, op);
|
|
|
|
UnalignedCopy64(ip + 8, op + 8);
|
2011-11-23 11:14:17 +00:00
|
|
|
op_ = op + len;
|
|
|
|
return true;
|
2011-03-18 17:14:15 +00:00
|
|
|
} else {
|
2011-11-23 11:14:17 +00:00
|
|
|
return false;
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool AppendFromSelf(size_t offset, size_t len) {
|
2011-03-18 17:14:15 +00:00
|
|
|
char* op = op_;
|
2012-01-04 13:10:46 +00:00
|
|
|
const size_t space_left = op_limit_ - op;
|
2011-03-18 17:14:15 +00:00
|
|
|
|
2013-07-29 11:06:44 +00:00
|
|
|
// Check if we try to append from before the start of the buffer.
|
|
|
|
// Normally this would just be a check for "produced < offset",
|
|
|
|
// but "produced <= offset - 1u" is equivalent for every case
|
|
|
|
// except the one where offset==0, where the right side will wrap around
|
|
|
|
// to a very big number. This is convenient, as offset==0 is another
|
|
|
|
// invalid case that we also want to catch, so that we do not go
|
|
|
|
// into an infinite loop.
|
|
|
|
assert(op >= base_);
|
|
|
|
size_t produced = op - base_;
|
|
|
|
if (produced <= offset - 1u) {
|
2011-03-18 17:14:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (len <= 16 && offset >= 8 && space_left >= 16) {
|
|
|
|
// Fast path, used for the majority (70-80%) of dynamic invocations.
|
2012-02-21 17:02:17 +00:00
|
|
|
UnalignedCopy64(op - offset, op);
|
|
|
|
UnalignedCopy64(op - offset + 8, op + 8);
|
2011-03-18 17:14:15 +00:00
|
|
|
} else {
|
|
|
|
if (space_left >= len + kMaxIncrementCopyOverflow) {
|
|
|
|
IncrementalCopyFastPath(op - offset, op, len);
|
|
|
|
} else {
|
|
|
|
if (space_left < len) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
IncrementalCopy(op - offset, op, len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
op_ = op + len;
|
|
|
|
return true;
|
|
|
|
}
|
2015-06-22 14:03:28 +00:00
|
|
|
inline size_t Produced() const {
|
|
|
|
return op_ - base_;
|
|
|
|
}
|
|
|
|
inline void Flush() {}
|
2011-03-18 17:14:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
bool RawUncompress(const char* compressed, size_t n, char* uncompressed) {
|
|
|
|
ByteArraySource reader(compressed, n);
|
|
|
|
return RawUncompress(&reader, uncompressed);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool RawUncompress(Source* compressed, char* uncompressed) {
|
|
|
|
SnappyArrayWriter output(uncompressed);
|
2013-06-12 19:51:15 +00:00
|
|
|
return InternalUncompress(compressed, &output);
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Uncompress(const char* compressed, size_t n, string* uncompressed) {
|
|
|
|
size_t ulength;
|
|
|
|
if (!GetUncompressedLength(compressed, n, &ulength)) {
|
|
|
|
return false;
|
|
|
|
}
|
2013-06-12 19:51:15 +00:00
|
|
|
// On 32-bit builds: max_size() < kuint32max. Check for that instead
|
|
|
|
// of crashing (e.g., consider externally specified compressed data).
|
|
|
|
if (ulength > uncompressed->max_size()) {
|
2011-03-18 17:14:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
STLStringResizeUninitialized(uncompressed, ulength);
|
|
|
|
return RawUncompress(compressed, n, string_as_array(uncompressed));
|
|
|
|
}
|
|
|
|
|
|
|
|
// A Writer that drops everything on the floor and just does validation
|
|
|
|
class SnappyDecompressionValidator {
|
|
|
|
private:
|
|
|
|
size_t expected_;
|
|
|
|
size_t produced_;
|
|
|
|
|
|
|
|
public:
|
2015-06-22 14:10:47 +00:00
|
|
|
inline SnappyDecompressionValidator() : expected_(0), produced_(0) { }
|
2011-03-18 17:14:15 +00:00
|
|
|
inline void SetExpectedLength(size_t len) {
|
|
|
|
expected_ = len;
|
|
|
|
}
|
|
|
|
inline bool CheckLength() const {
|
|
|
|
return expected_ == produced_;
|
|
|
|
}
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool Append(const char* ip, size_t len) {
|
2011-03-18 17:14:15 +00:00
|
|
|
produced_ += len;
|
|
|
|
return produced_ <= expected_;
|
|
|
|
}
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool TryFastAppend(const char* ip, size_t available, size_t length) {
|
2011-11-23 11:14:17 +00:00
|
|
|
return false;
|
|
|
|
}
|
2012-01-04 13:10:46 +00:00
|
|
|
inline bool AppendFromSelf(size_t offset, size_t len) {
|
2013-07-29 11:06:44 +00:00
|
|
|
// See SnappyArrayWriter::AppendFromSelf for an explanation of
|
|
|
|
// the "offset - 1u" trick.
|
|
|
|
if (produced_ <= offset - 1u) return false;
|
2011-03-18 17:14:15 +00:00
|
|
|
produced_ += len;
|
|
|
|
return produced_ <= expected_;
|
|
|
|
}
|
2015-06-22 14:03:28 +00:00
|
|
|
inline void Flush() {}
|
2011-03-18 17:14:15 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
bool IsValidCompressedBuffer(const char* compressed, size_t n) {
|
|
|
|
ByteArraySource reader(compressed, n);
|
|
|
|
SnappyDecompressionValidator writer;
|
2013-06-12 19:51:15 +00:00
|
|
|
return InternalUncompress(&reader, &writer);
|
2011-03-18 17:14:15 +00:00
|
|
|
}
|
|
|
|
|
2015-06-22 14:03:28 +00:00
|
|
|
bool IsValidCompressed(Source* compressed) {
|
|
|
|
SnappyDecompressionValidator writer;
|
|
|
|
return InternalUncompress(compressed, &writer);
|
|
|
|
}
|
|
|
|
|
2011-03-18 17:14:15 +00:00
|
|
|
void RawCompress(const char* input,
|
|
|
|
size_t input_length,
|
|
|
|
char* compressed,
|
|
|
|
size_t* compressed_length) {
|
|
|
|
ByteArraySource reader(input, input_length);
|
|
|
|
UncheckedByteArraySink writer(compressed);
|
|
|
|
Compress(&reader, &writer);
|
|
|
|
|
|
|
|
// Compute how many bytes were added
|
|
|
|
*compressed_length = (writer.CurrentDestination() - compressed);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t Compress(const char* input, size_t input_length, string* compressed) {
|
|
|
|
// Pre-grow the buffer to the max length of the compressed output
|
2016-05-26 21:51:33 +00:00
|
|
|
STLStringResizeUninitialized(compressed, MaxCompressedLength(input_length));
|
2011-03-18 17:14:15 +00:00
|
|
|
|
|
|
|
size_t compressed_length;
|
|
|
|
RawCompress(input, input_length, string_as_array(compressed),
|
|
|
|
&compressed_length);
|
|
|
|
compressed->resize(compressed_length);
|
|
|
|
return compressed_length;
|
|
|
|
}
|
|
|
|
|
2015-06-22 14:03:28 +00:00
|
|
|
// -----------------------------------------------------------------------
|
|
|
|
// Sink interface
|
|
|
|
// -----------------------------------------------------------------------
|
2011-03-18 17:14:15 +00:00
|
|
|
|
2015-06-22 14:03:28 +00:00
|
|
|
// A type that decompresses into a Sink. The template parameter
|
|
|
|
// Allocator must export one method "char* Allocate(int size);", which
|
|
|
|
// allocates a buffer of "size" and appends that to the destination.
|
|
|
|
template <typename Allocator>
|
|
|
|
class SnappyScatteredWriter {
|
|
|
|
Allocator allocator_;
|
|
|
|
|
|
|
|
// We need random access into the data generated so far. Therefore
|
|
|
|
// we keep track of all of the generated data as an array of blocks.
|
|
|
|
// All of the blocks except the last have length kBlockSize.
|
|
|
|
vector<char*> blocks_;
|
|
|
|
size_t expected_;
|
|
|
|
|
|
|
|
// Total size of all fully generated blocks so far
|
|
|
|
size_t full_size_;
|
|
|
|
|
|
|
|
// Pointer into current output block
|
|
|
|
char* op_base_; // Base of output block
|
|
|
|
char* op_ptr_; // Pointer to next unfilled byte in block
|
|
|
|
char* op_limit_; // Pointer just past block
|
|
|
|
|
|
|
|
inline size_t Size() const {
|
|
|
|
return full_size_ + (op_ptr_ - op_base_);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SlowAppend(const char* ip, size_t len);
|
|
|
|
bool SlowAppendFromSelf(size_t offset, size_t len);
|
|
|
|
|
|
|
|
public:
|
|
|
|
inline explicit SnappyScatteredWriter(const Allocator& allocator)
|
|
|
|
: allocator_(allocator),
|
|
|
|
full_size_(0),
|
|
|
|
op_base_(NULL),
|
|
|
|
op_ptr_(NULL),
|
|
|
|
op_limit_(NULL) {
|
|
|
|
}
|
|
|
|
|
|
|
|
inline void SetExpectedLength(size_t len) {
|
|
|
|
assert(blocks_.empty());
|
|
|
|
expected_ = len;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool CheckLength() const {
|
|
|
|
return Size() == expected_;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return the number of bytes actually uncompressed so far
|
|
|
|
inline size_t Produced() const {
|
|
|
|
return Size();
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool Append(const char* ip, size_t len) {
|
|
|
|
size_t avail = op_limit_ - op_ptr_;
|
|
|
|
if (len <= avail) {
|
|
|
|
// Fast path
|
|
|
|
memcpy(op_ptr_, ip, len);
|
|
|
|
op_ptr_ += len;
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
return SlowAppend(ip, len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool TryFastAppend(const char* ip, size_t available, size_t length) {
|
|
|
|
char* op = op_ptr_;
|
|
|
|
const int space_left = op_limit_ - op;
|
|
|
|
if (length <= 16 && available >= 16 + kMaximumTagLength &&
|
|
|
|
space_left >= 16) {
|
|
|
|
// Fast path, used for the majority (about 95%) of invocations.
|
|
|
|
UNALIGNED_STORE64(op, UNALIGNED_LOAD64(ip));
|
|
|
|
UNALIGNED_STORE64(op + 8, UNALIGNED_LOAD64(ip + 8));
|
|
|
|
op_ptr_ = op + length;
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool AppendFromSelf(size_t offset, size_t len) {
|
|
|
|
// See SnappyArrayWriter::AppendFromSelf for an explanation of
|
|
|
|
// the "offset - 1u" trick.
|
|
|
|
if (offset - 1u < op_ptr_ - op_base_) {
|
|
|
|
const size_t space_left = op_limit_ - op_ptr_;
|
|
|
|
if (space_left >= len + kMaxIncrementCopyOverflow) {
|
|
|
|
// Fast path: src and dst in current block.
|
|
|
|
IncrementalCopyFastPath(op_ptr_ - offset, op_ptr_, len);
|
|
|
|
op_ptr_ += len;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return SlowAppendFromSelf(offset, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Called at the end of the decompress. We ask the allocator
|
|
|
|
// write all blocks to the sink.
|
|
|
|
inline void Flush() { allocator_.Flush(Produced()); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<typename Allocator>
|
|
|
|
bool SnappyScatteredWriter<Allocator>::SlowAppend(const char* ip, size_t len) {
|
|
|
|
size_t avail = op_limit_ - op_ptr_;
|
|
|
|
while (len > avail) {
|
|
|
|
// Completely fill this block
|
|
|
|
memcpy(op_ptr_, ip, avail);
|
|
|
|
op_ptr_ += avail;
|
|
|
|
assert(op_limit_ - op_ptr_ == 0);
|
|
|
|
full_size_ += (op_ptr_ - op_base_);
|
|
|
|
len -= avail;
|
|
|
|
ip += avail;
|
|
|
|
|
|
|
|
// Bounds check
|
|
|
|
if (full_size_ + len > expected_) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make new block
|
|
|
|
size_t bsize = min<size_t>(kBlockSize, expected_ - full_size_);
|
|
|
|
op_base_ = allocator_.Allocate(bsize);
|
|
|
|
op_ptr_ = op_base_;
|
|
|
|
op_limit_ = op_base_ + bsize;
|
|
|
|
blocks_.push_back(op_base_);
|
|
|
|
avail = bsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(op_ptr_, ip, len);
|
|
|
|
op_ptr_ += len;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename Allocator>
|
|
|
|
bool SnappyScatteredWriter<Allocator>::SlowAppendFromSelf(size_t offset,
|
|
|
|
size_t len) {
|
|
|
|
// Overflow check
|
|
|
|
// See SnappyArrayWriter::AppendFromSelf for an explanation of
|
|
|
|
// the "offset - 1u" trick.
|
|
|
|
const size_t cur = Size();
|
|
|
|
if (offset - 1u >= cur) return false;
|
|
|
|
if (expected_ - cur < len) return false;
|
|
|
|
|
|
|
|
// Currently we shouldn't ever hit this path because Compress() chops the
|
|
|
|
// input into blocks and does not create cross-block copies. However, it is
|
|
|
|
// nice if we do not rely on that, since we can get better compression if we
|
|
|
|
// allow cross-block copies and thus might want to change the compressor in
|
|
|
|
// the future.
|
|
|
|
size_t src = cur - offset;
|
|
|
|
while (len-- > 0) {
|
|
|
|
char c = blocks_[src >> kBlockLog][src & (kBlockSize-1)];
|
|
|
|
Append(&c, 1);
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
class SnappySinkAllocator {
|
|
|
|
public:
|
|
|
|
explicit SnappySinkAllocator(Sink* dest): dest_(dest) {}
|
|
|
|
~SnappySinkAllocator() {}
|
|
|
|
|
|
|
|
char* Allocate(int size) {
|
|
|
|
Datablock block(new char[size], size);
|
|
|
|
blocks_.push_back(block);
|
|
|
|
return block.data;
|
|
|
|
}
|
2011-03-18 17:14:15 +00:00
|
|
|
|
2015-06-22 14:03:28 +00:00
|
|
|
// We flush only at the end, because the writer wants
|
|
|
|
// random access to the blocks and once we hand the
|
|
|
|
// block over to the sink, we can't access it anymore.
|
|
|
|
// Also we don't write more than has been actually written
|
|
|
|
// to the blocks.
|
|
|
|
void Flush(size_t size) {
|
|
|
|
size_t size_written = 0;
|
|
|
|
size_t block_size;
|
|
|
|
for (int i = 0; i < blocks_.size(); ++i) {
|
|
|
|
block_size = min<size_t>(blocks_[i].size, size - size_written);
|
|
|
|
dest_->AppendAndTakeOwnership(blocks_[i].data, block_size,
|
|
|
|
&SnappySinkAllocator::Deleter, NULL);
|
|
|
|
size_written += block_size;
|
|
|
|
}
|
|
|
|
blocks_.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
struct Datablock {
|
|
|
|
char* data;
|
|
|
|
size_t size;
|
|
|
|
Datablock(char* p, size_t s) : data(p), size(s) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
static void Deleter(void* arg, const char* bytes, size_t size) {
|
|
|
|
delete[] bytes;
|
|
|
|
}
|
|
|
|
|
|
|
|
Sink* dest_;
|
|
|
|
vector<Datablock> blocks_;
|
|
|
|
|
|
|
|
// Note: copying this object is allowed
|
|
|
|
};
|
|
|
|
|
|
|
|
size_t UncompressAsMuchAsPossible(Source* compressed, Sink* uncompressed) {
|
|
|
|
SnappySinkAllocator allocator(uncompressed);
|
|
|
|
SnappyScatteredWriter<SnappySinkAllocator> writer(allocator);
|
|
|
|
InternalUncompress(compressed, &writer);
|
|
|
|
return writer.Produced();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Uncompress(Source* compressed, Sink* uncompressed) {
|
|
|
|
// Read the uncompressed length from the front of the compressed input
|
|
|
|
SnappyDecompressor decompressor(compressed);
|
|
|
|
uint32 uncompressed_len = 0;
|
|
|
|
if (!decompressor.ReadUncompressedLength(&uncompressed_len)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
char c;
|
|
|
|
size_t allocated_size;
|
|
|
|
char* buf = uncompressed->GetAppendBufferVariable(
|
|
|
|
1, uncompressed_len, &c, 1, &allocated_size);
|
|
|
|
|
|
|
|
// If we can get a flat buffer, then use it, otherwise do block by block
|
|
|
|
// uncompression
|
|
|
|
if (allocated_size >= uncompressed_len) {
|
|
|
|
SnappyArrayWriter writer(buf);
|
|
|
|
bool result = InternalUncompressAllTags(
|
|
|
|
&decompressor, &writer, uncompressed_len);
|
|
|
|
uncompressed->Append(buf, writer.Produced());
|
|
|
|
return result;
|
|
|
|
} else {
|
|
|
|
SnappySinkAllocator allocator(uncompressed);
|
|
|
|
SnappyScatteredWriter<SnappySinkAllocator> writer(allocator);
|
|
|
|
return InternalUncompressAllTags(&decompressor, &writer, uncompressed_len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
} // end namespace snappy
|