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 below.) 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, John #lang racket (require ffi/unsafe racket/flonum racket/unsafe/ops) (define (make-buffer-of-small-randoms len) (let ([buf (make-flvector len)]) (for ([i (in-range len)]) (unsafe-flvector-set! buf i 0.73)) buf)) (define buf-len (* 44100 2 100)) (define b1 (make-buffer-of-small-randoms buf-len)) (define b2 (make-buffer-of-small-randoms buf-len)) (time (for ([i (in-range buf-len)]) (unsafe-flvector-set! b1 i (unsafe-fl+ (unsafe-flvector-ref b1 i) (unsafe-flvector-ref b2 i)))))
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev