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
