Harvey J. Stein wrote: > > It's now faster than the slowest C code, but the slowest one generates > 53 bits of randomness in doubles by using 2 32 bit random numbers > generated from the Mersenne twister random number generator. cmucl > seems to be using the same generator, but is probably only putting 32 > bits of randomness into each double, so probably should be compared to > the 2.8 second run, but I'll have to check. If that is the case, > that makes it ~20% slower.
I checked the code. CMUCL generates 2 32-bit chunks and smashes them together to make a double-float. > > Now we've gotten within 10%. But, can someone clarify what > maybe-inline does? It looks like it makes the specified functions All I know about maybe-inline is explained in the manual. The functions aren't inlined unless space = 0, or you declare them inline. > available as local calls. Is this the only function of it? Does this > also mean that when they're redefined, the redefinition won't affect > code that was compiled and loaded prior to redefinition? Most I believe this is true. If they've been inlined, you need to recompile the caller to see the new function. As expected. > importantly, why did it end up being faster than inline? Don't know. Cache issues? But with your declaim's, shouldn't they have all been inlined? > > It seems like declarations can get rid of boxing and unboxing inside > of functions, but in general not across function calls, unless > functions are inlined, maybe-inlined, or block compiled. Is this the > case? That's my limited understanding. > > If so, it would be nice to be able to tell the compiler that a > particular function can be redefined, but it's always going to return > a double-float, so don't bother boxing and unboxing the result. > Similarly for function arguments. This would be something lighter > weight than the above methods, but more flexible, while potentially > giving just as much optimization. Alternatively, the function itself > can be compiled with arguments and returns unboxed, with the function > calls themselves doing the boxing and unboxing if necessary. This > would be like hoisting the unboxing out of the function. Any thoughts > on the viability of such an extension? I think that's possible, but I suspect no one currently has the time and skill to do it. :-( Ray
