Re: XS optimization bug?

The first step would be to determine whether the value is different before you pass it through the XS interface back to Perl. Pick the smallest test that demonstrates the problem and add code to dump the value(s) to STDERR (or a file) within the C subroutine just prior to returning them.

I'd suggest dumping the 8-byte doubles in raw hex (or even binary), rather than formatted ascii, as different implementations of (s)printf can introduce changes that cloud the issues.

If you can isolate where the issues arise, it may give you a clue as to what causes it.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: XS optimization bug?

Replies are listed 'Best First'.
Re^2: XS optimization bug? by Anonymous Monk on Apr 11, 2009 at 12:39 UTC
Thanks to all that have commented. The Linux perl's weren't build with -Duselongdouble and the GCC versions are the same (well, the major points are the same). The same CPU is being used, albeit with the Linux version running under VM. I have tried other machines/OS/GCC versions and I get the same results. I have started to create smaller test cases. The following is a perl print out from the C structure when run under win32 (regardless of O level) and Linux (-O0) and Linux (regardless of O level) when ran via Valgrind: `170 : -25 171 : 9 172 : -28.0000000000005 173 : 25 174 : -156 175 : 26.0000000000005 176 : -50 177 : 34.0000000000005 178 : 36 179 : -10 180 : 22 181 : -70` [download] The following is a perl print out from the C structure when ran under Linux when compiled with optimization (1,2 or 3): `170 : -25 171 : 8.99999999999963 172 : -28.0000000000001 173 : 25 174 : -156 175 : 26.0000000000005 176 : -50 177 : 34.0000000000003 178 : 37.0000000000005 179 : -10.0000000000001 180 : 21.9999999999999 181 : -70.0000000000003` [download] I would expect to see differences of 0000000000003, but if you look at line 178 you'll notice a much larger difference and it's this that is causing the test script to fail. As yet, I dont know what is causing this difference...	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: XS optimization bug?
by Anonymous Monk on Apr 11, 2009 at 12:39 UTC

I have started to create smaller test cases. The following is a perl print out from the C structure when run under win32 (regardless of O level) and Linux (-O0) and Linux (regardless of O level) when ran via Valgrind:

170 : -25
171 : 9
172 : -28.0000000000005
173 : 25
174 : -156
175 : 26.0000000000005
176 : -50
177 : 34.0000000000005
178 : 36
179 : -10
180 : 22
181 : -70
[download]

The following is a perl print out from the C structure when ran under Linux when compiled with optimization (1,2 or 3):

170 : -25
171 : 8.99999999999963
172 : -28.0000000000001
173 : 25
174 : -156
175 : 26.0000000000005
176 : -50
177 : 34.0000000000003
178 : 37.0000000000005
179 : -10.0000000000001
180 : 21.9999999999999
181 : -70.0000000000003
[download]

I would expect to see differences of 0000000000003, but if you look at line 178 you'll notice a much larger difference and it's this that is causing the test script to fail. As yet, I dont know what is causing this difference...

[reply]
[d/l]
[select]