FAQ
I just printed a histogram of the lengths, it seems that the files that
perform poorly have an order of magnitude more lengths 4 and below than any
other (I didn't know that snappy allows lengths < 4).

I also tried the dual version, with L=8, O=0:
BenchmarkWordsDecode1e1-4 409.04 402.39 0.98x
BenchmarkWordsDecode1e2-4 413.11 396.93 0.96x
BenchmarkWordsDecode1e3-4 501.41 487.86 0.97x
BenchmarkWordsDecode1e4-4 332.99 309.59 0.93x
BenchmarkWordsDecode1e5-4 256.14 256.74 1.00x
BenchmarkWordsDecode1e6-4 277.36 277.56 1.00x
Benchmark_UFlat0-4 533.12 735.90 1.38x
Benchmark_UFlat1-4 428.48 479.35 1.12x
Benchmark_UFlat2-4 13939.92 13586.29 0.97x
Benchmark_UFlat3-4 836.60 697.90 0.83x
Benchmark_UFlat4-4 2848.84 5326.47 1.87x
Benchmark_UFlat5-4 520.65 691.76 1.33x
Benchmark_UFlat6-4 263.59 261.69 0.99x
Benchmark_UFlat7-4 254.36 258.57 1.02x
Benchmark_UFlat8-4 272.94 275.24 1.01x
Benchmark_UFlat9-4 248.50 245.86 0.99x
Benchmark_UFlat10-4 636.17 1051.09 1.65x
Benchmark_UFlat11-4 340.62 361.82 1.06x

Yea, I agree that the using builtin-copy doesn't seem to provide
significant gains for snappy.
On Wednesday, March 2, 2016 at 8:59:10 PM UTC-8, Nigel Tao wrote:

On Thu, Mar 3, 2016 at 3:29 PM, Nigel Tao <nige...@golang.org
<javascript:>> wrote:
Perhaps the copy lengths are usually so small that the overhead of
calling runtime.memmove isn't worth it. Perhaps it's something else.
I suppose that you could rig it so that you choose:

if length < L || offset < O {
use basic "dst[d] = dst[d-offset]" loop
} else {
use fancier builtin-copy-based loop
}

for some magic numbers L and O, but at least on amd64, that still
doesn't get close to the asm version, and it's not obvious that
whatever a good L and O is for one CPU is necessarily good for
another. I'm open to arguments to the contrary, but I'm not convinced
that it's worth making the decode_other.go simple implementation that
little bit more complicated. If, in the future, we also need e.g. a
really fast arm implementation, I'd be inclined to write an arm asm
version, again bypassing the decode_other.go version.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 23 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedFeb 26, '16 at 7:36a
activeApr 24, '16 at 12:39a
posts23
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase