DISQUS

Miguel de Icaza's blog: Mono's SIMD Support: Making Mono safe for Gaming - Miguel de Icaza

  • barrkel · 1 year ago
    That's really nice work. Kudos all round.
  • Lucas Meijer · 1 year ago
    I think line 3 of snippet #1 should read pos[i] += delta; instead.
  • migueldeicaza · 1 year ago
    oops. You are right, just fixed it.
  • The Fiddler · 1 year ago
    Great news! We are already evaluating how OpenTK can best advantage of Mono.SIMD.
  • migueldeicaza · 1 year ago
    These are *great* news!

    Please let us know if there are some helper methods that you think would be useful to have, I suspect we are going to need a dot product method (even if it is only available on SSE4 systems).
  • The Fiddler · 1 year ago
    A quick suggestion after skimming through the code.

    There are several methods defined like this:
    public static unsafe Vector4f operator | (Vector4f v1, Vector4f v2)
    { ... }

    AFAIK, unsafe methods are not CLS-compliant, so theseeither need a [CLSCompliant(false)] attribute or they need the unsafe keyword removed (an unsafe block inside the function should be enough).

    I'm sorry if this is not the correct place to make suggestions / feature requests - maybe this should go to the mono-dev list instead?
  • rodrigokumpera · 1 year ago
    You can either use our mailing lists, our irc chat bots or just email me ;)
  • James Henstridge · 1 year ago
    I assume the "Vector3f" bits in the second code snippet should be "Vector4f", right?
  • migueldeicaza · 1 year ago
    Oops, right, thanks for catching that.

    That is what I get for typing it from memory; Will fix as soon as I get back to work where my blog software is.
  • Nikolay Popov · 1 year ago
    Excellent, it's exiting to see this, I wish too MS will be inspired to implement it in the .NET runtime. I've do this trough C++ with inline assembly, but having this capability in the runtime would be really great. One suggestion/ idea - it'll be really great to put AMD.Stream and Nvidia.CUDA in to the game, after all every modern PC/MAC comes with video card from Nvidia or AMD. This could really enable the dream for true portable, stunning and modern games!
    Best Regards, Nikolay
  • migueldeicaza · 1 year ago
    I believe those might be better suited as class libraries that require no runtime support.

    There is already a project that does CUDA integration at least.
  • Frank HIleman · 1 year ago
    Thanks, this is amazing. A managed rendering engine for VG.net looks like a closer reality.
  • ljmeijer · 1 year ago
    Hey Miguel,

    Great stuff! In your presentation, there's a few things that are slightly off, related to the game development stuff:

    The part about AI taking up a large amount of the "frametime" of a game. It's actually a bit more general
    The parts that are traditionally written in "slowy" languages include:

    - indeed AI
    - steering behaviour for those birds that fly around in the island demo
    - reading mouse input, and deciding where the camera should go
    - deciding when to play sounds, when to start this or that animation
    - checking if a player is close enough to a powerup that he should actually pick it up,
    - keeping score of the game
    - dealing with the server communication in case of multiplayer games
    - much more that depends on what kind of game you are making.

    The total often gets referred to as "scripting" (since it is often done in a non c++ programming
    language. this term might change as very slowly more and more parts of a 3d engine get doable
    in nicer languages that c++), or as "game code". (a term engine programmers often use when
    they mean "all that stuff that I don't write")

    So not only is mono able to speed up my ai, it brings the performance of my entire gamecode up
    like 20x from the performance I had in previous engines where I had to do all this stuff in a very slow
    proprietary scripting language.

    Mono greatly enhances the amount of stuff I can do in a game, and I love it.
  • Peter · 1 year ago
    How about comparing the mono SIMD single precision versus a c++ SIMD single precision implementation. Having the comparison to a non SIMD double precision implementaion is meaningless.
  • migueldeicaza · 1 year ago
    The tests are done against floating point values. Both implementations are included in the tarball above.

    Read the Makefile and see rkf.cpp (the original is in rk.cpp)

    Miguel.
  • Veksi · 1 year ago
    What was the command line switches used in the compilation of the C++ code? Also, was profiling done against debug code (in which case any timing is worthless). I can say for sure that C++ code is not good for any testing. Why not iterators, for instance? And it contains bugs with temporary variables.

    All in all, the C++ code looks like written a novice (an argument against C++, I guess). But this is a good direction to take. Keep up the good job!
  • migueldeicaza · 1 year ago
    All of the information is in the source code, it contains makefiles and invocation parameters.

    The source code for C# is just a straight forward port with no tuning or performance improvements attempted. It could also be tuned up and improved (for example, using unsafe code would boost its performance).

    As I mentioned in the talk and elsewhere, C++ SIMD intrinsics would give you a major boost over plain C++ just like it did for Mono. But our research direction was on improving Mono to the point that it would satisfy the needs of game developers that would like the safety and productivity of a managed language without having to pay the high price of going to C++.
  • Mungolf · 11 months ago
    So why does the figure say "C++ (3D doubles) ?

    And why do you use a for-loop to compute the sum of two vectors? The compiler better has a good loop-unroll functionality because otherwise it makes the comparison even more meaningless.
  • Mungolf · 11 months ago
    Anyway, nice job on the mono part
  • Dmitri · 1 year ago
    So would Mono.Simd work on Windows? I mean, under Microsoft's CLR and all that?
  • migueldeicaza · 1 year ago
    Yes, the assembly will run just fine on the Microsoft.CLR, but it will not be accelerated.

    The same would happen if you use Mono.SIMD on a platform without SIMD support, for example a 486 computer, the code would continue to run just fine, but it would not get any hardware accelerated benefits.
  • Dan · 1 year ago
    Is this available on trunk now? What is the time frame for 2.2. Thanks.
  • migueldeicaza · 1 year ago
    yes, the code is available from trunk, from the mono-2-2 branch and from the Mono 2.2 preview packages that we shipped a week or two ago.

    When we showed the code at the PDC the code was already live, and the performance tests were all done with the code that was available at the time on SVN. We just did not go out of our way to advertise it.

    Notice that improvements to the API and to the JIT code since the PDC have improved Mono's performance on these tests.
  • Quack quack · 1 year ago
    Yikes! I support the idea, but it makes one somewhat dependent on using Mono's vector structures instead of one's own. I'd like to see an attribute that can be applied to custom vector op methods, and let the Mono JIT check that there's a vector op going on, and optimize that with SIMD.
  • Itai Bar-Haim · 1 year ago
    What about some more general functions, that can perform operations on any two primitives arrays of the same type and size? This will save the repeated coding task of finding the best combination of SIMD operations, corner cases, etc, and will greatly help to code filters (say, the very commonly used median filter).

    Itai.
  • Yoav HaCohen · 1 year ago
    I think that a standard implementation of BLAS for standard Mono/.NET arrays will be a very useful.
  • Anton · 11 months ago
    I have a lot of logarithm/exponent calls. Will Mono.Simd optimise them?

    Do you plan to rewrite advanced functions with SIMD support? Ln, Exp, Sqrt, Pow just to mention some of them...
  • migueldeicaza · 11 months ago
    Some will, some will not.

    The best thing is to discuss this on the mailing list or check our SVN release.
  • Anton · 11 months ago
    Hello, Miguel.

    I am very interested in suggested SIMD support and just finished speed measurments in my particular environment: SuSE 11 running in VurtualBox 2.1. Detailed description of my results is in the following post: http://kyta.spb.ru/monosimd.aspx

    Briefly speaking, I could win 100% of speed for mono with -O=simd switch, and at the same time I could loose 50% of speed for mono with -O=-simd switch.

    That is not what I expected from your presentation, but 100% are still 100%... The other point is VirtualMachine environment. I think this could break everything. I will try to execute this snippet in "real" environment asap.

    Best Regards,
    Anton.
  • drac · 11 months ago
    The C++ program was compiled in Debug Mode. It's not a fair comparison. Here is a benchmark on Windows XP with C++ program compiled with MinGW 4.3.2 and Visual Studio 2005.
    http://cristianadam.blogspot.com/2009/01/mono-2...
  • radioman · 11 months ago
    nice ;}
  • Mp3 indir · 11 months ago
    Briefly speaking, I could win 100% of speed for mono with -O=
  • marwee · 10 months ago
    It is a pity that the Simd-Types are not serializable. Besides this i love it.
  • Vladimir Vukicevic · 9 months ago
    Hey Miguel, this is pretty cool -- I was talking about doing the same thing for JS with Tracemonkey, and someone pointed me to this. It's a great way to expose some simd stuff direct to developers without asking them to play auto-vectorization roulette :-)
  • Frank Großmann · 8 months ago
    Hello!

    Why are the Vector structs are not Serializeable?
    (I've tried to write a dotNet to Mono Runtime Bridge using .Net Remoting, which is working but I cant use e.g. Vector2d directly)
  • GeneticGenesis · 8 months ago
    It might be worth taking a look here: http://ds9a.nl/gcc-simd/example.html and compiling your code for your chipset, and seeing how fast you can get it down to in C++.
  • Medyum · 7 months ago
    You can either use our mailing lists, our irc chat bots or just email me....
  • Medyum · 7 months ago
    These are *great* news!
  • Medyum · 7 months ago
    Great news! We are already evaluating how OpenTK can best advantage of Mono
  • Medyum · 7 months ago
    Yikes! I support the idea, but it makes one somewhat dependent on using Mono's vector structures instead of one's own. I'd like to see an attribute that can be applied to custom vector op methods, and let the Mono JIT check that there's a vector op going on, and optimize that with SIMD.
  • migueldeicaza · 7 months ago
    The good news is: we are taking patches.

    Please design the feature, code it, and post it to the mailing list, we will be happy to review it/integrate it.