Re: [Mono-list] More .NET and mono floating point inconsistencies
Kornél,
Thank you for looking into this issue for me. After adding a few more
explicit float conversions and removing some temporary variables, I was able
to create a version of my program that runs the same on both mono
(svn127604) and .NET. However, I am interested in what you said about
doubles. If I'm understanding correctly, if I use doubles instead of floats
I shouldn't have to worry about these rounding inconsistencies? I think we
started with doubles, but moved to floats because they were supposedly
faster, but if what you say is true, I might try and change everything over
when I have time. Checking Google only reveals that there is some conflict
as to if floats are faster than doubles in C#. Plus if I ever decide to use
the SIMD instructions, I can only do half as much work at a time. But even
if there is a performance loss it might be worth it to avoid constantly
having to test new versions for .NET/mono compatibility.
David
Kornél Pál wrote:
>
> David,
>
> I've evaluated your test cases and found that the behavior exposed by
> your tests cases is not a bug.
>
> For the first sight this seems to be a bug is MS.NET, but it isn't a bug
> of MS.NET either.
>
> ECMA specs (part3, 1.1.1 Numeric data types) explicitly state the
> following:
>
> When a floating-point value ... is put in a storage location, it is
> automatically coerced to the type of the storage location. ... However,
> the value might be retained in the internal representation for future
> use, if it is reloaded from the storage location without having been
> modified. ... This freedom to carry extra precision is not permitted,
> however, following the execution of an explicit conversion (conv.r4 or
> conv.r8) ...
>
> This means that unlike integer variables, floating point store/load
> pairs are not (necessarily) cause conversion.
>
> On the other hand if you need deterministic behavior, you should issue
> an explicit conv.r4 (x = (float)y; in C#) because this is an
> implementation detail of the current MS JIT compiler that may change in
> the future even in that compiler.
>
> Although ECMA specs permit the native float type to have additional
> precision, you will most likely never notice the same behavior with
> double (float64), because both Mono and MS.NET configure the FPU to
> round each arithmetic operations to 64-bits.
>
> Also note that there is no performance gain from using float (float32),
> because the FPU still operates in 64-bit mode that has to be converted
> to 32-bits. As a result if you want performance you shouldn't use
> float32 at all.
>
> A simplified test case:
> float f1=200;
> float f2=162.980057f;
> float f3 = (1 - (f2 / f1));
> float f4 = f3*f3;
> Console.WriteLine(f4.ToString("R", CultureInfo.InvariantCulture));
>
> Adding an extra conversion you will get the behavior of Mono on MS.NET
> as well:
> float f1=200;
> float f2=162.980057f;
> float f3 = (float)(1 - (f2 / f1));
> float f4 = f3*f3;
> Console.WriteLine(f4.ToString("R", CultureInfo.InvariantCulture));
>
> Kornél
>
> Rodrigo Kumpera wrote:
>> I have commited the fixed from Kornél for all bugs that have tests.
>>
>> On Fri, Feb 20, 2009 at 12:14 AM, ddambro > <mailto:ddam...@gmail.com>> wrote:
>>
>>
>> Hi,
>>
>> Thanks for looking into my issues. I hope my post didn't come across
>> as
>> rude or anything, I was really just looking to ask if it was better
>> to post
>> issues here or directly to Bugzilla. I'm sure there are far more
>> important
>> issues than my weird floating point inconsistencies.
>>
>> For the curious, I am an AI researcher working on Evolutionary
>> Computation.
>> I tend to use Windows and .NET to run my code, but my research group
>> has
>> several large computing clusters that could massively speed up my
>> experiments, but they only run Linux. Also academia tends to shy
>> away from
>> "Windows Only" software, so if I can say "Runs in Linux" when I
>> release my
>> code to the public, it's a pretty big boon for me as well as the
>> people who
>> want to run it. However, because of the floating point issues
>> described,
>> experiments run on mono are not compatible with experiments run on
>> .NET, as
>> over the course of a simulation, the small errors propagate over
>> thousands
>> of time steps into large differences in the final AI behavior.
>> Thus, if I
>> used both mono and .NET, not only would I have
Re: [Mono-list] More .NET and mono floating point inconsistencies
Hi,
Thanks for looking into my issues. I hope my post didn't come across as
rude or anything, I was really just looking to ask if it was better to post
issues here or directly to Bugzilla. I'm sure there are far more important
issues than my weird floating point inconsistencies.
For the curious, I am an AI researcher working on Evolutionary Computation.
I tend to use Windows and .NET to run my code, but my research group has
several large computing clusters that could massively speed up my
experiments, but they only run Linux. Also academia tends to shy away from
"Windows Only" software, so if I can say "Runs in Linux" when I release my
code to the public, it's a pretty big boon for me as well as the people who
want to run it. However, because of the floating point issues described,
experiments run on mono are not compatible with experiments run on .NET, as
over the course of a simulation, the small errors propagate over thousands
of time steps into large differences in the final AI behavior. Thus, if I
used both mono and .NET, not only would I have to be mindful of which
experiment was run on which platform when I do analysis and demonstrations,
but when I release my results to the public I would also have to mark
arbitrary sets of experiments as "mono only" or ".NET only."
Kornél Pál wrote:
>
> Hi,
>
> Thanks for the test cases, I'll invetigate these as well and try to fix
> them.
>
> The best way to get bugs fixed is to produce test cases and report them
> in buzilla.
>
> You can help more if you are able to provide a patch to fix the bugs.
>
> Note that for some reasons Novell guys seem to ignore this bug mostly
> because they have other things to do and their approval is required for
> these changes.
>
> Could you please describe your scenario (application name, purpose, etc.
> if they are public) where you need these floating point roundings and
> describe why these bugs are critical for you.
>
> Providing some description may raise component owners' attention.
>
> Kornél
>
> ddambro wrote:
>> I previously posted about some differences I noticed between the floating
>> point math in .NET and mono
>> http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-to21428695ef1367.html
>> here . The bug report can be found
>> https://bugzilla.novell.com/show_bug.cgi?id=467201 here . The patch
>> provided (Thank you!) fixes several issues I was encountering, but
>> unfortunately it led me to discover a couple more. The following two
>> code
>> samples were tested x86 machines using Linux mono 2.2 with the patch
>> found
>> in the bug report, a clean Windows mono 2.0.1, and the latest version of
>> .NET targeting 3.0 framework and x86.
>>
>> ---
>> 1.
>>
>> using System;
>> using System.Runtime.CompilerServices;
>>
>> class Testing
>> {
>> [MethodImpl(MethodImplOptions.NoInlining)]
>> public static void Main()
>> {
>> float f1=200;
>>
>> float distance=Distance(300, 500, 387.5f, 362.5f);
>>
>> float dist = 1 - (distance / f1);
>>
>> float distSqud = dist * dist;
>>
>> Console.WriteLine(distSqud.ToString("R"));
>>
>> foreach (byte b in BitConverter.GetBytes(distSqud))
>> Console.WriteLine(b);
>>
>> }
>>
>> public static float Distance(float x1, float y1, float x2, float y2)
>> {
>> float xDist = x1 - x2;
>> float yDist = y1 - y2;
>> float dist = (float)Math.Sqrt(xDist * xDist + yDist * yDist);
>> return dist;
>> }
>>
>> On .NET this code produces:
>> 0.0342619047
>> 54
>> 86
>> 12
>> 61
>>
>> and on mono it produces:
>> 0.03426191
>> 55
>> 86
>> 12
>> 61
>>
>> ---
>> 2.
>>
>> using System;
>> using System.Runtime.CompilerServices;
>>
>> class Testing
>> {
>> [MethodImpl(MethodImplOptions.NoInlining)]
>> public static void Main()
>> {
>> float distance = Distance(616.161255f, 391.2928f, 550.8382f,
>> 131.006973f);
>> Console.WriteLine(distance.ToString("R"));
>>
>> foreach (byte b in BitConverter.GetBytes(distance))
>> Console.WriteLine(b);
>> }
>>
>> public static float Distance(float x1, float y1, float x2, float y2)
>> {
>> float xDist = x1 - x2;
>> float yDist = y1 - y2;
>> float dist = (fl
[Mono-list] More .NET and mono floating point inconsistencies
I previously posted about some differences I noticed between the floating
point math in .NET and mono
http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-to21428695ef1367.html
here . The bug report can be found
https://bugzilla.novell.com/show_bug.cgi?id=467201 here . The patch
provided (Thank you!) fixes several issues I was encountering, but
unfortunately it led me to discover a couple more. The following two code
samples were tested x86 machines using Linux mono 2.2 with the patch found
in the bug report, a clean Windows mono 2.0.1, and the latest version of
.NET targeting 3.0 framework and x86.
---
1.
using System;
using System.Runtime.CompilerServices;
class Testing
{
[MethodImpl(MethodImplOptions.NoInlining)]
public static void Main()
{
float f1=200;
float distance=Distance(300, 500, 387.5f, 362.5f);
float dist = 1 - (distance / f1);
float distSqud = dist * dist;
Console.WriteLine(distSqud.ToString("R"));
foreach (byte b in BitConverter.GetBytes(distSqud))
Console.WriteLine(b);
}
public static float Distance(float x1, float y1, float x2, float y2)
{
float xDist = x1 - x2;
float yDist = y1 - y2;
float dist = (float)Math.Sqrt(xDist * xDist + yDist * yDist);
return dist;
}
On .NET this code produces:
0.0342619047
54
86
12
61
and on mono it produces:
0.03426191
55
86
12
61
---
2.
using System;
using System.Runtime.CompilerServices;
class Testing
{
[MethodImpl(MethodImplOptions.NoInlining)]
public static void Main()
{
float distance = Distance(616.161255f, 391.2928f, 550.8382f,
131.006973f);
Console.WriteLine(distance.ToString("R"));
foreach (byte b in BitConverter.GetBytes(distance))
Console.WriteLine(b);
}
public static float Distance(float x1, float y1, float x2, float y2)
{
float xDist = x1 - x2;
float yDist = y1 - y2;
float dist = (float)Math.Sqrt(xDist * xDist + yDist * yDist);
Console.WriteLine(dist.ToString("R"));
foreach (byte b in BitConverter.GetBytes(dist))
Console.WriteLine(b);
return dist;
}
}
On .NET this code produces:
268.3576
198
45
134
67
268.3576
198
45
134
67
and on mono it produces:
268.357635
199
45
134
67
268.357635
199
45
134
67
---
These seem to be very similar to the issues I was encountering before, but
they are not fixed by the patch. What is the best way to resolve these
inconsistencies?
Thanks,
David
--
View this message in context:
http://www.nabble.com/More-.NET-and-mono-floating-point-inconsistencies-tp22018718p22018718.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
I get the same results using Kornél's code. Using Robert's code compiled as
x86, run on various machines, OSes, and runtimes, I get the byte values as:
.NET:
169
192
42
63
mono:
168
192
42
63
So if this is a rounding issue, is there any way to get the two to round the
same? I think I've pretty much eliminated John's FPU suggestion as I went
through all the rounding flags and none of them matched .NET, and this issue
occurs in both Windows and Linux.
Kornél Pál wrote:
>
> Hi,
>
> This seems to me a float32 rounding problem because when using float64 I
> get the same results.
>
> Code:
>
> using System;
>
> class Testing
> {
> public static void Main()
> {
> float f1 = 0;
> f1 += -0.7779751f;
>
> Console.Write("0x");
> foreach (byte b in BitConverter.GetBytes(f1))
> Console.Write (b.ToString("x2"));
> Console.WriteLine();
> Console.WriteLine(f1.ToString("R"));
>
> f1 += -1f * -1.42317927f;
>
> Console.Write("0x");
> foreach (byte b in BitConverter.GetBytes(f1))
> Console.Write (b.ToString("x2"));
> Console.WriteLine();
> Console.WriteLine(f1.ToString("R"));
>
> f1 += -1.30905056f * 0.241778925f;
>
> Console.Write("0x");
> foreach (byte b in BitConverter.GetBytes(f1))
> Console.Write (b.ToString("x2"));
> Console.WriteLine();
> Console.WriteLine(f1.ToString("R"));
>
> f1 = (2.0F / (1.0F + (float)Math.Exp(-4.9F * f1))) - 1.0F;
>
> Console.Write("0x");
> foreach (byte b in BitConverter.GetBytes(f1))
> Console.Write (b.ToString("x2"));
> Console.WriteLine();
> Console.WriteLine(f1.ToString("R"));
> }
> }
>
> The last value is different indeed (I only thested on Windows):
> MS:
> 0xa9c02a3f
> 0,667002261
>
> Mono:
> 0xa8c02a3f
> 0,6670022
>
> Hex value is different for me as well.
>
> Kornél
>
> Robert Jordan wrote:
>> ddambro wrote:
>>> Hi,
>>>
>>> I was fairly sure the code had executed. As I mentioned, different
>>> flags in
>>> the C code caused errors in the program. Just to be sure though, I
>>> threw in
>>> some fprintf statements to stderr into setFloats() and they printed
>>> properly, so the code was definitely executed.
>>>
>>> Thankfully I have been able to come up with some code that shows at
>>> least
>>> one example of the inconsistencies I've been talking about. Here it is:
>>
>> It's just a string representation mismatch, as this code reveals the
>> same bits:
>>
>> Console.WriteLine(f1.ToString("R"));
>>
>> foreach (byte b in BitConverter.GetBytes(f1))
>> Console.WriteLine (b);
>>
>> Robert
>>
>> ___
>> Mono-list maillist - Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
> ___
> Mono-list maillist - Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
--
View this message in context:
http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21537058.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
Hi,
I was fairly sure the code had executed. As I mentioned, different flags in
the C code caused errors in the program. Just to be sure though, I threw in
some fprintf statements to stderr into setFloats() and they printed
properly, so the code was definitely executed.
Thankfully I have been able to come up with some code that shows at least
one example of the inconsistencies I've been talking about. Here it is:
using System;
class Testing
{
public static void Main()
{
float f1 = 0;
f1 += -0.7779751f;
Console.WriteLine(f1.ToString("R"));
f1 += -1f * -1.42317927f;
Console.WriteLine(f1.ToString("R"));
f1 += -1.30905056f * 0.241778925f;
Console.WriteLine(f1.ToString("R"));
f1 = (2.0F / (1.0F + (float)Math.Exp(-4.9F * f1))) - 1.0F;
Console.WriteLine(f1.ToString("R"));
}
}
.NET gives me:
-0.7779751
0.6452042
0.328703344
0.667002261
While mono gives me:
-0.7779751
0.6452042
0.328703344
0.6670022
If I remove the roundtrip specifiers (the "R" in the toString() call) .NET
gives me:
-0.7779751
0.6452042
0.3287033
0.6670023
while mono gives:
-0.7779751
0.6452042
0.3287033
0.6670022
Also, if I take away the "- 1.0F" in the 2nd to last line, making it:
f1 = (2.0F / (1.0F + (float)Math.Exp(-4.9F * f1)));
Then both mono and .NET give me the same set of answers:
-0.7779751
0.6452042
0.328703344
1.6670022
I've run the same binary on .NET and both Windows and Linux mono (2.0.2) on
various computers and have consistently gotten these results. The results
are the same on mono 2.2 on Linux as well. Maybe it's some sort of
inconsistency in rounding, but in the other instances I've found (but
haven't explored to this depth) sometimes mono will round higher than .NET
and sometimes .NET will round higher. I tried the other 3 rounding flags in
the FPU code (UP, DOWN, and ZERO) with my main code and while they each
produced different results, none of them matched the results I get with
.NET. Any suggestions would be appreciated.
Thanks,
David
Kornél Pál wrote:
>
> Hi,
>
> DLLs are Windows specific are you sure you actually executed setFloats()
> on Linux?
>
> If you are unable to solve this issue using control flags we can't
> figure out what your problem is without providing us a test case that
> exhibits this behavior.
>
> Please create a source code (can be as small as your wish) that can be
> compiled without modifications so that other people will be able to
> reproduce the problem.
>
> Kornél
>
> ddambro wrote:
>> I tried the FPU flags as follows:
>> 1.Compiled the following file to a dll using gcc on a test linux system:
>> #include
>>
>> void setFloats()
>> {
>> fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM |
>> _FPU_MASK_PM
>> |_FPU_DOUBLE | _FPU_RC_NEAREST ;
>> _FPU_SETCW( desired);
>> }
>>
>> 2.Added the following code to my main class in the C# code:
>> [DllImport("./floatTest.dll")]
>> public static extern void setFloats();
>>
>> 3.Called setFloats() before any other code.
>>
>> The end results were the exact same as all my other mono runs and thus
>> different than my .NET runs. The C code without the masks caused my
>> program
>> to throw divided by zero exceptions from Console.Writeline() and
>> File.Exists(). Are there other flags I can try or does the fact that
>> this
>> happens on Windows mono and Linux mono point to something other than the
>> FPU
>> setup? I'll keep looking for the exact spot where inconsistencies start
>> to
>> happen and just to try it, I'm compiling mono 2.2 on a test machine to
>> see
>> if that changes anything (everything so far has been on 2.0.2).
>>
>> David
>>
>>
>> Kornél Pál wrote:
>>> Hi,
>>>
>>> Please try the FPU flags suggested John to see if that solves your
>>> problem, modifying the control flags could be added to x86 versions of
>>> Mono so you wouldn't have to modify them manually.
>>>
>>> Kornél
>>>
>>> ddambro wrote:
>>>> The code is compiled for x86 in Windows, and the problems I describe
>>>> persist
>>>> even using mono for Windows. That is, on every computer I've tried so
>>>> far
>>>> regardless of OS and processor type, all of the mono runs produce the
>>>> same
>>>> results and all of the .NET runs produce the same results, but these
>>>> results
>>>> are different from each other. This includes a 64-bit Vista machine
>>>> running
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
I tried the FPU flags as follows:
1.Compiled the following file to a dll using gcc on a test linux system:
#include
void setFloats()
{
fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM
|_FPU_DOUBLE | _FPU_RC_NEAREST ;
_FPU_SETCW( desired);
}
2.Added the following code to my main class in the C# code:
[DllImport("./floatTest.dll")]
public static extern void setFloats();
3.Called setFloats() before any other code.
The end results were the exact same as all my other mono runs and thus
different than my .NET runs. The C code without the masks caused my program
to throw divided by zero exceptions from Console.Writeline() and
File.Exists(). Are there other flags I can try or does the fact that this
happens on Windows mono and Linux mono point to something other than the FPU
setup? I'll keep looking for the exact spot where inconsistencies start to
happen and just to try it, I'm compiling mono 2.2 on a test machine to see
if that changes anything (everything so far has been on 2.0.2).
David
Kornél Pál wrote:
>
> Hi,
>
> Please try the FPU flags suggested John to see if that solves your
> problem, modifying the control flags could be added to x86 versions of
> Mono so you wouldn't have to modify them manually.
>
> Kornél
>
> ddambro wrote:
>> The code is compiled for x86 in Windows, and the problems I describe
>> persist
>> even using mono for Windows. That is, on every computer I've tried so
>> far
>> regardless of OS and processor type, all of the mono runs produce the
>> same
>> results and all of the .NET runs produce the same results, but these
>> results
>> are different from each other. This includes a 64-bit Vista machine
>> running
>> the x86 code in .NET and mono (installed as x86). How would this affect
>> your suggested fix? Also I noticed a fairly significant speed up when I
>> converted all my doubles to floats in this code a few years ago, would
>> your
>> fix undo that? mono already runs the code MUCH slower than .NET so I'd
>> hate
>> to get another performance hit.
>>
>>
>> Dallman, John-2 wrote:
>>>> when I take the same binary and run it with the same inputs it
>>>> produces different outputs if it is run on mono and .Net.
>>> This is with Mono on Linux, and .NET on Windows? The executable
>>> is 32-bit .NET code?
>>>
>>> I suspect that you've hit a misfeature that exists for most
>>> floating-point code on 32-bit x86 Linux.
>>>
>>> The code to be run in the C function is:
>>>
>>> #include /* Mask the Denormal, Underflow and Inexact
>>> exceptions,
>>> leaving Invalid, Overflow and
>>> Zero-divide active.
>>> Set precision to standard doubles,
>>> and round-to-nearest. */
>>> fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM |
>>> _FPU_DOUBLE | _FPU_RC_NEAREST ;
>>> _FPU_SETCW( desired);
>>>
>>> This needs to be a C function because everything in uppercase in
>>> that code is a macro, from fpu_control.h. You may want to leave out
>>> enabling floating point traps, in which case the code becomes:
>>>
>>> #include /* Set precision to standard doubles, and
>>> round-to-nearest. */
>>> fpu_control_t desired = _FPU_DOUBLE | _FPU_RC_NEAREST ;
>>> _FPU_SETCW( desired);
>>>
>>> It would be good, really, if Mono had a standard call for setting
>>> up consistent floating-point on all its platforms.
>>>
>>> --
>>> John Dallman
>>> Parasolid Porting Engineer
>>>
>>> Siemens PLM Software
>>> 46 Regent Street, Cambridge, CB2 1DP
>>> United Kingdom
>>> Tel: +44-1223-371554
>>> john.dall...@siemens.com
>>> www.siemens.com/plm
>>> ___
>>> Mono-list maillist - Mono-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-list
>>>
>>>
>>
> ___
> Mono-list maillist - Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
--
View this message in context:
http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21522156.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
The code is compiled for x86 in Windows, and the problems I describe persist even using mono for Windows. That is, on every computer I've tried so far regardless of OS and processor type, all of the mono runs produce the same results and all of the .NET runs produce the same results, but these results are different from each other. This includes a 64-bit Vista machine running the x86 code in .NET and mono (installed as x86). How would this affect your suggested fix? Also I noticed a fairly significant speed up when I converted all my doubles to floats in this code a few years ago, would your fix undo that? mono already runs the code MUCH slower than .NET so I'd hate to get another performance hit. Dallman, John-2 wrote: > >> when I take the same binary and run it with the same inputs it >> produces different outputs if it is run on mono and .Net. > > This is with Mono on Linux, and .NET on Windows? The executable > is 32-bit .NET code? > > I suspect that you've hit a misfeature that exists for most > floating-point code on 32-bit x86 Linux. > > The code to be run in the C function is: > > #include /* Mask the Denormal, Underflow and Inexact > exceptions, > leaving Invalid, Overflow and > Zero-divide active. > Set precision to standard doubles, > and round-to-nearest. */ > fpu_control_t desired = _FPU_MASK_DM | _FPU_MASK_UM | _FPU_MASK_PM | > _FPU_DOUBLE | _FPU_RC_NEAREST ; > _FPU_SETCW( desired); > > This needs to be a C function because everything in uppercase in > that code is a macro, from fpu_control.h. You may want to leave out > enabling floating point traps, in which case the code becomes: > > #include /* Set precision to standard doubles, and > round-to-nearest. */ > fpu_control_t desired = _FPU_DOUBLE | _FPU_RC_NEAREST ; > _FPU_SETCW( desired); > > It would be good, really, if Mono had a standard call for setting > up consistent floating-point on all its platforms. > > -- > John Dallman > Parasolid Porting Engineer > > Siemens PLM Software > 46 Regent Street, Cambridge, CB2 1DP > United Kingdom > Tel: +44-1223-371554 > john.dall...@siemens.com > www.siemens.com/plm > ___ > Mono-list maillist - Mono-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > > -- View this message in context: http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21512975.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
The code is compiled to x86 and is being run on several processor types, but the only thing that seems to noticeably differentiate the results is .NET and mono e.g. .NET on an Intel and Amd produce the same results which are different than mono's results. I am adding traces and I think I'm getting close, I've narrowed down the general area where things start to diverge and hopefully I'll have a solution or code sample I can share shortly. The problem I'm having is not so much accuracy (I'm using floats instead of doubles) but rather precision. The issue I'm afraid of is that I get simulation that looks good, but then when I go to show it off, I have to know if it was run on a mono machine or .NET, which is doable, but something I'd prefer to avoid. It's also not the minor inconsistencies that bother me, it's the fact that they build up and magnify over several thousand time steps which in turn create rather large differences by the end. russell.kay wrote: > > If they are running under different architectures[*] then you will > definitely see difference in floating point arithmetic. > > i.e. 32 bit x86 code uses the Floating Point Unit to do all the float > and double calculations, 64 bit x64 code uses SIMD to do all the > floating point and double calculations. > > This leads to differences across architectures, so if you were checking > mono x86 against mono x86 there should be little that is divergent, > however if you are using .NET x86 against mono x86 there may well be > differences because of libraries that are implemented differently (to > different accuracies). > > If you need them all to be the same you would be best to add traces to > the code to track down where things start to diverge and I would suspect > any library functions until you convince yourself that they are not the > source of any problem. > > Also some optimisations may well change the ordering of floating point > code which may change the result in subtle ways. > > Basically it is a bad idea to rely on absolute accuracy across machines > (even between intel cpus of different generations) in a network > situation, you have to relax the requirement for accuracy and go for > something that "is good enough". > > Game programmers have been living with this for quite some time now. > > Russell > > [*] You will also see differences with CPUs from different manufacturers > (intel or amd) and with CPUs of different generations (Pentium4 agains > Core2Duo). > > -Original Message- > From: mono-list-boun...@lists.ximian.com > [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of ddambro > Sent: 13 January 2009 22:29 > To: mono-list@lists.ximian.com > Subject: Re: [Mono-list] Mono and .Net Floating Point Inconsistencies > > > > > kuse wrote: >> >> >> >> ddambro wrote: >>> >>> Hello, >>> >>> I have a floating point heavy simulation written in C# that I am >>> interested in running in Linux. The simulator runs fine in mono, but >>> I've noticed that when I take the same binary and run it with the > same >>> inputs it produces different outputs if it is run on mono and .Net. > From >>> I can tell, these inconsistencies are the result of slight > differences in >>> the floating point calculations. It is important to my experiments > that >>> an arbitrary machine (running .Net or mono) can reproduce the same >>> results as another arbitrary machine. Thus, I am curious as to if > this >>> is a known issue and if there is any way to force .Net and mono to >>> produce the same output with respect to floating point calculations. >>> >>> Thanks, >>> David >>> >> >> Provide a simple test case so other people can test it and try to find >> whats causing this. >> >> > > Unfortunately, the program in question is fairly large, complex, and > multi-threaded, so it's difficult to pinpoint the exact section of code > where the two begin to diverge. I'll keep looking and will certainly > post > an example if I find one. For now though, are there any known > conditions > that cause these inconsistencies? I make use of many functions in > System.Math, and do some double to float casting, could either of these > lead > to my problems? > -- > View this message in context: > http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp214 > 28695p21445881.html > Sent from the Mono - General mailing list archive at Nabble.com. > > ___ > Mono-list maillist - Mono-list@lists.ximian.
Re: [Mono-list] Mono and .Net Floating Point Inconsistencies
kuse wrote: > > > > ddambro wrote: >> >> Hello, >> >> I have a floating point heavy simulation written in C# that I am >> interested in running in Linux. The simulator runs fine in mono, but >> I've noticed that when I take the same binary and run it with the same >> inputs it produces different outputs if it is run on mono and .Net. From >> I can tell, these inconsistencies are the result of slight differences in >> the floating point calculations. It is important to my experiments that >> an arbitrary machine (running .Net or mono) can reproduce the same >> results as another arbitrary machine. Thus, I am curious as to if this >> is a known issue and if there is any way to force .Net and mono to >> produce the same output with respect to floating point calculations. >> >> Thanks, >> David >> > > Provide a simple test case so other people can test it and try to find > whats causing this. > > Unfortunately, the program in question is fairly large, complex, and multi-threaded, so it's difficult to pinpoint the exact section of code where the two begin to diverge. I'll keep looking and will certainly post an example if I find one. For now though, are there any known conditions that cause these inconsistencies? I make use of many functions in System.Math, and do some double to float casting, could either of these lead to my problems? -- View this message in context: http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21445881.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono and .Net Floating Point Inconsistencies
Hello, I have a floating point heavy simulation written in C# that I am interested in running in Linux. The simulator runs fine in mono, but I've noticed that when I take the same binary and run it with the same inputs it produces different outputs if it is run on mono and .Net. From I can tell, these inconsistencies are the result of slight differences in the floating point calculations. It is important to my experiments that an arbitrary machine (running .Net or mono) can reproduce the same results as another arbitrary machine. Thus, I am curious as to if this is a known issue and if there is any way to force .Net and mono to produce the same output with respect to floating point calculations. Thanks, David -- View this message in context: http://www.nabble.com/Mono-and-.Net-Floating-Point-Inconsistencies-tp21428695p21428695.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
