[perl #58410] [TODO] Deprecate n_* variants of the math opcodes

[Allison Randal]

# 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

[Geoffrey Broadwell]

Post by Allison Randal
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

[Allison Randal]

Post by Geoffrey Broadwell
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

[Bernhard Schmalhofer]

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

[Patrick R. Michaud]

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

[Chromatic]

Post by Patrick R. Michaud

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

[Patrick R. Michaud]

Post by Chromatic

Post by Patrick R. Michaud

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 ?

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

[Chromatic]

Post by Patrick R. Michaud

Post by Chromatic

Post by Patrick R. Michaud
What's the replacement opcode for n_neg ?

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