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 > >
- [hybi] Performance of Vector XOR Bob Gezelter
- Re: [hybi] Performance of Vector XOR Len Holgate
- Re: [hybi] Performance of Vector XOR Tobias Oberstein
- Re: [hybi] Performance of Vector XOR Bob Gezelter
- Re: [hybi] Performance of Vector XOR Brian McKelvey
- Re: [hybi] Performance of Vector XOR IƱaki Baz Castillo