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

$x should become $(Ref(x))[]? #205

Open
stevengj opened this issue Apr 14, 2021 · 8 comments
Open

$x should become $(Ref(x))[]? #205

stevengj opened this issue Apr 14, 2021 · 8 comments

Comments

@stevengj
Copy link
Contributor

stevengj commented Apr 14, 2021

It's a bit annoying when you have to use this convoluted Ref trick to prevent the compiler from constant-folding the whole calculation (ala #130):

julia> @btime exp(1);
  0.052 ns (0 allocations: 0 bytes)

julia> @btime exp($(Ref(1))[]);
  13.785 ns (0 allocations: 0 bytes)

It would be nicer if we could just use @btime exp($1) and the $ did the trick automatically.

(Another case just came up on discourse. cc @stillyslalom)

@ettersi
Copy link
Contributor

ettersi commented Nov 13, 2021

+1 for a more convenient syntax, but I'm not sure whether $x is the right syntax. In my understanding of interpolation, x = 42; :(foo($x)) and foo(42) should be one and the same thing.

@stevengj
Copy link
Contributor Author

Individual macros can do whatever they want with interpolation syntax; it doesn't have to be limited to expression interpolation.

@ettersi
Copy link
Contributor

ettersi commented Nov 16, 2021

Of course you can write a macro such that @extremely_large_value_of_2(2+2) == 5, but that probably wouldn't be very useful unless you are running a T-shirt company.

A concrete example where (I believe) the proposed syntax would be problematic is x = 2.0; n = 2; @btime $(Ref(x))[]^$n. In this case, you might legitimately want n to be "hardwired" into the benchmark expression but not x.

@gdalle
Copy link
Collaborator

gdalle commented Jun 13, 2023

Would #130 alone solve this? Or can this pop up in more complex functions?

@stevengj
Copy link
Contributor Author

#130 is just a warning. I'm suggesting that BenchmarkTools should just fix this automatically by automatically wrapping every interpolated expression in a Ref.

@gdalle
Copy link
Collaborator

gdalle commented Sep 18, 2023

Do you think @ettersi's counterexample is relevant @stevengj?

@stevengj
Copy link
Contributor Author

stevengj commented Oct 11, 2023

A concrete example where (I believe) the proposed syntax would be problematic is x = 2.0; n = 2; @btime $(Ref(x))[]^$n. In this case, you might legitimately want n to be "hardwired" into the benchmark expression but not x.

In cases where you want to literally interpolate into the benchmark expression, you could use @eval @btime $(Ref(x))[]^$n … but the need for this seems pretty rare to me.

@willow-ahrens
Copy link
Collaborator

Is this solved via #30 and #265? Currently, here's the same example:

julia> @btime sin(1)
  1.000 ns (0 allocations: 0 bytes)
0.8414709848078965

julia> @btime sin($1)
  5.333 ns (0 allocations: 0 bytes)
0.8414709848078965

julia> @btime sin($(Ref(1))[])
  5.333 ns (0 allocations: 0 bytes)
0.8414709848078965

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

No branches or pull requests

4 participants