All of lore.kernel.org
 help / color / mirror / Atom feed
From: Loic Dachary <loic@dachary.org>
To: Andreas-Joachim Peters <andreas.joachim.peters@cern.ch>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Caching the erasure code decoding matrix
Date: Sun, 07 Jun 2015 00:42:22 +0200	[thread overview]
Message-ID: <5573774E.9010105@dachary.org> (raw)
In-Reply-To: <55511543.3040603@dachary.org>

[-- Attachment #1: Type: text/plain, Size: 2144 bytes --]

Hi Andreas,

After discussing this a little with a few people, I'm tempted to conclude caching the decoding matrix is probably not worth the complexity. It's even difficult for me to know if maintaining the cache is cheaper than computing the decoding matrix.

Cheers

On 11/05/2015 22:46, Loic Dachary wrote:
> Hi Andreas,
> 
> I gave a shot at implementing a cache to avoid computing the decoding matrix every time a 4KB stripe needs it, for the jerasure plugin, in the same way you did it for the ISA plugin. 
> 
> The draft is at https://github.com/dachary/ceph/commit/a6fb5257fabd810704405c8bc13743d1592ecc54 if you're curious. Then I did some benchmarking and was quite disappointed. It looks like whenever the matrix needs to be computed jerasure_invert_matrix needs ~4000 cycles. Compared to the cost of galois_w08_region_multiply (~4 millions cycles), it is very small [1].
> 
> With the ISA plugin ec_init_table is less expensive than jerasure_invert_matrix with ~1200 cycles as well as the the function ec_encode_data_avx (1.5 millions cycles) [2].
> 
> In both cases though the order of magnitude remains (1000 to 1) and makes me wonder if I'm not missing something.
> 
> What do you think ?
> 
> Cheers
> 
> [1] jerasure profiling: make -j4 ceph_erasure_code_benchmark && rm bench.callgrind &&  valgrind --tool=callgrind --callgrind-out-file=bench.callgrind      ./ceph_erasure_code_benchmark      --plugin jerasure      --parameter directory=.libs --workload decode --verbose      --parameter technique=reed_sol_van      --parameter k=4      --parameter m=2      --iterations 1024 --erased 1 --erased 2 && kcachegrind bench.callgrind 
> [2] isa profiling: make -j4 ceph_erasure_code_benchmark && rm bench.callgrind &&  valgrind --tool=callgrind --callgrind-out-file=bench.callgrind      ./ceph_erasure_code_benchmark      --plugin isa      --parameter directory=.libs --workload decode --verbose      --parameter technique=reed_sol_van      --parameter k=4      --parameter m=2      --iterations 1024 --erased 1 --erased 2 && kcachegrind bench.callgrind 
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2015-06-06 22:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 20:46 Caching the erasure code decoding matrix Loic Dachary
2015-06-06 22:42 ` Loic Dachary [this message]
2015-06-07 12:30   ` Andreas Joachim Peters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5573774E.9010105@dachary.org \
    --to=loic@dachary.org \
    --cc=andreas.joachim.peters@cern.ch \
    --cc=ceph-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.