On Thu, 2008-08-28 at 00:03 -0700, Allison Randal wrote:
> Briefly discussed on the phone with Patrick, Jerry, and chromatic: The
> versions of the math opcodes that modify an existing destination PMC
> instead of creating a new destination PMC are not useful to HLLs,
> because they make assumptions about assignment semantics that don't hold
> true for all (or possibly even any) HLLs. Code generated from PCT takes
> the result of the math op as a temporary result value, and then performs
> a separate assignment operation to the HLL result variable, following
> the HLLs semantics for assignment.
>
> The plan is to make the regular variants (like 'add') create a new
> destination PMC, and then deprecate the old n_* variants (like 'n_add').
What is the replacement for the old "regular" variants that use a
pre-existing destination?
A few years ago when I was doing copious Perl 5 PDL work, I found that
in certain loops I would get bottlenecked entirely by creation and
destruction of temporaries. I might be doing several dozen math
operations per iteration, but I as the programmer knew that I only
needed a handful of temporaries, and these could be created outside the
loop. The vast majority of the object cycling was quite obviously
wasted. In some cases, I could work around this by considerably
uglifying the code and/or reaching through several layers of
abstraction, but sometimes there was no recourse except to drop to
PDL::PP (specially preprocessed C) or even C itself.
I'd like to be able to write decently-performing math libraries in PIR,
instead of having to drop down all the way to C. Being forced to create
and destroy loads of temporaries I don't need will make this nigh
impossible, let alone putting a major strain on the GC subsystem.
Will there be some way to stay in PIR and still optimize away temporary
cycling?
-'f
|