[Mono-dev] mono numerical performance

2011-11-19 Thread Jonathan Shore
I write scientific numerical algorithms that are very data / array intensive.  Having recently moved from using the JVM to the Mono CLR, was curious about the pure numerical performance against arrays.   Towards this end, wrote a partial matrix class and driver around it to test performance across

Re: [Mono-dev] mono numerical performance

2011-11-19 Thread Jonathan Shore
Slide, not really. If mono SIMD had a more general mapping to the GPU, or could operate on very large vectors or matrices, possibly. Linear algebra is an easy mapping to that stuff. However, I do more complicated stuff around timeseries, so does not really fit into linear alg stuff. I gues

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Stefanos A.
2011/11/20 Jonathan Shore > Slide, not really. If mono SIMD had a more general mapping to the GPU, or > could operate on very large vectors or matrices, possibly. Linear algebra > is an easy mapping to that stuff. However, I do more complicated stuff > around timeseries, so does not really f

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
Did the code I attached get filtered? I'll post the tar.gz into bugzilla and send the link. Below are code snippets to calculate Ordinary Least Squares, a simpler example. I found this to be 4x slower than C++ / Java: Here is the "safe" and "unsafe" versions of OLS which I ran on an array si

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
Here is a link to and entry in bugzilla with attached code. I could not send to the list: http://bugzilla.xamarin.com/show_bug.cgi?id=2098 On Nov 20, 2011, at 7:41 AM, Jonathan Shore wrote: > Did the code I attached get filtered? I'll post the tar.gz into bugzilla and > send the link. > > B

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Konrad M.
Hi, I'd like to add that you may gain something on MS JIT compiler using for (int i = 0 ; i < x.Length ; i++) instead of for (int i = 0 ; i < len ; i++) This may seem counter intuitive, however that's the scenario in which JIT eliminates array bound checking for the x array (however not for the

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
Thanks, Zoltan pointed out that the performance under LLVM is pretty good, so I probably did not have LLVM enabled. Indeed I checked and found that to be the case (my bad). As for the pattern you mention, aware that mono is able to avoid checks in that scenario. More often then not, though,

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Konrad M.
Hi again, > > It is too bad that one cannot declare a primitive expression to be > locally const in C#. Maybe one could get away with something like this: public struct FinalBox { public FinalBox(T value) { this.value = value; } public T Va

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
Yes, I see what you are doing. There is no way to modify the structure. However doesn't it still boil down to determining whether a local variable reference is changed. So for instance: FinalBox len = for (int i = 0 ; i < len ; i++) vs var len = for (int i = 0 ; i < len ; i++)

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Konrad M.
On Sun, 2011-11-20 at 12:33 -0500, Jonathan Shore wrote: > Yes, I see what you are doing. There is no way to modify the structure. > However doesn't it still boil down to determining whether a local variable > reference is changed. Yeah, exactly, this is rather pointless construct ;) There sho

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Konrad M.
On the other hand, maybe it could be possible to add the final-like mechanism to Mono's compiler. Such mechanism would be beneficial if the CLR had some notion of local readonly variables. F# uses non-mutable variables a lot, so maybe CLR recognizes it. I am not sure what kind of transparent denota

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Dawid Weiss
As far as I know the final on local variables is only a hint for the java compiler (javac), not jit (hotspot) engine. Detection of loop invariants is done at runtime (during code jitting) so there's really no difference between any of the following in modern Java jits: 1) (final) int max = array.l

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
Yes, the modern java JIT does not need final as does the analysis. However, it is very nice to be able to specify constness, not only to help the JIT along, but also in terms of documenting intent. Given that C# does not have such a construct (too bad) / const is too constrained, the next be

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Konrad M.
On Sun, 2011-11-20 at 19:39 +0100, Dawid Weiss wrote: > > > As far as I know the final on local variables is only a hint for the > java compiler (javac), not jit (hotspot) engine. Detection of loop > invariants is done at runtime (during code jitting) so there's really > no difference between any

Re: [Mono-dev] mono numerical performance

2011-11-20 Thread Jonathan Shore
On Nov 20, 2011, at 2:28 PM, Konrad M. Kruczyński wrote: > Maybe that's the reason there is no local readonly in the C# language - > local variables are easily trackable. As to those used in closures (as > mentioned by Jonathan) - as far as I know, they aren't local variables > actually but rathe