[Openmcl-devel] how does one cause stack-allocation for floats? [2]

[james anderson]

hello again;

thank you for your note.

i agree with the sentiment, but it's not very satisfying.

let me see if i can reframe this.

i know that it is not good form to slip notes under the table to the  
compiler to cajole it into doing the right thing.
on the other hand, some annotation is necessary, since, without the  
benefit of global analysis, only the application writer will know  
that, in the end, it's just fine to do the whole thing in registers.  
yes, i would like to have annotation sufficient to achieve beer's  
floating-point efficiency, but i would like the directives to be  
understood by any standard lisp. maybe ansi will reconvene one day.  
maybe they will admit that a "register" declaration is not  
unmitigated evil. until then i am limited to dynamic-extent.

yes, i have trashed zero and had to figure out how to reconstruct it.  
that's life.

conscious of which, if i just gather together the results, with a  
count of 10000000, from lisps i have at hand, they look like this:
(results are | total milliseconds . gc milliseconds .  byes consed | )

----------------------|    single-float     | single/stack  | double- 
float        | double/stack     |
allegro 6.2 / P4-2.8G | 4484 . 3436 . 320MB | 406 . 0 . 496 | 6562 .  
4638 . 480MB | 406 .  0 .  24   |
open-mcl 1.0/ G5-2.5G |  655 .    0 .   0   | 421 . 0 .   0 |   
932 .   28 . 320MB | 819 . 27 . 320MB |
mcl         / G5-2.5G | 4098 .  547 . 160MB | 320 . 8 .  24 | 7844 .   
305 . 320MB | 361 .  0 .  16   |
cmucl 19c   / G5-2.5G |   70 .    0 .  24   |  60 . 0 .   0 |   
280 .    0 .  32   |   7 .  0 .  32   |
----------------------|---------------------|---------------|----------- 
----------|------------------|
cmucl-only double w/o declarations                           11050 .   
350 . 320MB

(whereby the gc figures are intra-runtime only, as the heap sizes  
vary widely)
these reveal open-mcl's dark secret in the relatively small  
difference between 819 and 932.
they also imply that cmucl knows even more secrets: the type  
declarations alone accomplish a lot.
despite which, the differences between 361 and 819 and between 320MB  
and 16, and between 280 and 7 will sometimes contribute to whether a  
process completes in time or not.

what is wrong with letting the program specify that it wants scratch  
storage?

would it not be the right thing to support (declare (register result))?
it would avoid the (= 0.0 pi) problem. no?

...