Re: ELEMENTAL functions and performance

On Jul 30, 9:37 am, Daniel Kraft <d...@xxxxxxxx> wrote:
When called with an array argument, your ELEMENTAL procedure will be
called for each element as opposed to when your procedure accepts the
whole array for one call, and thus here's the possiblity that the
performance changes; but I don't think you can really know in advance if
it improves or degrades and how much; that probably depends on your code
and how your compiler interprets it.

If the compiler calls the elemental function once per each array
element, it largely depends whether the compiler can inline the
function. If it can, it should be quite fast, if it cannot, I would
expect that the program might slow down a lot, especially if you have
a large number of array elements and the calculation in the elemental
procedure is quick (i.e. the procedure-calling overhead is larger than
the calculations in the procedure). On the other hand, if you have
only an array-valued procedure, the construction of an array and doing
array assignments in the procedure can also take some time, which
means that for scalars a elemental procedure should be (a tiny bit,
presumably negligibly) faster.

I believe that in most of the cases, the performanceloss due to
elemental procedures is negligible and worrying about the algorithm or
other things is much more important.

Thus, unless you are sure that the procedure is called very often with
array arguments, I would not worry about it. If it is called a lot,
you should profile the code and verify that it is indeed a hot spot
for the compilers you use.

An alternative to an ELEMENTAL function is to have a generic procedure
containing a scalar and an array specific procedure. That gives a
convenient interface to the user and is fast - for both scalars and
arrays - but you replicate code with all its disadvantages.
(Therefore, you really should check whether it makes a difference for
your compiler; having a well-readable code is more important than
having a tiny performance gain. Especially as compilers make progress
and different compilers behave differently, some changes might be not
needed or worse make the program even slower.)

Tobias
.

Relevant Pages

  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)
  • Re: Windows array allocation problem
    ... array reference has to have a 64-bit index or array subscript triplet? ... to fit in one. ... That assumes, of course, that your compiler ... limits on just about anything. ...
    (comp.lang.fortran)
  • Re: Error handling library
    ... which lets the compiler catch out-of-range usage. ... and assuming that a higher int means "more dangerous error" ... with a comment warning that one is used as an index into the array ... languages while running (an array of languages, ...
    (comp.lang.c)
  • Bounds checked arrays
    ... As everybody knows, the C language lacks ... When the state of this toggle is ON, the compiler ... Important is to know that the array updates ... We have just to allow him/her to specify what to do ...
    (comp.lang.c)