Re: [openpgp] AEAD Chunk Size - Performance

"Neal H. Walfield" <neal@walfield.org> Thu, 28 February 2019 08:38 UTC

Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D743130EFC for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSf26cJtB6YJ for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:38:40 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B05130E68 for <openpgp@ietf.org>; Thu, 28 Feb 2019 00:38:40 -0800 (PST)
Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1gzHDB-00089F-Ae; Thu, 28 Feb 2019 08:38:37 +0000
Date: Thu, 28 Feb 2019 09:38:36 +0100
Message-ID: <87k1hk2tpv.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Bart Butler <bartbutler@protonmail.com>
Cc: Vincent Breitmoser <look@my.amazin.horse>, "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com>
References: <87mumh33nc.wl-neal@walfield.org> <F9VLV9HZWH.3RYL3UM3BN873@my.amazin.horse> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/2ycyN1-uI6ABn277XzK5pvlkp00>
Subject: Re: [openpgp] AEAD Chunk Size - Performance
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 08:38:53 -0000

Hi Bart,

Thanks for your feedback.

On Wed, 27 Feb 2019 22:34:09 +0100,
Bart Butler wrote:
> In our AEAD implementation for OpenPGP.js we settled on a default
> `c` of 12 rather than 8 after some performance benchmarking showed
> that 256 kiB chunks were more performant for the most common message
> sizes. Our result was specific to the web crypto API, and therefore
> specific to OpenPGP.js, but in general libraries may want to use
> different default sizes depending on implementation details like
> this.

I don't need exact numbers, but I'd appreciate it if you could you
comment on the approximate performance of 256 kiB chunks relative to
16 kiB chunks (e.g., factor 1.2 speedup).  Of course, if you still
have the numbers lying around, that would be even better!


There are two reasons that I find 16 kiB *intuitively* appealing from
a performance perspective: a typical L2 cache is about 256 kiB these
days.  So a 16 kiB buffer has a good chance of staying completely in
L2.  Second, on all desktop and mobile operating systems, it is almost
always reasonable to stack allocate a 16 kiB buffer whereas 256 kiB is
a bit big.

From a robustness perspective, I'd like to avoid introducing a
threshold and having to do something brittle like:

  void *buffer;
  if size > 16 kiB {
    buffer = malloc(size);
  } else {
    buffer = alloca(size);
  }

  ...

  if size > 16 kiB {
    free(buffer);
  }

Unfortunately, I haven't benchmarked this type of thing in the context
of AEAD so this is just drawing from my limited prior experience with
sizing these sorts of things.

:) Neal