The compiler should be able to optimize all of them to the same machine code.
This is already good.
Easily optimized by constant folding.
This one depends on the semantics of signed underflow, so it may not do what you want.
The loop can only exit if x==10, so as long as the nextInt() method doesn’t have side effects, the loop should be eliminated. But, again, language semantics can affect this.
I feel like an idiot. Also, in the “Good” example, no underflow occurs. i goes from 0 to -10, and x is assigned to -i every loop.
It might still be possible to optimize away the random number example, if the random function were made a magic language item, but it would not be even remotely close to being worth the effort.
The question the optimizer can’t really answer is: will Random.nextInt() ever return 10? If that’s a 64 bit integer it could be a LOOOOOONG time before 10 ever shows up.
For #4 if the Random instance weren’t “new”, then calling the nextInt() function would definitely have side effects, since the next integer would pull one away from the random stack.
However unlike the first three which will run within a consistent amount of time, #4 will take an unknown amount of time to run, so you can’t just collapse it and eliminate the loop.
For example a very simple race game where a participant moves a random number of steps each turn, we may want to time how long that race takes. We can’t just say that they will reach the end immediately. In fact technically we don’t know that they will ever finish the race… But that’s the halting problem and a whole other issue.
But, if you borrow C’s semantics, you are allowed to “optimize” away side-effect-less loops, even if they would never terminate. But that would require the random method to be pure.
You could do a lot worse. If the type of i was an object, you could overload the negation operation to have side-effects for the third snippet, for example.
The compiler should be able to optimize all of them to the same machine code.
This one depends on the semantics of signed underflow, so it may not do what you want.The loop can only exit ifx==10, so as long as thenextInt()method doesn’t have side effects, the loop should be eliminated. But, again, language semantics can affect this.Edit: Very wrong for 3 & 4, see replies.
I’d be shocked if 4 got optimised out
4 is used for non-deterministic delay - - - is Random.nextInt() also cryptographically secure?
I feel like an idiot. Also, in the “Good” example, no underflow occurs. i goes from 0 to -10, and x is assigned to -i every loop.
It might still be possible to optimize away the random number example, if the random function were made a magic language item, but it would not be even remotely close to being worth the effort.
The question the optimizer can’t really answer is: will Random.nextInt() ever return 10? If that’s a 64 bit integer it could be a LOOOOOONG time before 10 ever shows up.
Ah yes the halting problem
For #4 if the Random instance weren’t “new”, then calling the nextInt() function would definitely have side effects, since the next integer would pull one away from the random stack.
However unlike the first three which will run within a consistent amount of time, #4 will take an unknown amount of time to run, so you can’t just collapse it and eliminate the loop.
For example a very simple race game where a participant moves a random number of steps each turn, we may want to time how long that race takes. We can’t just say that they will reach the end immediately. In fact technically we don’t know that they will ever finish the race… But that’s the halting problem and a whole other issue.
I don’t know what I was thinking.
But, if you borrow C’s semantics, you are allowed to “optimize” away side-effect-less loops, even if they would never terminate. But that would require the random method to be pure.
Still a mess to read though, anyone revewing the code will be like wtf?
You could do a lot worse. If the type of
iwas an object, you could overload the negation operation to have side-effects for the third snippet, for example.