Wow, you are faster than I :) On 07. 11. 20 15:36, Matthew Flatt wrote: > At Fri, 6 Nov 2020 12:45:46 -0700, Matthew Flatt wrote: >> I will investigate faster option. A primitive without conversion could >> make the safe `flvector-set!` slightly faster, too, by avoiding a >> redundant check. > > Long story short, I added flvectors to the Chez Scheme level as of > v7.9.0.4. With that change, `flvector-set!` is faster, and > `flvector-ref` and `flvector-set!` cooperate better with flonum > unboxing.
Ok, I originally wanted to reply to your original remark about unsafe/safe flonum operations, but this actually extends my questions. My current understanding is that the best performance you get from unsafe operations while using safe operations as hints for the flonum unboxing algorithm, right? So with flvectors it is now the same? When I convey some safe hint to the unboxing code, is it the best (in terms of performance) to use unsafe flvector procedures then? To be honest, when I try to write down "definitive" rules how to structure the code (mainly tight loops) and use safe/unsafe operations properly, I get quickly lost. I'll do some empirical benchmarks and see whether I can get some generally valid answer. > > For example, this microbenchmark now avoids allocation and runs about 8 > times as fast: > > (let ([v (make-flvector 100)]) > (time > (for ([j (in-range 100000)]) > (for ([i (in-range (flvector-length v))]) > (flvector-set! v i (fl+ 1.0 (flvector-ref v i))))))) I was just about to ask. This is how most of my code looks right now (albeit more complex and with very short flvectors - 3 or 9 elements mostly). I'll test the new implementation and see if there is a difference. > > Also, your program now crashes as you intended. > Aweseome! (May sound weird, but I really like consistent behavior). > > (To make room in Chez Scheme's type encoding for flvectors, I removed > immutable fxvectors. Immutable fxvectors do not seem useful, and > there's no such thing at the Racket level.) There definitely are scenarios, where immutable fxvectors may be a good idea. However in those scenarios, allocations ruin the performance most of the time. And although CS performs way better with extensive box allocations than BC, it can still quickly become a noticeable bottleneck. Dominik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/e6f12dab-7996-9479-2cc1-85422d9b6587%40trustica.cz.
