Hello,
> It might still be preferable to provide higher-dimensional versions which
> do something more efficient that simple repetition.
Yes, if I have time and will to code them (these are not in the hot code
section in my code, so I am more worried about correctness, flexibility and
ease of use than speed)
> And this obviously is not particularly fast, since you are paying the
> subroutine call overhead on UniformInteger every time. You'll need lots
of
> optimisation cleverness in the compiler to sort that one out.
Presumably the routine for generating a random number is not too fast, if it
is, then an inlined generator (which I will generate using my preprocessor
explicitly, since I would not trust my compiler to do that with internal
functions) would solve the calling overhead problem.
> There is ABSOLUTELY NO NEED to do this.
>
> The NAG compiler only generates a temporary if the actual argument is
> discontiguous at runtime. This is such an obvious and simple optimisation
> for a common paradigm (and so well known) that no self-respecting
> optimising compiler should fail to do it.
That was somewhat of a speculation. Timing results are attached for LF95 on
a Linux box. The timing for the scalar generator is obtained by calling it
in a loop the same number of times as there are elements in the large arrays
(1,000,000 or so). I am not sure of the exact reasons for the inefficiencty,
but I can speculate...
As to the reentrant API and thread safeness and such, the base generator,
either scalar or for a simple uniform array, will have to be changed when
changing platforms, especially if moving to a parallel machine...I am not
there in coding my library yet...
Thanks,
Aleksandar
_____________________________________________
Aleksandar Donev
http://www.pa.msu.edu/~donev/
[log in to unmask]
(517) 432-6770
Department of Physics and Astronomy
Michigan State University
East Lansing, MI 48824-1116
_____________________________________________
|