Re: pure procedure
- From: Dick Hendrickson <dick.hendrickson@xxxxxxx>
- Date: Fri, 22 Apr 2011 13:46:58 -0500
On 4/22/11 11:39 AM, nmm1@xxxxxxxxx wrote:
Richard Maine<nospam@xxxxxxxxxxxxx> wrote:
Daniel H<no.spam.address@xxxxxx> wrote:
[about lying to the compiler to fake it intothinkinga procedure is pure]
Now I am wondering: are there any drawbacks / pitfalls to this?
Mostly the obvious two.
1. It is nonstandard. As mentioned by others, that means that it might
not work at all on some compilers. Those might even potentially include
future "smarter" versions of the ones you currently use.
1. It adds complication - enough complication that you''ll probably need
to add comments explaining what is going on and why. Otherwise, someone
is likely to do something like "fix" it at some point in the future.
Yes, to both of those.
Also, I am wondering whether it's worth the trouble. How much do I gain
if in this way I manage to declare my procedures as pure? Asked the
other way around: what is the additional benefit of adding the pure
keyword in a function that already conforms to the requirements?
Usually no gain at all. People might speculate about potential
performance gains, but I wouldn't place any faith in such speculation
unles backed by measured data. Performance is really not what purity is
Not at all. Any half-competent optimising compiler will recognise
that PURE procedures can be made subject to common expression
elimination and code rearrangement, just as the intrinsics can.
I agree that it will have no significant difference on the actual
execution time of the procedure!
There's one difference between PURE and intrinsic. PURE procedures can use entities in common or from a module as "input", not just their arguments. This limits how much multi-line optimization can be done.
x = pure_F(7)
y = F(23)
z = pure_F(7)
isn't optimiziable unless the compiler can see into F and pure_F. In some ways it's too bad that F95 didn't limit PURE routines to also not accessing anything as well as not modifying anything.
The gain is in being allowed to use the procedure in contexts that
require purity. Those contexta are pretty limitted. They are also
exactly the kinds of places where failing to follow the rules is most
likely to get you in trouble.
Well, yes, but that's not the REAL gain, which is how much they
can speed up debugging in large programs. If you see a PURE
procedure, (a) you can be certain that it isn't going to have a
strange (legal or illegal) side-effect on some other data and
(b) you can put extra calls in your diagnostic statements without
affecting the results.