Hi -
I think this is a GCC-ism.
> To me, this means that a different library is being linked after the
> compilation stage. This agrees with the manual page for 'gcc'.
My hypothesis here is that certain versions of GCC, when optimizations are
enabled, will evaluate `cbrt` at compile-time. I suspect that this compile-time
evaluation computes the operation more precisely than the runtime math library
does.
Here is a C program that shows the same behavior with GCC 8.2 (where the result
depends on whether or not optimization is enabled):
#include <math.h>
#include <stdio.h>
int main() {
double y = 0x1.0p-1044;
double cbrtX = cbrt(0x1.0p-1044);
double cbrtY = cbrt(y);
printf("cbrtX=%a\n", cbrtX);
printf("cbrtY=%a\n", cbrtY);
return 0;
}
Compiling it with the GCC flag --save-temps, I can see in the generated .s file
that with -O there are no calls to cbrt in the program, and without, there is
one.
So, I think GCC has the capability of evaluating cbrt exactly at compile-time.
But only when optimizations are enabled does it figure out that `y` in the
above program is known at compile-time.
With clang instead of GCC, or with the --llvm backend with the original Chapel
programs, we see the version with 0.5 relative error in either case. This is
because clang/--llvm does not attempt to evaluate cbrt at compile-time, and the
system math library has 0.5 relative error.
Damian, I have had trouble finding resources indicating the relative error of
system math library functions. Is that a problem in your work? It sounds like
you use a strategy of re-implementing them to achieve the precision you
require. I personally think it would be nice to be able to list the maximum
errors possible in the Math documentation, but as long as we use the system
math library, that information would be platform-dependent (besides the problem
that I wouldn't know what errors to put in the documentation even for one
platform). Of course it would be possible for our Math library to reimplement
these functions, but that seems like a pretty big undertaking and might lead to
reduced performance when comparing against C programs...
Cheers,
-michael
P.S. I think the GASNet angle has to do with how Chapel represents global
variables in multilocale programs. I observed that both values are computed at
compile-time by GCC if the test code is put into a function in a Chapel program
(rather than being file-scope). That is because the Chapel compiler applies
constant-propagation to the function-local variables case but not to the global
variables case. For GASNet, I suspect that the GCC optimization that learns the
constant value for these global variables is confused by the extra code Chapel
emits to handle global variables that might be remote.
Hi Paul,
On Wed, 6 Mar 2019, Paul Cassella wrote:
> Very strange, and puzzling, but I can't speak as to whether it's
> worrisome.
I merely raised it because something looks weird and it looks like it is
something that will stab somebody in the back. And it looked so plainly
reproducible that I figured that somebody, far more skilled than I, could
fix quickly.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
