Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If you do nothing an infinite number of times, in the end do you end up having done anything? Yesterday on #perl6 I had a quick talk with TimToady and others about: loop {}It was not the first time I saw this construct, but for the first time something bugged me about it. At first I thought it was because of the idea that Perl 6 is supposed to be parallelism-friendly, but then I realized this is not the issue here. I couldn't quite grasp what was the problem until I asked myself: "How long is the execution of this instruction supposed to take?" I suppose a no-op is not instantaneous. Well, for a computer I mean. I guess it takes at least a clock cycle or something. But at least conceptually, in a way an optimizer should be aware of, such an operation is supposed to be instantaneous. Thus its execution time is zero. Thus if you execute it once, twice, ten or a thousand times, it should still be zero. So, what if you do it an infinite number of times? Is it still zero? Infinite? In other words, what is 0 * Inf? In maths, zero times infinity is an undefined concept. Perl 6 already knows that:
Indeed we get NaN (Not A Number). So, what happens when you ask a computer to loop a no-op? Well, the computer could actually run some code to perform the loop and just the loop, but a compiler should not request something like that, should it? I mean if you put a no-op inside a program, like this for instance: say 'hello'; ; say 'good bye'The space between the two semi-colons can be considered as a no-op, right? Yet I very much doubt the compiler spends a clock cycle to execute it. More probably it just ignores it and goes directly from say 'hello' to say 'good bye'. Same if you run this: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Obviously such a program would not take twice as much time as: ;;;;;;;;;;;;;;;;;;;;;;;;;;Because a finite sequence of no-op can reasonably be replaced by a single no-op, right? To some extend, 'loop {}' is a way of writing an infinite sequence of semi-colons. So, why should it take seriously the no-op inside a loop? I think it shouldn't. It should just ignore it. However, a compiler can only ignore a finite number of successive no-op. Otherwise it would face an undefined concept, just as in 0 * Inf. That's why, if you ask me, I'd tell you that I think loop {} should die with a "undefined behavior" message. (or "singular behavior", "degenerated control structure", "infinite empty loop", ... you chose) In reply to Should loop {} really loop indefinitely? by grondilu
|
|