Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order dependent function compilation with inlining #41740

Open
raminammour opened this issue Jul 30, 2021 · 1 comment
Open

Order dependent function compilation with inlining #41740

raminammour opened this issue Jul 30, 2021 · 1 comment

Comments

@raminammour
Copy link
Contributor

raminammour commented Jul 30, 2021

Hello,

I know that there are some issues open about order dependent inference behavior, I am not sure if this is related, but it may help with debugging. Feel free to close if this is duplicate or expected. I was producing a simple example to show how inlining can be bad sometimes and found this behavior peculiar:

function g(x,s)
    f(x,s[1])
end

@inline function f(x,s)
    s1=s
    for i in x
        s1 += i
    end
    s1
end

#As expected, inlining causes a bad type instability
for i in 3:7
    x=rand(10^i);@time g(x,Any[0.])
end
  0.000033 seconds (2.00 k allocations: 31.344 KiB)
  0.000288 seconds (20.00 k allocations: 312.594 KiB)
  0.002709 seconds (200.00 k allocations: 3.052 MiB)
  0.046871 seconds (2.00 M allocations: 30.518 MiB, 30.53% gc time)
  0.381641 seconds (20.00 M allocations: 305.176 MiB, 37.92% gc time)

@noinline function f(x,s)
    s1=s
    for i in x
        s1 += i
    end
    s1
end

# Again expected, not inlining ~ function barrier --> helps
for i in 3:7
    x=rand(10^i);@time g(x,Any[0.])
end
  0.000006 seconds (2 allocations: 112 bytes)
  0.000014 seconds (2 allocations: 112 bytes)
  0.000132 seconds (2 allocations: 112 bytes)
  0.001321 seconds (2 allocations: 112 bytes)
  0.012353 seconds (2 allocations: 112 bytes)

# Now **redefine f** with inline
@inline function f(x,s)
    s1=s
    for i in x
        s1 += i
    end
    s1
end

# Surprising, same behavior as with no-inline
for i in 3:7
    x=rand(10^i);@time g(x,Any[0.])
end
  0.007094 seconds (4.13 k allocations: 218.143 KiB, 99.71% compilation time)
  0.000014 seconds (2 allocations: 112 bytes)
  0.000132 seconds (2 allocations: 112 bytes)
  0.001481 seconds (2 allocations: 112 bytes)
  0.018629 seconds (2 allocations: 112 bytes)

It looks as if g is not recompiled (though the first line shows it being recompiled), if we redefine g it works as expected. Is it expected with inlining that the function is not recompiled?

Cheers, and great JuliaCon!

Julia Version 1.6.1
Commit 6aaedecc44 (2021-04-23 05:59 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin18.7.0)
  CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, skylake)
@kimikage
Copy link
Contributor

kimikage commented Jul 31, 2021

Is this a kind of "so-called" #35800?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants