Re: [racket-dev] bit-vectors and serialization

[Pierpaolo Bernardi]

On Mon, Dec 17, 2012 at 10:35 PM, Ryan Culpepper  wrote:

> True, popcount takes about three times as long as it used to. With a few
> additional changes, popcount on a million-bit bit-vector takes 1.1 ms using
> bytes, as opposed to 0.35 ms using fxvectors. (Tested on a 64-bit machine.)

I seem to understand that popcount still uses the same trick as the
fixnum version?

Have you tried using a byte-vector of 256 precomputed values for each
byte value?

P.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] bit-vectors and serialization

[Ryan Culpepper]

On 12/17/2012 04:30 AM, Jens Axel Søgaard wrote:

2012/12/17 Ryan Culpepper :

I'd like to make bit-vectors serializable so I can replace sql-bits with
them. I'll deprecate the current sql-bits names but keep them around for a
while.

The issue is that bit-vectors are implemented using fxvectors, which are
serializable, but simply serializing them will presumably cause errors if a
bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit
machine or vice versa.

One solution would be to use bytes instead of fxvectors. The performance is
about the same as far as I could tell using the sieve benchmark.

Another option is to declare that serialization across word sizes doesn't
work for bit vectors.

Any opinions?


The sieve-benchmark works on individual bits, so it makes sense that
the performance is about the same. What happens for operations that
work on words (e.g. the popcount operation)? My intuition is that
these operations will be slower.


True, popcount takes about three times as long as it used to. With a few 
additional changes, popcount on a million-bit bit-vector takes 1.1 ms 
using bytes, as opposed to 0.35 ms using fxvectors. (Tested on a 64-bit 
machine.)


Ryan

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] bit-vectors and serialization

[Jens Axel Søgaard]

2012/12/17 Ryan Culpepper :
> I'd like to make bit-vectors serializable so I can replace sql-bits with
> them. I'll deprecate the current sql-bits names but keep them around for a
> while.
>
> The issue is that bit-vectors are implemented using fxvectors, which are
> serializable, but simply serializing them will presumably cause errors if a
> bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit
> machine or vice versa.
>
> One solution would be to use bytes instead of fxvectors. The performance is
> about the same as far as I could tell using the sieve benchmark.
>
> Another option is to declare that serialization across word sizes doesn't
> work for bit vectors.
>
> Any opinions?

The sieve-benchmark works on individual bits, so it makes sense that
the performance is about the same. What happens for operations that
work on words (e.g. the popcount operation)? My intuition is that
these operations will be slower.

An alternative to switching to bytevectors is to write a pair of functions
bit-vector->integer and integer->bit-vector and simply serialize the
bit-vector as an integer.

/Jens Axel
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] bit-vectors and serialization

[Neil Toronto]

I'd call it an error if something couldn't be correctly serialized and 
deserialized between platforms.


Neil ⊥

On 12/16/2012 05:22 PM, Robby Findler wrote:

If there's no significant performance penalty, then I'd say that we
should make things work between 32bit and 64bit builds.

(If there is a performance penalty then I'd still want to try to achieve
that, at least.)

Robby


On Sun, Dec 16, 2012 at 6:18 PM, Ryan Culpepper mailto:r...@cs.utah.edu>> wrote:

I'd like to make bit-vectors serializable so I can replace sql-bits
with them. I'll deprecate the current sql-bits names but keep them
around for a while.

The issue is that bit-vectors are implemented using fxvectors, which
are serializable, but simply serializing them will presumably cause
errors if a bit-vector is serialized on a 64-bit machine and
deserialized on a 32-bit machine or vice versa.

One solution would be to use bytes instead of fxvectors. The
performance is about the same as far as I could tell using the sieve
benchmark.

Another option is to declare that serialization across word sizes
doesn't work for bit vectors.

Any opinions?

Ryan
_
  Racket Developers list:
http://lists.racket-lang.org/__dev 




_
   Racket Developers list:
   http://lists.racket-lang.org/dev



_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] bit-vectors and serialization

[Robby Findler]

If there's no significant performance penalty, then I'd say that we should
make things work between 32bit and 64bit builds.

(If there is a performance penalty then I'd still want to try to achieve
that, at least.)

Robby


On Sun, Dec 16, 2012 at 6:18 PM, Ryan Culpepper  wrote:

> I'd like to make bit-vectors serializable so I can replace sql-bits with
> them. I'll deprecate the current sql-bits names but keep them around for a
> while.
>
> The issue is that bit-vectors are implemented using fxvectors, which are
> serializable, but simply serializing them will presumably cause errors if a
> bit-vector is serialized on a 64-bit machine and deserialized on a 32-bit
> machine or vice versa.
>
> One solution would be to use bytes instead of fxvectors. The performance
> is about the same as far as I could tell using the sieve benchmark.
>
> Another option is to declare that serialization across word sizes doesn't
> work for bit vectors.
>
> Any opinions?
>
> Ryan
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] bit-vectors and serialization

[Ryan Culpepper]

I'd like to make bit-vectors serializable so I can replace sql-bits with 
them. I'll deprecate the current sql-bits names but keep them around for 
a while.


The issue is that bit-vectors are implemented using fxvectors, which are 
serializable, but simply serializing them will presumably cause errors 
if a bit-vector is serialized on a 64-bit machine and deserialized on a 
32-bit machine or vice versa.


One solution would be to use bytes instead of fxvectors. The performance 
is about the same as far as I could tell using the sieve benchmark.


Another option is to declare that serialization across word sizes 
doesn't work for bit vectors.


Any opinions?

Ryan
_
 Racket Developers list:
 http://lists.racket-lang.org/dev