[plt-scheme] Statistics (V301.5 Speed Up)

Does it make any sense to attempt to attach optimizations to the use of
contracts?  I realize that might not be their intended usage, but some of
the same typing information is included there.

I suspect that just having the float operators would speed up the science
collection considerably, for example.

Doug

> -----Original Message-----
> From: plt-scheme-bounces at list.cs.brown.edu [mailto:plt-scheme-
> bounces at list.cs.brown.edu] On Behalf Of Will M. Farr
> Sent: Tuesday, February 14, 2006 11:31 AM
> To: PLT Scheme
> Subject: Re: [plt-scheme] Statistics (V301.5 Speed Up)
> 
> Hello,
> On 14 Feb 2006, at 11:20 AM, Alexander Friedman wrote:
> 
> >> - generic arithmetic preventing arithmetic optimizations (not that
> >> anybody really knows how to fix this)
> >
> > Yes. I don't see any obvious way to fix this either.
> 
> As someone who uses Scheme to do pretty heavy-duty numerical
> simulations, could I put in a request for some fl+ fl- fl* fl/, etc
> operators?  (These are already in the SRFI with proposed R6RS
> arithmetic.)  I realize that this solution to the generic arithmetic
> problem is not perfect, but if the typechecks and boxing/unboxing
> operations associated with these operators were compiled in the right
> way, a pretty simple peephole optimizer would be able to eliminate most
> of them---for example, the ocaml bytecode interpreter recently gained a
> double-float result register (unboxed), and numerical performance
> improved quite a bit (see http://dem.inim.us/ocamlfp/README-FP.html ).
> Naively, I would expect even greater improvements if there's a proper
> native-code compiler sitting behind the floating-point specific
> operators.  You're not going to catch Bigloo or another compiler that
> does full SUA, etc, but you would make me very happy :).
> 
> Thanks,
> Will
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme