Smalltalk › Squeak › Squeak - Dev

ByteArray implements #hash but not #=

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Martin Kuball

ByteArray implements #hash but not #=

Hi!

I'm just wondering why #= is not implemented in class ByteArray. Wouldn't
it make sense to have a fast primitive for that instead of using the
general implementation in class SequenceableCollection?

Martin

Ron Teitelbaum

RE: ByteArray implements #hash but not #=

Hi Martin,

I dunno I've never noticed a performance problem with ByteArray #=.

| aCopy |
aCopy := self copy.

Time millisecondsToRun: [
1 to: 1000 do: [:i | self = aCopy]]

I took a 128 element byte array and ran #= a thousand times and the results
were only 14ms. The comparison time seems linear but I'm not 100% sure
about that. 500 calls gives me 7ms.

Ok so for the fun of it I did the same thing with War and Peace by Leo
Tolstoy. A single comparison took 340ms. 100 times took: 34223. That's
pretty linear.

Most of the work we do in the cryptography team is on small byteArrays so it
would be very important that we do not lose speed there from any changes in
implementation.

Ron Teitelbaum
Squeak Cryptography Team Leader

> From: Martin Kuball
> Sent: Sunday, February 25, 2007 8:27 AM
> Hi!
>
> I'm just wondering why #= is not implemented in class ByteArray. Wouldn't
> it make sense to have a fast primitive for that instead of using the
> general implementation in class SequenceableCollection?
>
> Martin
>

Ron Teitelbaum

RE: ByteArray implements #hash but not #=

Ok so I just realized that was not a very good way to test liner time. But
I tried war and peace / 2 and got 170ms. That's a better test then trying
the same thing 100 times.

Ron Teitelbaum
Squeak Cryptography Team Leader

> From: Ron Teitelbaum
> Sent: Sunday, February 25, 2007 2:10 PM
>
> Hi Martin,
>
> I dunno I've never noticed a performance problem with ByteArray #=.
>
> | aCopy |
> aCopy := self copy.
>
> Time millisecondsToRun: [
> 1 to: 1000 do: [:i | self = aCopy]]
>
> I took a 128 element byte array and ran #= a thousand times and the
> results
> were only 14ms. The comparison time seems linear but I'm not 100% sure
> about that. 500 calls gives me 7ms.
>
> Ok so for the fun of it I did the same thing with War and Peace by Leo
> Tolstoy. A single comparison took 340ms. 100 times took: 34223. That's
> pretty linear.
>
> Most of the work we do in the cryptography team is on small byteArrays so
> it
> would be very important that we do not lose speed there from any changes
> in
> implementation.
>
> Ron Teitelbaum
> Squeak Cryptography Team Leader
>
> > From: Martin Kuball
> > Sent: Sunday, February 25, 2007 8:27 AM
> > Hi!
> >
> > I'm just wondering why #= is not implemented in class ByteArray.
> Wouldn't
> > it make sense to have a fast primitive for that instead of using the
> > general implementation in class SequenceableCollection?
> >
> > Martin
> >
>
>
>

Bryce Kampjes

RE: ByteArray implements #hash but not #=

In reply to this post by Ron Teitelbaum

Ron Teitelbaum writes:

> Most of the work we do in the cryptography team is on small byteArrays so it
> would be very important that we do not lose speed there from any changes in
> implementation.

It would be easy to extend Exupery to be able to compile that method
well. It's just SmallInteger arithmetic, ByteArray>>at: (not yet
handled), and species.

I've talked a little to Martin about crypto, handling the byte based
algorithms should be fairly easy. The word based ones will be harder
but still very possible.

The trick to compile word based algorithms efficiently is to avoid
generating objects for intermediate words. It's basically the same
problem as compiling floats without any overhead. But fast full word
compilation is definitely something that would have to wait until
after 1.0 unless someone else would like to work on it.

It would be nice to work with the crypto team after the next release
or two if you like the idea of compiling Smalltalk rather than writing
primitives to provide speed.

Bryce

Ron Teitelbaum

RE: ByteArray implements #hash but not #=

Hi Bryce,

We would definitely be interested in working with you. We have noticed that
we need to do most crypto algorithms via plugin's because of the 32 bit word
manipulation performance. It would be interesting if we could get results
similar to the plugin from compiled implementations. Most all the word
manipulation goes through ThirtyTwoBitRegister so I wonder if it would be
possible to rewrite it as a hander for the math instead and prevent object
creation that way. I'm sure it would be an interesting conversation.
Please feel free to join the team at any time; we would love to have you!

By the way we still need some Crypto plugin's done in slang if anyone has
time and would like to work on or learn Crypto! Anyone anyone?

Ron Teitelbaum
Squeak Cryptography Team Leader

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Tuesday, February 27, 2007 5:22 PM
> To: [hidden email]; The general-purpose Squeak developers list
> Subject: RE: ByteArray implements #hash but not #=
>
> Ron Teitelbaum writes:
>
> > Most of the work we do in the cryptography team is on small byteArrays
> so it
> > would be very important that we do not lose speed there from any
> changes in
> > implementation.
>
> It would be easy to extend Exupery to be able to compile that method
> well. It's just SmallInteger arithmetic, ByteArray>>at: (not yet
> handled), and species.
>
> I've talked a little to Martin about crypto, handling the byte based
> algorithms should be fairly easy. The word based ones will be harder
> but still very possible.
>
> The trick to compile word based algorithms efficiently is to avoid
> generating objects for intermediate words. It's basically the same
> problem as compiling floats without any overhead. But fast full word
> compilation is definitely something that would have to wait until
> after 1.0 unless someone else would like to work on it.
>
> It would be nice to work with the crypto team after the next release
> or two if you like the idea of compiling Smalltalk rather than writing
> primitives to provide speed.
>
> Bryce