|
|
 Up |
|
|
  |
Author: zhngbnzhngbn Date: Jul 6, 2008 12:51
Hi, all
I have heard that the build-in function anint of fortran is kind
of slow, but I have to used it quite frequent in my code. Anyone know
a more efficient version of it?
Thanks a lot.
|
| |
|
| | 12 Comments |
|
|
Author: nospamnospam Date: Jul 6, 2008 13:16
> I have heard that the build-in function anint of fortran is kind
> of slow, but I have to used it quite frequent in my code. Anyone know
> a more efficient version of it?
That's pretty much a meaningless question without a whole lot more
context. That kind of thing depends 100%% on the particular compiler
implementation. It would not be a property of the Fortran language,
which doesn't say anything about how the function is implemented. If
there were a faster implementation of exactly the same thing, then
presumably the compiler vendor would adopt it and that would then *BE*
the intrinsic one for that compiler.
There are basically only two ways that can make any sense.
1. If it is a problem with a particular compiler. In that case, well, it
would depend on that particular compiler.
2. The suggestion is that the functionality of anint is inherently slow.
In that case, the interesting question would be what alternate
finctionality would suit your needs.
|
| Show full article (1.50Kb) |
|
| | no comments |
|
|
Author: zhngbnzhngbn Date: Jul 6, 2008 14:53
> 2. The suggestion is that the functionality of anint is inherently slow.
> In that case, the interesting question would be what alternate
> functionality would suit your needs.
This is what I wanted. :) Any suggestions?
Sorry for any misunderstanding.
Thanks.
|
| |
| no comments |
|
|
Author: dpbdpb Date: Jul 6, 2008 14:56
zhngbn wrote:
>> 2. The suggestion is that the functionality of anint is inherently slow.
>> In that case, the interesting question would be what alternate
>> functionality would suit your needs.
>
> This is what I wanted. :) Any suggestions?
...
Profile the code to first prove what you have is actually a
bottleneck...like Richard, I am also skeptical this is a real problem.
--
|
| |
| no comments |
|
|
Author: zhngbnzhngbn Date: Jul 6, 2008 15:19
On Jul 6, 2:56Â pm, dpb non.net> wrote:> zhngbn wrote:
>>> 2. The suggestion is that the functionality of anint is inherently slow.
>>> In that case, the interesting question would be what alternate
>>> functionality would suit your needs.
>
>> This is what I wanted. :) Any suggestions?
>
> ...
>
> Profile the code to first prove what you have is actually a
> bottleneck...like Richard, I am also skeptical this is a real problem.
>
> --
This is the flat profile I got from gprof:
1 Flat profile:
2
3 Each sample counts as 0.01 seconds.
4 %% cumulative self self total
5 time seconds seconds calls s/call s/call name...
|
| Show full article (1.44Kb) |
| no comments |
|
|
Author: dpbdpb Date: Jul 6, 2008 15:25
zhngbn wrote:
> On Jul 6, 2:56 pm, dpb non.net> wrote:...
>> Profile the code to first prove what you have is actually a
>> bottleneck...like Richard, I am also skeptical this is a real problem.
...
> This is the flat profile I got from gprof:
...
> 4 %% cumulative self self total
> 5 time seconds seconds calls s/call s/call name
> 6 38.95 47.07 47.07 20001 0.00 0.00 derv_
> 7 20.59 71.96 24.89 20001 0.00 0.00 second_
> 8 17.76 93.42 21.46 20001 0.00 0.00 third_
> 9 10.08 105.60 12.18 f_ldnint_val
...
> Is the function on line 9 "f_ldnint_val" the build-in "anint"? I have
> clearly not defined this function.
Perhaps, I'm not positive.
|
| Show full article (1.06Kb) |
| no comments |
|
|
Author: zhngbnzhngbn Date: Jul 6, 2008 15:53
On Jul 6, 3:25Â pm, dpb non.net> wrote:> zhngbn wrote:
>> On Jul 6, 2:56 pm, dpb non.net> wrote:>
> ...
>
>>> Profile the code to first prove what you have is actually a
>>> bottleneck...like Richard, I am also skeptical this is a real problem.
>
> ...
>
>
>
>> This is the flat profile I got from gprof:
> ...
>>    4  %%  cumulative  self        self   total
>>    5  time  seconds  seconds   calls  s/call  s/call  name
>> Â Â Â 6 Â 38.95 Â Â 47.07 Â Â 47.07 Â Â 20001 Â Â 0.00 Â Â 0.00 Â derv_
>> Â Â Â 7 Â 20.59 Â Â 71.96 Â Â 24.89 Â Â 20001 Â Â 0.00 Â Â 0.00 Â second_
>> Â Â Â 8 Â 17.76 Â Â 93.42 Â Â 21.46 Â Â 20001 Â Â 0.00 Â Â 0.00 Â third_ ...
|
| Show full article (1.58Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: Jul 6, 2008 17:08
> I have heard that the build-in function anint of fortran is kind
> of slow, but I have to used it quite frequent in my code. Anyone know
> a more efficient version of it?
The Fortran definition of ANINT isn't consistent with the IEEE
rounding modes. I can't recall whether SSE has an appropriate
instruction, but in module IEEE_ARITHMETIC there is a function
IEEE_RINT which maps to normal processor arithmetic instructions:
C:\gfortran\clf\rint>type rint.f90
program rint
use IEEE_ARITHMETIC
implicit none
integer, parameter :: dp = selected_real_kind(15,300)
integer N
real(dp), allocatable :: harvest(:)
real(dp) t0,t1
integer i, j
real(dp) total
|
| Show full article (1.99Kb) |
| no comments |
|
|
Author: zhngbnzhngbn Date: Jul 6, 2008 22:56
On Jul 6, 5:08Â pm, "James Van Buskirk" comcast.net> wrote:>> Â Â I have heard that the build-in function anint of fortran is kind
>> of slow, but I have to used it quite frequent in my code. Â Anyone know
>> a more efficient version of it?
>
> The Fortran definition of ANINT isn't consistent with the IEEE
> rounding modes. Â I can't recall whether SSE has an appropriate
> instruction, but in module IEEE_ARITHMETIC there is a function
> IEEE_RINT which maps to normal processor arithmetic instructions:
>
> C:\gfortran\clf\rint>type rint.f90
> program rint
> Â Â use IEEE_ARITHMETIC
> Â Â implicit none
> Â Â integer, parameter :: dp = selected_real_kind(15,300)
> Â Â integer N ...
|
| Show full article (2.52Kb) |
| no comments |
|
|
|
|
|
Author: James Van BuskirkJames Van Buskirk Date: Jul 6, 2008 23:42
> I tried to use g95 to compile the code, but got the following error:
> In file rint.f90:30
> total = total+IEEE_RINT(1.1) !(harvest(j))
1
> Error: Too many arguments in call to 'ieee_rint' at (1)
> any idea why?
Beats me. Looks like a good question for Andy.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
| |
| no comments |
|
|
|
|
