On Sep 23, 2010, at 8:16 PM, Matthew Flatt wrote:

> One more thought: Do you get to pick whether you use 16-bit integers or
> 64-bit floating-point numbers? The `flvector-' and `f64vector-'
> operations are inlined by the JIT and recognized for unboxing, so using
> flonum vectors and operations could be much faster than using raw
> pointers and 16-bit integers.

Well, that's an option, albeit a somewhat unappetizing one; as the 44100 in my 
code no doubt signaled, I'm reading and writing sound data here, and both 
16-bit ints and 32-bit floats are fairly common. 64-bit floats will be another 
factor of 2 in memory, for a total of 42 megabytes per minute.

I ran some tests, using flvectors and unsafe operations everywhere. (Code 

My tests called for 400 seconds of audio, or 282 Megabytes, and this made 
DrRacket flustered.  Restarting and running with half that size yielded (quite 
variable) times between 1 and 3 seconds, so that appears about twice as fast as 
the fixed-point one.

I'm tempted to write a little C code, but then of course I have to compile it 
separately for every darn platform.

Thanks again for your help,


#lang racket

(require ffi/unsafe

(define (make-buffer-of-small-randoms len)
  (let ([buf (make-flvector len)])
    (for ([i (in-range len)])
      (unsafe-flvector-set! buf i 0.73))

(define buf-len (* 44100 2 100))

(define b1 (make-buffer-of-small-randoms buf-len))
(define b2 (make-buffer-of-small-randoms buf-len))

 (for ([i (in-range buf-len)])
   (unsafe-flvector-set! b1 i
                         (unsafe-fl+ (unsafe-flvector-ref b1 i)
                                     (unsafe-flvector-ref b2 i)))))

Attachment: smime.p7s
Description: S/MIME cryptographic signature

  For list-related administrative tasks:

Reply via email to