[Mono-list] mcs compiles on linux. Now what?

[Joe Tennies]

Is that REALLY such a concern?  Couldn't the big selling point be "we work
on Linux and Solaris and *BSD and MacOS X.1 and Windows!"

Speed is going to be a variable thing anyways.  Every good programmer knows
this about JIT code.  Look at Java.  The implementations are just straight
up faster now than they were a couple years ago.  Speed is also currently no
where near the issue completeness is.  If this turns out to be a huge
problem later, we can fix it.  If we constantly fix what we have now, we'll
nevr compete because we'll never have finished.

BTW: I know it's all nice and good to get all this profiled info and speed
things up, but is it getting us closer to complete self hosting?  I guess I
really don't know, but I'd assume not.  Is this profiling getting us closer
to a feature complete mono environment?

-----Original Message-----
From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On
Behalf Of Bob Smith
Sent: Friday, March 08, 2002 2:24 PM
To: Paolo Molaro
Cc: mono-list@ximian.com
Subject: Re: [Mono-list] mcs compiles on linux. Now what?


Hmm. And such huge useless loops could be used by Microsoft to produce
binaries that run slowly on any .Net JITer/interpriter that dont optomize
it away. It could be used to clame that .Net is faster then mono. Should
watch out for this. :)

On Fri, 8 Mar 2002, Paolo Molaro wrote:

> On 03/08/02 Martin Baulig wrote:
> > if we're talking about optimizations, won't it make more sense to
> > do the optimization based on profiling data from mcs run with mono,
> > not with mint ?
>
> This is a good point, but we work with the data we have :-)
> It would be excellent if someone contributed a profiler for the
> code generatd by the jit. I already posted some time ago profile data
> for the JIT itself.
>
> > If we start optimizing based on profiling data from mint, we may end
> > up trying to "optimize away" small functions which are inlined by
> > the runtime, but which need a function call in mint.
> [...]
> > If I understand this correctly, this'll result in one million function
> > calls when run with mint, but will look more like
> >
> > ====
> >         public static void TestIt ()
> >         {
> >                 long result = 0;
> >
> >                 for (long count = 0; count < 1000000; count++)
> >                         result++;
> >         }
> > ====
> >
> > when run with mono, so it won't make much sense to optimize this.
>
> There is hope this can result in the following code with an optimizing
> JIT:
>
>          public static void TestIt ()
>          {
>          }
>
> ;-)
> Note that the interpreter could start inlining some methods as well,
> so I don't think there will be a huge difference in the profile data.
>
> > Same in the Array.Copy implementation, the code currently does
> > something like
> >
> >         for (int i = 0; i < count; i++)
> >         {
> >                 object value = array.GetValue (i);
> >                 array.SetValue (value, i);
> >         }
> >
> > which are 2*count function calls in mint, but the same than implementing
> > this function in C when run in mono.
>
> This is a perfect reason for avoiding internalcalls that do the checks:
> if you have the check in C# code, the jit will use the generic code to
> optimize them away, but if you hide the checks in the internalcall
> the jit will either have to hand-craft the checks or suffer them even if
> they are not needed.
>
> > Btw. does mcs already run with mono, or what needs to be done to make
> > it run with it ?
>
> >From my tests mono works with mcs just as well as mint, but it doesn't
> work with garbage collection enabled and that prevents it's use in
> compiling large programs.
>
> lupus
>
> --
> -----------------------------------------------------------------
> lupus@debian.org                                     debian/rules
> lupus@ximian.com                             Monkeys do it better
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>


_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list