Re: [hybi] Performance of Vector XOR

"Len Holgate" <len.holgate@gmail.com> Wed, 07 September 2011 20:40 UTC

Return-Path: <len.holgate@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097021F8C40 for <hybi@ietfa.amsl.com>; Wed, 7 Sep 2011 13:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6-1JJismA2D for <hybi@ietfa.amsl.com>; Wed, 7 Sep 2011 13:40:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C739521F8C34 for <HYBI@ietf.org>; Wed, 7 Sep 2011 13:40:46 -0700 (PDT)
Received: by wwf5 with SMTP id 5so42098wwf.13 for <HYBI@ietf.org>; Wed, 07 Sep 2011 13:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=6EB2+GbjjyL/nHVewgQnsgyLManS3b7CyDqgFjIFrzk=; b=fd57IDEgPz87RJAmDer951YQk6RbVBr+OH+k7Ro5Ykwu3+SYzqbFk6L6KqHHN4H5NK vi5+m2lJLfy2JW1kEes9FauMETiPiBS990ogRaaiy0KtgxPbNR9DSjAn0Bc7g9Ja9r/8 S04tJgsgtRK28M7yhOGG3T6yLmopy8lf8Em38=
Received: by 10.227.3.4 with SMTP id 4mr2537133wbl.35.1315428156060; Wed, 07 Sep 2011 13:42:36 -0700 (PDT)
Received: from Venus (cpc6-glfd6-2-0-cust182.6-2.cable.virginmedia.com [80.5.71.183]) by mx.google.com with ESMTPS id fq9sm1822220wbb.15.2011.09.07.13.42.34 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:42:35 -0700 (PDT)
From: Len Holgate <len.holgate@gmail.com>
To: 'Bob Gezelter' <gezelter@rlgsc.com>, 'Tobias Oberstein' <tobias.oberstein@tavendo.de>, rbarnes@bbn.com
References: <20110907133128.ef1fc80126c74c6c202a919c41c7bb0b.a42c8f016b.wbe@email03.secureserver.net>
Date: Wed, 07 Sep 2011 21:42:19 +0100
Message-ID: <193e01cc6d9e$a4025b60$0a00a8c0@Venus>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20110907133128.ef1fc80126c74c6c202a919c41c7bb0b.a42c8f016b.wbe@email03.secureserver.net>
Thread-Index: AcxtnS2loFWkglshTbmdWiCzr7rcnwAAR81Q
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
Cc: HYBI@ietf.org
Subject: Re: [hybi] Performance of Vector XOR
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 20:40:48 -0000

Bob,

I don't have any concerns over the performance of the xor. My code is all
c++ and the performance is fine right now.

I'd just like the spec to say what's allowed and what isn't so that I can
nail my API down... No point in allowing optional server->client masking
clients will all assume it's not allowed.

Len
http://www.serverframework.com

> -----Original Message-----
> From: Bob Gezelter [mailto:gezelter@rlgsc.com] 
> Sent: 07 September 2011 21:31
> To: len.holgate@gmail.com; Tobias Oberstein; rbarnes@bbn.com
> Cc: HYBI@ietf.org
> Subject: Performance of Vector XOR
> 
> Len, Tobias, Richard,
> 
> I would recommend extreme caution on using rough JavaScript or even
> Python benchmarks as a test for the execution efficiency of 
> the masking
> operation (Note: I say this as one who is unconvinced of the 
> benefits of
> masking).
> 
> A well-written, straight vector XOR of a message should not be an
> extremely expensive operation. I would be loath to believe that modern
> processors cannot effectively perform this operation. With all due
> respect to the implementers, it is far more likely that the JavaScript
> (and quite possibly Python) use data structures and 
> representations that
> were not designed for this type of vector operation.
> 
> In a real situation, the XOR would be done in code that is likely
> written in C/C++ or a similar language. If there is a real concern on
> this issue, then the analysis should be done at the level of precisely
> what machine instructions are actually being executed. As a 
> former code
> generator writer, I can attest that it is quite easy to gain or lose
> efficiency at this level (for example, I would be unsurprised to
> discover that JavaScript and Python are doing the XOR one byte at a
> time, rather than in 64-bit chunks; that alone would account 
> for nearly
> an order of magnitude performance hit).
> 
> - Bob Gezelter, http://www.rlgsc.com
> 
>