On Fri Aug 29 00:44:18 2008, [EMAIL PROTECTED] wrote: > Geoffrey Broadwell via RT wrote: > > > > 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? > > Compared to the cost of the multiple dispatch that all the math ops do, > the cost of creating a temporary variable to hold the result is very minor. > > That said, the semantics of whether the destination PMC is modified or > replaced by a new one is determined by the particular sub selected by > multiple dispatch. It's even possible (or will be once the MMD branch is > merged back in) to define a non-multi vtable function in a particular > PMC, to optimize away the cost of multiple dispatch. > > Allison >
I think this has been resolved, but not sure. Can anyone confirm? cheers, kjs _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
