Subject: [hybi] Performance of Vector XOR

From: "Bob Gezelter" <[email-masked]>
Date: Wed, 07 Sep 2011 13:31:28 -0700

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

---

From: "Len Holgate" <[email-masked]>
Date: Wed, 7 Sep 2011 21:42:19 +0100

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:[email-masked]] 
> Sent: 07 September 2011 21:31
> To: [email-masked]; Tobias Oberstein; [email-masked]
> Cc: [email-masked]
> Subject: Performance of Vector XOR
> 
> Len, Tobias, Richard,
>

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 7 Sep 2011 13:47:38 -0700

Bob,

my comment wasn't to question masking, and XOR is probably as light-weight
as it gets.

It was also not about how great a tool Python is for bit banging - it isn't;)

And yes, I'd probably use stuff like GCC SIMD intrinsics to get the XOR
really fly .. in C/C++.

Personally, I'm suprised how good Google V8 is a JITting.

I would be interested in 2 more data points:

* LuaJIT2 .. this could trump v8. It's insanely fast, and has special bit ops. handrolled.
* gcc intrinsics as a base line

and
* Java/C#

 ... with the latter since those might also not be the greatest for bit banging,
and there might be no cheap escape route to C.

With Python, if I had more time, I'd probably write a minimal
WS accelerator native module that does just

* XOR
* incr. UTF-8 validation

Those 2 are the pain points.

Cheers,
Tobias

> -----Ursprüngliche Nachricht-----
> Von: Bob Gezelter [mailto:[email-masked]]
> Gesendet: Mittwoch, 7. September 2011 22:31
> An: [email-masked]; Tobias Oberstein; [email-masked]
> Cc: [email-masked]
> Betreff: Performance of Vector XOR
> 
> Len, Tobias, Richard,
> 
> 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).
>

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 7 Sep 2011 15:27:45 -0700

It is quite impressive.  As I understand it, it has special optimizations for bitwise operations and representing numbers internally as int32 if possible when dealing with integer arithmetic, rather than as the 64-bit floating point format specified by ECMA-262 for all numbers.

Brian

Sent from my iPhone

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 8 Sep 2011 12:12:22 +0200

> WS accelerator native module that does just

In my WS server (Ruby language) I've got a 400% of efficience by
coding a Ruby C extension for the unmasking process:

http://oversip.net/public/oversip/websocket-autobahn-results/

-- 
Iñaki Baz Castillo
<[email-masked]>