One of the most common complaints arising in this group is issue 15276, performance of captured variables in closures · Issue #15276 · JuliaLang/julia · GitHub , which seems to cause all kinds of baffling performance hits. I’m wondering whether this issue could be solved by adding the following rest…

Unfortunately inference can’t help us much here. The boxing is occurring at the syntax level. This is before Julia has access to inference. It’s before compilation. That’s what makes it so tricky. We’re in #development — let’s make it more #development-y. Here’s one of the simpler examples from …

Ok, I think I get the problem now, and it is even worse: We currently miscompile closures in order to avoid the performance slowdown. Or is the following behavior correct? @noinline cb2(x) = (x.r.contents = "foo";); function f1(cb2) if true end; r=1; cb = ()->r; …

[image] foobar_lv2: Edit: The behavior on f1 is correct and on f2 is wrong, imo. Except if we changed the language semantics. No this is not wrong. Just because it happens at lowering doesn’t mean it’s the semantics. It also doesn’t mean inference can’t do anything about it but it is much har…

So, do you think that either f1 or f2 is misbehaving, or rather that this is proper as-intended UB?

“Soft” UB, as in f1(cb2) should do something sensible or throw? Or “hard UB”, as in f1(cb2) would be allowed to spawn bats out of your ears (corrupt memory)?

Neither. It’s an implementation detail so you just can’t assume it’ll do anything you want. It doesn’t really make sense to be more specific about it since you should never do it other than for debugging, in which case you are always exploring compiler implementations anyway. It won’t be something…

Thank you for taking the time to write this really clear explanation of the issue. This is very helpful. I didn’t realize that the problem arises before type inferencing. If I understand your write-up correctly, it seems that a user could ensure that 15276 won’t arise if there were a means to dec…

I see your point about Int. It seems that there is no syntax in the current language for a closure to indicate to the parser that a captured variable has a definite type, so the parser is stuck with a bunch of heuristics. If there were such a syntax, would that solve 15276 (if a code uses it)? Wo…

Language restriction to solve 15276?

Internals & Design

yuyichao May 6, 2018, 9:39pm 38

No, the parser has no idea that Int is a constant type.

Topic		Replies	Views
RFC: Some Ideas to Tackle #15276 - performance of captured variables in closures Internals & Design inference , type-stability , corebox	65	5037	February 16, 2024
Can someone explain closures to me Internals & Design performance , type-stability , closure	13	3524	November 2, 2023
Type stability in closures Performance type-stability , closure	13	334	November 28, 2024
"A Tragedy of Julia’s Type System" Offtopic	33	3133	January 13, 2025
Boxing obvious cases where the type is clear Performance	13	726	December 7, 2023

Language restriction to solve 15276?

Related topics