[Mono-dev] Performance problems on ARM/linux
Rodrigo Kumpera
kumpera at gmail.com
Wed Apr 15 13:40:07 EDT 2009
Which FP mode your cpu/linux support? FPA, VFP or soft-float?
ARM_FPU_NONE enables soft-float mode, which is super slow compared
to any hardware.
On Thu, Apr 9, 2009 at 2:34 PM, Martin Fuzzey <mfuzzey at parkeon.com> wrote:
> Hi,
> I'm running mono on ARM/linux (i.MX21 processor) using svn build 130875
> (the xbuild in the 2.4 release won't build my application).
>
> It works but the performance doesn't seem very good.
> Specifically compared to the same hardware under WinCE and .NET compact
> framework i'm seeing a *6 on startup time and *7 on many operations.
>
> The mono application is compiled with xbuild / gmcs (using framework
> 2.0 rather than the CF so it's not quite a fair comparison I know).
>
> I've built mono with:
> configure: --with-tls=pthread --without-static_mono
> --without-sigaltstack --without-mcs_docs --disable-parallel-mark
> C_FLAGS: -DARM_FPU_FPA
> I'm using the SMALL_CONFIG option for the gc
> I'm not using any -enable-minimal options as I'm not worried (for the
> moment) about disk size.
>
> [I need --without-static_mono because the application accesses
> WaitForSingleObject etc - I can use the versions supplied by the iolayer
> via an assemble config file but it only works if both the mono runtime
> and the imported native DLL use the same code]
>
> Initially I used ARM_FPU_NONE but that causes floats (but not doubles)
> to fail. In particular it caused an assertion error relative the the
> load factor (which is a float) of the Hashtable class. With FPU_NONE the
> following test app gives incorrect output:
>
> using System;
>
> public class FloatTest {
>
> static void Main()
> {
> int i1 = 1;
> int i2 = 2;
> float f1 = 1.0f;
> float f2 = 1.5f;
> double d1 = 1.0;
> double d2 = 1.5;
> bool result;
>
> System.Console.WriteLine("Hello world");
> System.Console.WriteLine("i1=" + i1 + " i2=" + i2);
> System.Console.WriteLine("f1=" + f1 + " f2=" + f2);
> System.Console.WriteLine("d1=" + d1 + " d2=" + d2);
>
> result = i1 < i2;
> System.Console.WriteLine("i1 < i2 : " + result);
> result = i1 > i2;
> System.Console.WriteLine("i1 > i2 : " + result);
>
> result = f1 < f2;
> System.Console.WriteLine("f1 < f2 : " + result);
> result = f1 > f2;
> System.Console.WriteLine("f1 > f2 : " + result);
>
> result = d1 < d2;
> System.Console.WriteLine("d1 < d2 : " + result);
> result = d1 > d2;
> System.Console.WriteLine("d1 > d2 : " + result);
> }
> }
>
> [it gave gibberish values and incorrect comparisons for f1,f2 (but not
> for d1,d2)]
>
> time shows that it's mostly userspace:
>
> real 0m 51.26s
> user 0m 44.05s
> sys 0m 5.09s
>
> I've tried using
> --profile=default:stat
>
> but that gives me
>
> **
> ** ERROR:(handles.c:497):_wapi_handle_new: assertion failed:
> (_wapi_has_shut_down == FALSE)
>
> ** (fatapp/Fat_App.exe:1994): WARNING **: Thread (nil) may have been
> prematurely finalized
>
>
> Bug 445610 talks about something similar but on OS X. Should the
> profiler work on ARM??
>
> I don't think it's a gc problem because --stats gives:
> Major GC collections: 20
> Major GC time in msecs: 1012.903000
>
> ie the GC only accounts for 1s of the 50s
>
> I've tried using aot ; it compiles fine and generates a .so but when
> running it I get a segfault:
>
> Stacktrace:
>
> at System.Windows.Forms.Control.OnSizeChanged (System.EventArgs)
> <0xffffffff>
> at System.Windows.Forms.Control.OnSizeChanged (System.EventArgs) <0x00034>
> at System.Windows.Forms.Control.UpdateBounds (int,int,int,int,int,int)
> <0x00223>
> at System.Windows.Forms.Control.UpdateBounds (int,int,int,int) <0x000f3>
> at System.Windows.Forms.Control.SetBoundsCoreInternal
> (int,int,int,int,System.Windows.Forms.BoundsSpecified) <0x00383>
> at System.Windows.Forms.Control.SetBoundsCore
> (int,int,int,int,System.Windows.Forms.BoundsSpecified) <0x0005f>
> at System.Windows.Forms.Control.SetBoundsInternal
> (int,int,int,int,System.Windows.Forms.BoundsSpecified) <0x0013b>
> at System.Windows.Forms.Control.SetBounds
> (int,int,int,int,System.Windows.Forms.BoundsSpecified) <0x000ab>
> at System.Windows.Forms.Control.set_Size (System.Drawing.Size) <0x00047>
> at (wrapper remoting-invoke-with-check)
> System.Windows.Forms.Control.set_Size (System.Drawing.Size) <0xffffffff>
> at Fat_App.Form1.InitializeComponent () <0x00a63>
> at Fat_App.Form1..ctor () <0x00033>
> at (wrapper remoting-invoke-with-check) Fat_App.Form1..ctor ()
> <0xffffffff>
> at Fat_App.Program.Main () <0x00033>
> at (wrapper runtime-invoke) object.runtime_invoke_void
> (object,intptr,intptr,intptr) <0xffffffff>
>
> Native stacktrace:
>
> /usr/local/lib/libmono.so.0 [0x4012403c]
> /usr/local/lib/libmono.so.0 [0x40054350]
> /lib/libc.so.6(__default_rt_sa_restorer+0) [0x405788b0]
> /usr/local/lib/libmono.so.0 [0x40224bd0]
> /usr/local/lib/libmono.so.0 [0x40224ed4]
> /usr/local/lib/libmono.so.0 [0x40051f98]
> /usr/local/lib/libmono.so.0 [0x40052a88]
> /usr/local/lib/libmono.so.0 [0x40053750]
> /usr/local/lib/libmono.so.0 [0x40053940]
> /usr/local/lib/libmono.so.0(mono_compile_method+0x7c) [0x40180638]
> /usr/local/lib/libmono.so.0 [0x40125544]
> [0x406ad058]
>
> I don't get a full symbolic stack trace even if the binaries are not
> stripped.
> But I don't understand why it found mono_compile_method and not the others.
>
> Running the X86 version of mono (built from the same sources) has no
> problems (all the profiling options work).
> Just one strange thing in that case - even when using --aot the --stats
> output on execution shows
> Methods from AOT: 0
>
> I would much appreciate any ideas on:
> a) Why the profiling / aot stuff doesn't work
> b) Ideas for other avenues to persue
>
> Regards,
>
> Martin Fuzzey
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090415/87fc5073/attachment.html
More information about the Mono-devel-list
mailing list