Hi.
I can't find any information on what platforms are currently supported
by Mono.Simd. In particular, is Mono.Simd hardware accelerated on
iPhone and Android?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Only x86 and amd64 are supported.
On Mon, Apr 16, 2012 at 9:22 AM, Alexander Mezin
mezin.alexan...@gmail.comwrote:
Hi.
I can't find any information on what platforms are currently supported
by Mono.Simd. In particular, is Mono.Simd hardware accelerated on
iPhone and Android?
This patch is contributed under the MIT license
I don't have push access to the main repository, so please
commit the patch yourself.
This is an oversight, could I have your GitHub account so I can add you
to the group?
___
Mono-devel-list
This patch is contributed under the MIT license
I don't have push access to the main repository, so please
commit the patch yourself.
Ah, never mind, found you: robert-j
You are now part of the Mono commit team.
___
Mono-devel-list mailing
Hi Rodrigo,
On 07.09.2010 02:32, Rodrigo Kumpera wrote:
Robert, can you commit your patch after you state the license of it? Either
via email
on MDL or on the commit message.
This patch is contributed under the MIT license
I don't have push access to the main repository, so please
Robert, can you commit your patch after you state the license of it? Either
via email
on MDL or on the commit message.
On Wed, Aug 25, 2010 at 11:56 PM, Rodrigo Kumpera kump...@gmail.com wrote:
a
On Mon, Aug 23, 2010 at 7:01 PM, Robert Jordan robe...@gmx.net wrote:
On 23.08.2010 23:13,
I think you missed the important part of that last email. If wanted you to
state the license of the patch, then commit it :)
Alan.
On 27 Aug 2010 02:10, Jerry Maine - KF5ADY crashfou...@gmail.com wrote:
Please, I found this bug to be very annoying as it hampers the use of
dynamic languagues
Please, I found this bug to be very annoying as it hampers the use of
dynamic languagues with Mono.Simd. I found this bug trying to use
mono.simd in ironpython.
On 08/25/2010 09:56 PM, Rodrigo Kumpera wrote:
a
On Mon, Aug 23, 2010 at 7:01 PM, Robert Jordan robe...@gmx.net
Well, I tried to make find a place would have system properties store
where a key like mono.simd.accel could be used to get back the
available acceleration capabilities. It could make the code a bit
cleaner with not making a internal method call inside the Mono.Simd
assembly.
Any ideas where
a
On Mon, Aug 23, 2010 at 7:01 PM, Robert Jordan robe...@gmx.net wrote:
On 23.08.2010 23:13, Rodrigo Kumpera wrote:
I think it's easier to catch the security exception under MS since its
accell mode is None anyway.
I had to move icall's call site outside the .cctor and mark
the call
On 23.08.2010 13:16, Robert Jordan wrote:
On 23.08.2010 04:53, Jerry Maine - KF5ADY wrote:
I found a discrepency in Mono.Simd.SimdRuntime.AccelMode and it is
equivalent access by reflection. I believe this is a bug.
Attached is a test for this. I believe there are more cases of this in
Would the c# portion of the patch work on MS .Net?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
On 23.08.2010 19:24, Jerry Maine wrote:
Would the c# portion of the patch work on MS .Net?
Dammit! I thought the icall would be ignored by MS.NET because
I took care of not invoking it in this case. But icalls are not
allowed in assemblies != mscorlib under MS.NET.
Unless I'm misguided, the
On Mon, Aug 23, 2010 at 3:29 PM, Robert Jordan robe...@gmx.net wrote:
On 23.08.2010 19:24, Jerry Maine wrote:
Would the c# portion of the patch work on MS .Net?
Dammit! I thought the icall would be ignored by MS.NET because
I took care of not invoking it in this case. But icalls are not
On 23.08.2010 23:13, Rodrigo Kumpera wrote:
I think it's easier to catch the security exception under MS since its
accell mode is None anyway.
I had to move icall's call site outside the .cctor and mark
the call site's method as non-inlineable to make this work.
Thanks for the hint.
I have an alternate idea that I'd like to research. It may lead to a
cleaner implementation.
On Mon, Aug 23, 2010 at 5:01 PM, Robert Jordan robe...@gmx.net wrote:
On 23.08.2010 23:13, Rodrigo Kumpera wrote:
I think it's easier to catch the security exception under MS since its
accell mode
I found a discrepency in Mono.Simd.SimdRuntime.AccelMode and it is
equivalent access by reflection. I believe this is a bug.
Attached is a test for this. I believe there are more cases of this in
Mono.Simd
Any ideas on how to fix this?
using System;
using Mono.Simd;
namespace simd
{
class
Hello Rodrigo and all,
Returning to my old problem which deals with alignment of vector variables.
I noticed that on x86 vector locals are aligned at 8-byte boundary instead
of 16-byte thus causing to use 'movups' instead of much more efficient
'movaps'.
On PowerPC there is no such bug, so I
The way to handle those situations is to have a arch decomposition pass that
converts MULPS into a VZERO + MULADD.
For bonus points, you can add to the arch peephole code to fuse MULPS +
ADDPS.
For an example of that, take a look at mini-x86.c /
mono_arch_decompose_opts.
Rodrigo
On Tue, Feb 9,
Hi,
Now I'm stuck with another problem on PPC. For multiplication of floats
Altivec has only a fuse-add instruction which does a*b+c. So in order to
implement OP_MULPS I need to assure c==0. The only solution which comes to
mind is:
XZERO D
MULADD D = S1, S2, D
Where MULADD is the instruction and
Hi Sergei,
On Tue, Feb 2, 2010 at 6:59 AM, Sergei Dyshel qyron.priv...@gmail.comwrote:
Hello all,
I'm currently working on PowerPC port of Mono which utilizes AltiVec SIMD
instructions. During the development I've encountered an alignment problem:
As far as I understood from running Mono's
Hello all,
I'm currently working on PowerPC port of Mono which utilizes AltiVec SIMD
instructions. During the development I've encountered an alignment problem:
As far as I understood from running Mono's JIT, stack-allocated
Mono.Simd.Vector* types are always aligned by 16 byte bound, but global
As part of my free time, I decided to start down the path to SIMD-ing
some cryptography algorithms. As a starter exercise, I took Threefish256
from the SHA-3 submission Skein. The experience was very enlightening,
and as I haven't been able to find anything of substance out there about
working
Hey,
The big issue you're having is that you haven't implemented a SIMD algorithm
;) I spent 15 mins 'optimising' your code and came up with this. Notice that
I made everything a SIMD operation. There is no scalar code in the method
anymore. This tripled performance as compared to the non-SIMD
Hey,
The C++ code seems very similar to the C# SIMD code, so I don't know what
would make the C# version any faster. This question would be best directed
at jit guys, who may know what causes the difference.
If you want to try speeding up the mono version, you should just use trial
and error to
I have done some performance tests of SIMD under windows.
Results tests in ms:
In MS C 235 (Visual Studio Release Mode With SIMD)
In MS C 360 (Visual Studio Release Mode With 4D Float)
In Mono C#453 (With Mono SIMD)
In Mono C#562 (With Mono 4D Float)
In MS C#
Oh,
BTW, there are 2 issues with your program.
The following code is wrong mi.GetParameters() [i].GetType(), it should be
mi.GetParameters() [i].ParameterType otherwise you'll be querying for
ParameterInfo class instead of what you want.
The other one is minor, in that some functions might not
The following code is wrong mi.GetParameters() [i].GetType(), it
should be mi.GetParameters() [i].ParameterType otherwise you'll be
querying for ParameterInfo class instead of what you want.
Thanks, that was what I was looking for, updated program below.
The other one is minor, in that
Hi all,
I've written aprogram that uses reflection to give a list of relevant
methods in the Mono.Simd, and reports whether they are accelerated or
not (see below). This small program might be of interest to others, to
see how well their processor behave.
There are methods that have
Rodrigo Kumpera wrote:
On Wed, Nov 19, 2008 at 4:23 PM, crashfourit [EMAIL PROTECTED]
wrote:
It would be nice to have the vector* have a constructor that takes in
only
one argument and fills all spots in the vector* with the same value.
Like...
Vector4f vector = new Vector4f(1);
The JIT will generate reasonable code. It's on our plans to give atention on
having a good
integration story with existing code.
On Thu, Nov 20, 2008 at 9:15 PM, crashfourit [EMAIL PROTECTED] wrote:
How will the jit engine handle this?
public static unsafe Vector4 AsVector4(ref Vector4f
It would be nice to have the vector* have a constructor that takes in only
one argument and fills all spots in the vector* with the same value. Like...
Vector4f vector = new Vector4f(1);
Second... I can really see someone doing this to use mono.simd in already
established code base.
On Wed, Nov 19, 2008 at 4:23 PM, crashfourit [EMAIL PROTECTED] wrote:
It would be nice to have the vector* have a constructor that takes in only
one argument and fills all spots in the vector* with the same value.
Like...
Vector4f vector = new Vector4f(1);
Second... I can really see
Hi Alan,
There a couple of issues with your code, let me get on them:
-Until recently (last night), getters were not accelerated, which causes a
significant
slowdown. I fixed this in r118899. The generated code is not as good as it
could be,
but this will be fixed eventually.
-Setters are still
Hey,
On Sat, Nov 15, 2008 at 3:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Alan,
-Getters and setter are a hint of ill vectorized code.
In this particular scenario, I'm not sure how i can get rid of the use
of getters/setters unless I use even more unsafe code. I don't know
whether it's
Here's my benchmarking file anyway, it may prove useful.
Alan.
On Sun, Nov 16, 2008 at 2:37 AM, Alan McGovern [EMAIL PROTECTED] wrote:
Hey,
On Sat, Nov 15, 2008 at 3:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Hi Alan,
-Getters and setter are a hint of ill vectorized code.
In this
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort to unsafe code,
it's actually substantially slower! I've attached three
implementations of the method here. The original, the safe SIMD and
the unsafe SIMD. The runtimes are
I forgot to mention that I'm on a 1.86GHZ core2duo and i was running
with --optimize=simd.
Alan.
On Sat, Nov 15, 2008 at 2:13 AM, Alan McGovern [EMAIL PROTECTED] wrote:
I found a bit of code in the SHA1 implementation which i thought was
ideal for SIMD optimisations. However, unless i resort
Guillon
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono.Simd Acceleration Attributes
Hi Christophe,
2008/11/7 Christophe Guillon [EMAIL PROTECTED]
Thank you for the explanation. It confirms my point and it seems that we
agree.
For the user guide aspect:
2) the attributes
PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Rodrigo Kumpera
*Sent:* 07 November 2008 15:15
*To:* Christophe Guillon
*Cc:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] Mono.Simd Acceleration Attributes
Hi Christophe,
2008/11/7 Christophe Guillon [EMAIL PROTECTED
Hi John,
Default values are indeed an useful addition. So far we have focused on API
completeness and not much about
making it easier to use. It's on our plans to add such helpers.
2008/11/6 Hurliman, John [EMAIL PROTECTED]
I'm in the process of converting over my OpenMetaverseTypes.dll
On 11/07/08 Christophe Guillon wrote:
It seems that as soon as the Mono.Simd primitives have a well defined
semantic it is not useful to specify which architecture feature is able to
emulate each of these primitives. I would have expected this to be the
choice of the virtual execution
Thank you for the explanation. It confirms my point and it seems that we
agree.
For the user guide aspect:
2) the attributes on the methods are never inspected by the runtime:
they are there to guide the programmers using Mono.Simd in determining
what kind of optimizations are usually available
Hi all,
Looking at the proposal for the Mono.Simd primitives I'm wondering how the
Mono.Simd.Acceleration attributes and the corresponding Mono.Simd.AccelMode
parameters are useful.
Thus I'm wondering what is the rational of having these attributes defined
and used in the definition of the
Hi Christophe,
2008/11/7 Christophe Guillon [EMAIL PROTECTED]
Thank you for the explanation. It confirms my point and it seems that we
agree.
For the user guide aspect:
2) the attributes on the methods are never inspected by the runtime:
they are there to guide the programmers using
Hey Jonathan,
Thanks for taking some time looking at the Mono.Simd API and doing
some suggestions
but, please, do then on a more visible mailing list such as mono-devel.
Just perusing through the Mono.Simd API, and one question (and a few
other suggestions) occurs to me: Why the non-reliance on
Hi Jonathan,
Answering your others suggestions.
Other suggestions:
SimdRuntime.IsMethodAccelerated() and
SimdRuntime.MethodAccelerationMode() should be overloaded to accept a
MethodInfo of the desired method, as it can be ~trivial to get a
MethodInfo in a static, type-checked fashion, e.g.:
I'm in the process of converting over my OpenMetaverseTypes.dll library (basic
3D type library) to use Mono.Simd. One thing that is very handy to have is
static members for common values, such as:
public static readonly Vector4f Zero = new Vector4f();
public static readonly Vector4f One = new
On Thu, 2008-11-06 at 12:04 -0200, Rodrigo Kumpera wrote:
Thanks for taking some time looking at the Mono.Simd API and doing
some suggestions but, please, do then on a more visible mailing list
such as mono-devel.
Because I'm an idiot who saw mono-d... and assumed it was
mono-devel-list. My
49 matches
Mail list logo
