subroutine faster than function? (ifort 10.1.021)

subroutine faster than function? (ifort 10.1.021)

Are there benefits using a function instead of a subroutine if both subprograms can be implemented?

For simple test-problems subroutines seem slightly faster than functions, whether using the pure statement or not. Is this a rule of thumb or misleading?

Best regards,

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Misleading. The only difference is actually returning the function result, and that should be no different in time than storing a result in a subroutine argument.

Steve - Intel Developer Support

The only real issue should be clarity of meaning. A subroutine must be called before any "result" can be used in another statement. For example a write statement.
call sub(x)
call sub(z)
y = x + z   and   Write (...) ..., x, ..., z, ...

Whereas a (well behaved) function can be used within a statement.
y = AFun(x) + AFun(z)       ! Hopefully there are no funny "side effects" inside AFun !
Write(...) ..., AFun(x), ..., AFun(z), ...


Les, thanks for the example and I agree that sometimes the function use can be more concise and therefore simpler. In many other (most?) cases, however, I think function references can be confusing because an unfamiliar reviewer doesn't know whether the word he sees if a function or a variable. When you CALL a subroutine, it is perfectly clear that the name is a subroutine and it is being called.

I used to think that functions executed faster. Probably because I observed them used heavily in time-sensitive applications like data acquisition programs. I even THINK I recall an explanation, something about the way subroutines utilize stack operations to transfer data while functions do not (or do it differently). Maybe I was all wet. Or maybe it used to be true but no longer?

I've never known it to be true. The only possible reason is that returning a scalar value in a register is perhaps a bit faster than storing it in memory through an argument. If you did this a LOT, perhaps you'd be able to measure something, but it seems unlikely. I'm not in favor of nano-optimizing like this. Far better to write clear, understandable code. With modern optimizing compilers, and inlining, any advantage is muted.

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today