At Sat, 7 Nov 2020 16:42:43 +0100, Dominik Pantůček wrote: > 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?
I'm not sure I understand what you mean, but I don't think unsafe operations are particularly helpful for unboxing hints. Let's separate out safety checks from unboxing. For safety checks, I'd put the unsafe flonum operations into two categories: * `fl+`, `fl-`, etc., where the only relevant check is whether an argument is a flonum --- In this case, the benefits of unsafe variants are small to nothing. Depending on context, the compiler can often infer that the arguments are definitely flonums, so the generated code is the same. It's only when the compiler cannot infer flonumness that an unsafe variant has any performance advantage, and then it's just skipping a type-tag check. * `flvector-ref` and `flvector-set!` --- In these cases, there's an array-bounds requirement that is well beyond the reach of the compiler to infer. So, there will be a check on every use of the safe variants in a loop, for example. The check also requires more instructions than checking flonumness, so it's easier to see some speedup with unsafe variants of these operations. Unboxing is a bigger deal for performance than safety checks, though, and unboxing is completely driven by what the compiler can infer. Using unsafe operations provides no more or less information to the compiler's unboxing inference than safe operations do. Matthew -- 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/20201107145933.fe%40sirmail.smtps.cs.utah.edu.
