Larry Wall <[EMAIL PROTECTED]> wrote:
> Dave Mitchell writes:
> : | my personal pet peeve: death to dSP and friends !!
...
> I think that's silly. You misuse a variable that requires an auto, the
> compile dies, that's all. And macros can be very useful for an abstraction
> layer that intended to *hide* the implementation. Hoisting implementation
> details into the name defeats that abstraction.
>
> The whole point of dSP and friends was to make it easier to switch to
> inline threaded code if we felt like it, in which case all bets are off
> as to which variables are auto.
My main objection to dSP et al is that it represents the innermost circle
of the hell that is Perl 5 macros. Stuff like this is totally bemusing to
the newcomer:
dPOPPOPnnrl;
if (right == 0.0) ....
I was just trying think of ways of altering people that Something Funny
is Going On Here. Oh well, I surrender...
> : If you do put an optimisation in, time it on as many architectures
> : as you can, and reject it if it slows down on any of them! And remember
> : to document it.
>
> Or disable the optimization on that architecture, to get the benefit of
> it elsewhere, balancing the benefits of the small code fork against
> the benefits of not forking. When in Rome, do as the Romans would do
> if they weren't Roman and just visiting.
My thinking behind "if fails on one, avoid on all" was that if it failed
on at least one, then it may well fail on others that you dont have access
to - either now or in the future, and thus perhaps isnt as good an optimisation
as you figured. The other way would to be only enable for those architectures
that experience a speedup.
