A problem about performance

General Usage Performance
21

what, when did I say that? stop making strawman argument

  1. we know non-const global causes problem
  2. some weird stuff going on in OP related to non-const global
  3. solution: don’t use non-const global because it’s a bad idea in all cases anyway
22

Just pretend the first post says

“I wrote fun2 which is a good function, then I rewrite fun1 which passes the argument in a non const global variable… I thought it should be much slower but in fact it’s 3x faster. Why?”

3 Likes
23

Please tone it down here. No need to yell (type in all caps) or get short with anyone. Let’s focus on @dlakelan’s rephrased question here.

7 Likes
24

Love and peace :saluting_face:

1 Like
25

It’s not “wrong”, just not the best.

26

Thanks @StefanKarpinski and @jling I felt like simply this is a miscommunication. Hopefully the rephrased question helps.

Can anyone else confirm the results with the same Julia version as OP? AND OP what kind of computer are you running on? processor and OS etc?

Are you still able to consistently reproduce these timings?

1 Like
27

Easy heuristic: If a benchmark shows an elementary operation being way faster than 1 ns, you are probably not measuring anything meaningful.

Thought experiment: If your CPU can make 10000 additions in 1.8 ns with serial code, what kind of frequency does it need to run at? (Assume one operation per clock cycle unless you happen to know a better approximation.)

3 Likes
28

Because after I did what they said, fun2($v) or const v = rand(10000), there was no difference between them, just like @lmiq 's. So it shouldn’t be a problem about version or platform.

I guess, fun2 will do something extra compared with fun1 when passing nonconstant v to them. I don’t know that, could someone explain that?

29

If i make both functions return s at the end, then I get the same timing

@btime f1()
@btime f2($v)

Both take about 12us on my laptop.

So, I think the answer is probably that because the original functions return nothing the loop is optimized away, and the difference you saw was the difference in time it takes to call a function with a given single argument vs to call a zero argument function. That’s my guess.

1 Like
30

I think the difference is more a question of how effectively the two functions happen to be optimized down to doing nothing. You can see from the LLVM code in the original post that there are still remnants of doing something, which apparently takes a small amount of time, but that it clearly involves neither looping, nor summing anything.

2 Likes
31

Yes, that seems to be it. As soon as you make them do useful work, by returning s at the end, they both do real stuff and take about the same time.

2 Likes