Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: I've done most of this in r35787, but we can't get rid of n_neg entirely until someone updates PCT and NQP not to use it for prefix:- rules. I poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? Pm
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tuesday 20 January 2009 07:27:53 Patrick R. Michaud wrote: On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: I've done most of this in r35787, but we can't get rid of n_neg entirely until someone updates PCT and NQP not to use it for prefix:- rules. I poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? If we remove n_neg, the replacement is likely a two-step operation: clone $P1, $P2 neg $P1 -- c
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tue, Jan 20, 2009 at 09:33:17AM -0800, chromatic wrote: On Tuesday 20 January 2009 07:27:53 Patrick R. Michaud wrote: On Mon, Jan 19, 2009 at 08:35:26PM -0800, chromatic via RT wrote: I've done most of this in r35787, but we can't get rid of n_neg entirely until someone updates PCT and NQP not to use it for prefix:- rules. I poked at that, but couldn't make them work. What's the replacement opcode for n_neg ? If we remove n_neg, the replacement is likely a two-step operation: clone $P1, $P2 neg $P1 Please, not this -- it's terribly inconsistent. When we got rid of the other n_* opcodes, their non-n_* counterparts were given the create a new PMC semantics that the n_* version had. We should do the same for n_neg, such that what was previously n_add $P0, $P1, $P2# construct $P0 as sum of $P1 and $P2 n_neg $P0, $P1 # construct $P0 as negation of $P1 is now add $P0, $P1, $P2 # construct $P0 as sum of $P1 and $P2 neg $P0, $P1 # construct $P0 as negation of $P1 Pm
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
On Tuesday 20 January 2009 09:50:56 Patrick R. Michaud wrote: What's the replacement opcode for n_neg ? If we remove n_neg, the replacement is likely a two-step operation: clone $P1, $P2 neg $P1 Please, not this -- it's terribly inconsistent. When we got rid of the other n_* opcodes, their non-n_* counterparts were given the create a new PMC semantics that the n_* version had. We should do the same for n_neg, such that what was previously n_add $P0, $P1, $P2# construct $P0 as sum of $P1 and $P2 n_neg $P0, $P1 # construct $P0 as negation of $P1 is now add $P0, $P1, $P2 # construct $P0 as sum of $P1 and $P2 neg $P0, $P1 # construct $P0 as negation of $P1 Hm, now that I look closer, this already exists and works that way. Thus the replacement is to use: neg $P0, $P1 -- c
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
Will Coleda via RT wrote:
On Thu Aug 28 00:03:51 2008, alli...@perl.org wrote:
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').
Does this include n_not , n_bnot, and n_bnots ?
Yes. The 'not', 'abs', 'bnot', and 'bnots' opcodes already have
2-argument variants, the 'n_*' alternates are unnecessary.
The task also involves modifying the corresponding vtable functions
('logical_not', 'absolute', 'binary_not', 'binary_nots') so they return
a new PMC, rather than morphing the existing destination PMC. (Many of
them already do this, so the 'n_*' variants were actually already doing
the same thing as the regular opcodes.)
Allison
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
Klaas-Jan Stol via RT schrieb: I think this has been resolved, but not sure. Can anyone confirm? It looks like it is not resolved yet. In src/ops/math.ops I still found: n_infix, n_abs and n_neg. Regards, Bernhard
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
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
[perl #58410] [TODO] Deprecate n_* variants of the math opcodes
# New Ticket Created by Allison Randal # Please include the string: [perl #58410] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58410 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'). Allison
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
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
