RFC: lower x^literal as x^Val{literal} for integer literals #20530

stevengj · 2017-02-08T21:48:20Z

As discussed in #20527.

This PR doesn't change any behaviors or implement any optimizations for small powers yet — it just falls through to the generic ^ for now — but there are a number of improvements that would be easy to add (in separate PRs, probably) if this is merged.

JeffBezanson · 2017-02-08T22:08:25Z

src/ast.c

+        return fl_ctx->T;
+    else if (iscvalue(args[0]) && fl_ctx->jl_sym == cv_type((cvalue_t*)ptr(args[0]))) {
+        jl_value_t *v = *(jl_value_t**)cptr(args[0]);
+        if (jl_is_long(v) && jl_unbox_long(v) < 32 && jl_unbox_long(v) > -32)


I believe small julia Ints get mapped to fixnums, so this should not be necessary.

I was thinking about metaprogramming where someone splices a value into an expression

The representation should be the same in that case. It would be an issue for splicing other integer types, though, but that's difficult to handle in general.

Oh, right, julia_to_scm does that transformation automatically. Great, this PR will get shorter!

JeffBezanson · 2017-02-08T23:11:22Z

With this, we might be able to remove the custom inlining code for ^, which is pretty nasty. cc @vtjnash

felixrehren · 2017-02-09T08:39:37Z

base/promotion.jl

@@ -253,6 +253,11 @@ end

 Exponentiation operator. If `x` is a matrix, computes matrix exponentiation.

+If `y` is an `Int` literal (e.g. `x^2` or `x^-3`), the Julia code


"(e.g. 2 in x^2 or -3 in x^-3)," ?

andyferris · 2017-02-10T09:48:40Z

Could this be made more powerful/useful as a step in inference? That is, have the transformation made for any constant exponent, rather than just literal?

Yes, it would be a bit more magical, but it would also be a bit more powerful/generic.

stevengj · 2017-02-10T12:39:42Z

@andyferris, seems like a lot of effort for little payoff. How often does one do const two = 2 and then use x^two instead of x^2? Moreover, I'm skeptical that we want to do this for non-integer exponents.

Right now, this is merely syntactic sugar. Making it something "more magical" that occurs later in compilation would be a more invasive change in the language.

andyferris · 2017-02-10T13:13:24Z

That's fair enough (I would only ask it to do this for constant integers). The thought for me was you might have dimensionful packages call exponentiation programmatically with type parameter constants as exponents e.g. when converting metric to imperial, etc. But it's not a big deal if these are a bit slower, and I can't estimate if inference transformations are harder to implement than lisp ones, and more magical = bad, for sure.

stevengj · 2017-02-10T14:22:47Z

@andyferris, that's a good point, but they can still use this PR as-is for type parameters via generated functions. Note also that if you do miles_to_km(x::Miles{n}) = Kilometers{n}(x.val * kmpermile^Val{n}} it will work too. (Though in that application you can use e.g. a generated function and avoid the runtime exponentiation completely.)

StefanKarpinski · 2017-02-10T15:51:06Z

To me the fact that this is only for literal exponents is a feature – it keeps the rule simple: exponentiation by an integer literal means one thing; exponentiation by anything else (constant, variable, expression, whatever) means something else. The fact that this fairly simple distinction addresses the vast majority of the pain we've encountered over the years from ^ is the appeal.

andyferris · 2017-02-13T10:10:34Z

Simple rules are always best.

Does this expand out automatically for v.^5 and so on? Seems like that would present a similar performance and inferability bottleneck.

stevengj · 2017-02-13T12:56:08Z

@andyferris, yes, see the test.

What happens is that literal arguments are already inlined in dot calls, so v.^5 was getting converted to broadcast(x -> x^5, v) during lowering. As a result, the x^5 in the anonymous function now gets converted to x^Val{5} without requiring any special case for .^.

andyferris · 2017-02-13T13:04:34Z

Awesome, thanks for the clarification.

stevengj · 2017-02-13T19:33:12Z

Can we get a decision on this for 0.6?

tkelman · 2017-02-13T19:38:19Z

I share @vtjnash's reservations on this (it may conflict with #19890), and dislike giving literals special treatment.

stevengj · 2017-02-13T19:47:32Z

(I don't see any conflict with #19890 ... whether to do anything special for float^literal is entirely orthogonal to this PR. We could still decide to call powf unless @fastmath is enabled, for example. And we could still inline cases that are currently calling power_by_squaring, like complex^literal or int^literal. And there is still the inference benefit for Unitful, and the ability to do integer^-1 etc.)

tkelman · 2017-02-13T20:01:29Z

Having x^(-2) work dramatically better than p=-2; x^p and give potentially different behavior in some package would be rather surprising. There's a semantic red flag this is raising to me (would you call this referential transparency?)

ajkeller34 · 2017-02-13T20:37:40Z

@tkelman I share your concerns about referential transparency, but I think the pros outweigh the cons here. @stevengj has listed several tangible benefits of this PR and I think the disadvantages you point out could be mitigated in documentation.

Could PackageEvaluator be run to see if any packages are impacted by the changes in this PR? If few or none of them are, then that seems like useful data to have before making a final decision.

stevengj · 2017-02-13T20:38:35Z

@ajkeller34, this particular PR shouldn't affect any package, because x^Val{p} simply calls x^p in all cases at the moment.

vtjnash · 2017-02-13T20:50:07Z

I think the disadvantages you point out could be mitigated in documentation

Stefan mentioned this too. To me, this sounds like a significant con (that the behavior is sufficiently surprising it requires extra documentation on pow). And it also makes understanding how to call/overload pow take more effort.

There's a substantial amount a language can do by pattern matching input rather than doing dispatch. But I don't think we should go down that route.

martinholters · 2017-02-15T09:39:21Z

What if we don't do any special parsing but still go ahead and do something useful for x^Val{n}? Yes, writing out x^Val{-2} is longer than just x^-2, but it's absolutely non-magic (and that's supposed to be a pro in this context).

KristofferC · 2017-02-15T09:58:43Z

@valify x^2 + x^-3

stevengj · 2017-02-15T12:25:40Z

@martinholters, explaining to users that they have to use x^Val{-2} or @valify x^-2 to do what they want would be a huge wart on the language, in my opinion.

Explaining about x^Val{p} to the tiny minority of users who want to override ^ for new numeric types (which tend to be defined by only the most sophisticated developers) seems like not such a huge deal. (Overriding ^ for non-numeric types will still be able to just override ^(x, p), since in those cases ^(x, Val{p}) will probably call the fallback.)

StefanKarpinski · 2017-02-16T18:15:01Z

@stevengj: since this has passed CI, you could just merge it and add text in NEWS saying that it's an experimental feature in a separate PR, or add a [ci skip] commit to this PR – your call.

…uliaLang#20527)

…heme, regardless of their origin

vtjnash · 2017-02-17T06:35:43Z

It looks like this hurt performance of several benchmarks (I'm guessing, but this seems to be the only commit that changed code). I suspect that this may be blocking inlining now in some cases. I suspect it will also will be hiding x^2 from inlining as x*x right now.

tkelman · 2017-02-17T08:13:29Z

probably shouldn't have assumed this wouldn't cost anything without verifying as much. 3x slowdown on several of the benchmarls is a substantial argument against doing this.

stevengj · 2017-02-17T11:58:37Z

Would it fix it just to put @inline in front of the fallback definition?

stevengj · 2017-02-17T11:59:34Z

@tkelman, it's not really a "substantial argument" if it is easily fixed, as I'm sure that it is. (On the contrary, this approach allows us to easily do more inlining if we want.)

tkelman · 2017-02-17T13:48:01Z

until it's fixed it's a noticeable performance regression. if simple, fine, but the existing logic in inference isn't simple and this shouldn't break it without a more general replacement

stevengj · 2017-02-17T17:13:44Z

The existing logic isn't simple, but the new logic in terms of Val should simple; it shouldn't require me to touch inference.jl at all, I think. I'll push a PR.

stevengj · 2017-02-17T17:28:36Z

I've pushed a PR with a "more general replacement" as requested.

tkelman · 2017-02-17T17:35:01Z

it's less general if inference can currently handle non-literal constants

stevengj · 2017-02-17T17:47:19Z

That case is still handled by inference.jl, since non-literal constants are not lowered to x^Val{p}.

timholy · 2017-02-17T18:15:22Z

base/intfuncs.jl

+# x^p for any literal integer p is lowered to x^Val{p},
+# to enable compile-time optimizations specialized to p.
+# However, we still need a fallback that calls the general ^:
+^{p}(x, ::Type{Val{p}}) = x^p


How about we rewrite this as ^(x, p) = internal_pow(x, p) and then dispatch on Val in internal_pow? I ask because this is going to be a magnet for ambiguities since packages are likely to specialize on the first argument. E.g., PainterQubits/Unitful.jl#54

Unitful will maybe want to write its own ^(x, Val{p}) methods that are type-stable anyway, however, so in this case the ambiguity warning is helpful.

But I guess it doesn't hurt to do this, and it may be helpful in other cases?

I dunno, the more I think about it the more I think that the ambiguity warning is actually helpful here. Particularly if we start inlining x^Val{p}, anyone specializing purely on the first argument (and not restricting to p::Number, as most types would) will want to explicitly decide what to do for the Val{p} case.

these won't be warnings any more, they'll be errors the first time someone happens to call the ambiguous signature, unless you're going out of your way to check for ambiguities

Unitful wasn't even getting through precompilation, because some of these run at build time and the ambiguity error kicks in. These are fixable errors, as witnessed by that PR, but I don't personally see much downside to engineering the dispatch chain to avoid breakage.

The downside is that packages that really should be thinking about doing something different for Val{p} will get no warning of the change.

But I don't feel strongly about this; I've updated #20648 to use internal_pow as you suggest.

stevengj added needs decision A decision on this change is needed maths Mathematical functions needs docs Documentation for this change is required parser Language parsing and surface syntax labels Feb 8, 2017

stevengj changed the title ~~lower x^literal as x^Val{literal} for small integer literals~~ RFC: lower x^literal as x^Val{literal} for small integer literals Feb 8, 2017

JeffBezanson reviewed Feb 8, 2017

View reviewed changes

stevengj force-pushed the literalpow branch from 60553fb to 17e2e30 Compare February 8, 2017 22:48

stevengj changed the title ~~RFC: lower x^literal as x^Val{literal} for small integer literals~~ RFC: lower x^literal as x^Val{literal} for integer literals Feb 8, 2017

stevengj removed the needs docs Documentation for this change is required label Feb 9, 2017

felixrehren reviewed Feb 9, 2017

View reviewed changes

stevengj added this to the 0.6.0 milestone Feb 13, 2017

stevengj added 8 commits February 16, 2017 16:10

lower x^literal as x^Val{literal} for small integer literals (closes J…

b453ba6

…uliaLang#20527)

simplify smallnum check since all Ints get inlined as fixnums into Sc…

ce13a79

…heme, regardless of their origin

do x^Val{p} transformation for all literal p, not just small ones

7eeefee

fix comment

5411736

docs for x^Val{p}

a7f1f45

documentation tweak

f23f250

added test for x^literal

3a0d354

note experimental feature [ci skip]

d1dab59

stevengj force-pushed the literalpow branch from c08c38b to d1dab59 Compare February 16, 2017 21:10

stevengj merged commit 3222749 into JuliaLang:master Feb 16, 2017

stevengj deleted the literalpow branch February 16, 2017 21:11

stevengj mentioned this pull request Feb 16, 2017

inline ^ for literal powers of numbers #20637

Closed

stevengj mentioned this pull request Feb 17, 2017

minimal inlining of x^Val{p} for p=0,1,2,3 and x::Number #20648

Merged

timholy reviewed Feb 17, 2017

View reviewed changes

stevengj mentioned this pull request Feb 24, 2017

change x^p for literal p from x^Val{p} to x^Val{p}() #20783

Closed

stevengj mentioned this pull request Mar 3, 2017

Issues with the new x^y Val lowering #20882

Closed

ajkeller34 mentioned this pull request Mar 5, 2017

RFC: address issue #20882 #20889

Merged

rdeits mentioned this pull request Mar 14, 2017

@which and @code_warntype don't show ^Val{p} lowering #21014

Closed

ajkeller34 mentioned this pull request Mar 20, 2017

Make @fastmath aware of Base.literal_pow #21099

Closed

stevengj mentioned this pull request Oct 20, 2017

make x^-n equivalent to inv(x)^n for literal n #24240

Merged

		@@ -253,6 +253,11 @@ end

		Exponentiation operator. If `x` is a matrix, computes matrix exponentiation.

		If `y` is an `Int` literal (e.g. `x^2` or `x^-3`), the Julia code

RFC: lower x^literal as x^Val{literal} for integer literals #20530

RFC: lower x^literal as x^Val{literal} for integer literals #20530

Conversation

stevengj commented Feb 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeffBezanson commented Feb 8, 2017

Choose a reason for hiding this comment

andyferris commented Feb 10, 2017

stevengj commented Feb 10, 2017 • edited Loading

andyferris commented Feb 10, 2017

stevengj commented Feb 10, 2017 • edited Loading

StefanKarpinski commented Feb 10, 2017 • edited Loading

andyferris commented Feb 13, 2017

stevengj commented Feb 13, 2017 • edited Loading

andyferris commented Feb 13, 2017

stevengj commented Feb 13, 2017

tkelman commented Feb 13, 2017

stevengj commented Feb 13, 2017 • edited Loading

tkelman commented Feb 13, 2017

ajkeller34 commented Feb 13, 2017

stevengj commented Feb 13, 2017

vtjnash commented Feb 13, 2017

martinholters commented Feb 15, 2017

KristofferC commented Feb 15, 2017 • edited Loading

stevengj commented Feb 15, 2017 • edited Loading

StefanKarpinski commented Feb 16, 2017

vtjnash commented Feb 17, 2017

tkelman commented Feb 17, 2017

stevengj commented Feb 17, 2017

stevengj commented Feb 17, 2017

tkelman commented Feb 17, 2017

stevengj commented Feb 17, 2017

stevengj commented Feb 17, 2017

tkelman commented Feb 17, 2017

stevengj commented Feb 17, 2017 • edited Loading

Choose a reason for hiding this comment

stevengj Feb 17, 2017 • edited Loading

Choose a reason for hiding this comment

stevengj Feb 17, 2017 • edited Loading

Choose a reason for hiding this comment

stevengj Feb 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevengj commented Feb 8, 2017 •

edited

Loading

stevengj commented Feb 10, 2017 •

edited

Loading

stevengj commented Feb 10, 2017 •

edited

Loading

StefanKarpinski commented Feb 10, 2017 •

edited

Loading

stevengj commented Feb 13, 2017 •

edited

Loading

stevengj commented Feb 13, 2017 •

edited

Loading

KristofferC commented Feb 15, 2017 •

edited

Loading

stevengj commented Feb 15, 2017 •

edited

Loading

stevengj commented Feb 17, 2017 •

edited

Loading

stevengj Feb 17, 2017 •

edited

Loading

stevengj Feb 17, 2017 •

edited

Loading

stevengj Feb 17, 2017 •

edited

Loading