9 ms·

Lots of interesting news in the .NET world lately. (Kind of hard to believe it took this long to get SIMD though!) SIMD can be a huge boost for numerical workl

Lots of interesting news in the .NET world lately. (Kind of hard to believe it took this long to get SIMD though!) SIMD can be a huge boost for numerical workloads; for example, SIMD auto-vectorization was just added to Julia, and people saw 8x boosts on some workloads (and in some cases another 4x from inlining improvements merged the next day).

bigdubs 13y ago
SIMD will also be huge for games.
- mrec 13y ago
  Really? I'd have thought that most of the things that would benefit from SIMD would be down in engine code, which is still mostly C/C++. Are many people writing numerically-intensive full-stack games in managed languages?
  - rbanffy 13y ago
    > Are many people writing numerically-intensive full-stack games in managed languages? It could just be that the current languages don't support it well.
  - seanmcdirmid 13y ago
    I'm sure there are than a few. Box2D for Java/C# is very useful (see Farseer in C# land), and can be more efficient than going through lots of interop calls. You can also hit DirectX directly using Sharp/SlimDX, which again, is also quite useful (if you want to write a game for DirectX, you are pretty much stuck in C++ unless you use these bindings).
    - MaulingMonkey 13y ago
      Not to mention all the fellows using Unity (or previously XNA) to develop games with. Writeoff #1 always seems to be "not quite fast enough" and each high performance option can help take a chunk out of that population.
      - mrec 13y ago
        Unity only uses C# for application-level user code. The core engine is C++.
      - _random_ 13y ago
        Unity is not an XNA replacement. MonoGame is.
        MaulingMonkey 13y ago
        Extremely arguable. I'm not hearing nearly as much about MonoGame as I am about Unity (although I am hearing some promising things.) I don't mean to imply Unity is 1:1 API replacement for XNA - it isn't, MonoGame is, yes. But I'd argue Unity has replaced (and quite effectively at that) XNA/MonoGame as a strong game building target for the masses. And it's not even arguable that, for me, Unity has absolutely replaced XNA, and MonoGame at this point is background noise. And don't get me wrong, I wish this weren't the case - because the more I've used Unity's APIs, the more I've come to hate them. I've an extreme dislike of the out of date and buggy compiler Unity uses for some of those platforms. But Unity's got a broader platform set than XNA and MonoGame combined, which unfortunately for me trumps the rest. I'd unscientifically wager it has far more libraries and middleware being written with it in mind. Maybe that will change. I would welcome such change. There have already been changes, even. But I'm not holding my breath - even if it does, it's too little and far too late for my day job.
        _random_ 13y ago
        "I don't mean to imply Unity is 1:1 API replacement for XNA" - this is what I meant. You cannot build your own engine on top of Unity, but some people don't need to.
  - alkonaut 13y ago
    A lot of the content tooling for games is usually written in some other more productive language (C#, python, ...), so there is a lot of contact between managed and native even for AAA games, even though very little of what actually ships in the game is managed code. Getting a performance boost (or not having to interop) in a level editor, texture tool etc. will likely be welcome. The tradeoff between safety/convenience/productivity vs. performance of C# vs C++ for example can't be motivated at the moment, and probably won't be with SIMD. Writing .NET code with deterministic performance is hard, so hard that C# is no more convenient than C++. I think any complex performance sensitive (Web browser, Game, SSL-Implementation...) is soon too complex to be done in C++ and too performance sensitive to be done in managed. Rust can't be released soon enough.
protomyth 13y ago
> Kind of hard to believe it took this long to get SIMD though! Does the JVM have SIMD?
- stusmall 13y ago
  Yes but there is room to improve. https://bugs.openjdk.java.net/browse/JDK-6340864 https://bugs.openjdk.java.net/browse/JDK-6340864
  - kvb 13y ago
    That's a bit different; this is about user-controlled SIMD instructions, not whether .NET can use SIMD instructions as part of its routine JIT code generation (see http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/4518... for some very old commentary on where .NET took advantage of SSE instructions in its code gen).
    - stusmall 13y ago
      Awesome! The other day I tried to find the amount of per-cpu tuning the .NET runtime was capable of but could never find anything. Thanks for the link, this is exactly what I was looking for.
- rbanffy 13y ago
  If what's needed is speed, neither Java nor C# are optimal choices. As for SSE/AVX from Java, http://stackoverflow.com/a/10809123/158026 http://stackoverflow.com/a/10809123/158026 shows a nice example of how it can be done. OTOH, I find this specific C# implementation neat and portable. I like it a lot.
  - bunderbunder 13y ago
    If what's needed is speed, neither Java nor C# are optimal choices. True, but if you're just trying to get some numerical speed out of some specific routines in a larger .NET application then having access to SSE like this could still be very helpful. Calling into native libraries from .NET isn't necessarily a performant option because of the cost of marshaling data back and forth between the managed and unmanaged memory spaces. The end result can be pretty significant; from my own experience I'm usually pretty hard-pressed to come up with a C++ implementation that can beat the C# code it intends to replace outside of a microbenchmark. If the C# code now has the option of banging on SSE then I'm not sure it'll even be worth trying to trot out C++.

bigdubs 13y ago

SIMD will also be huge for games.

mrec 13y ago
Really? I'd have thought that most of the things that would benefit from SIMD would be down in engine code, which is still mostly C/C++. Are many people writing numerically-intensive full-stack games in managed languages?
- rbanffy 13y ago
  > Are many people writing numerically-intensive full-stack games in managed languages? It could just be that the current languages don't support it well.
- seanmcdirmid 13y ago
  I'm sure there are than a few. Box2D for Java/C# is very useful (see Farseer in C# land), and can be more efficient than going through lots of interop calls. You can also hit DirectX directly using Sharp/SlimDX, which again, is also quite useful (if you want to write a game for DirectX, you are pretty much stuck in C++ unless you use these bindings).
  - MaulingMonkey 13y ago
    Not to mention all the fellows using Unity (or previously XNA) to develop games with. Writeoff #1 always seems to be "not quite fast enough" and each high performance option can help take a chunk out of that population.
    - mrec 13y ago
      Unity only uses C# for application-level user code. The core engine is C++.
    - _random_ 13y ago
      Unity is not an XNA replacement. MonoGame is.
      - MaulingMonkey 13y ago
        Extremely arguable. I'm not hearing nearly as much about MonoGame as I am about Unity (although I am hearing some promising things.) I don't mean to imply Unity is 1:1 API replacement for XNA - it isn't, MonoGame is, yes. But I'd argue Unity has replaced (and quite effectively at that) XNA/MonoGame as a strong game building target for the masses. And it's not even arguable that, for me, Unity has absolutely replaced XNA, and MonoGame at this point is background noise. And don't get me wrong, I wish this weren't the case - because the more I've used Unity's APIs, the more I've come to hate them. I've an extreme dislike of the out of date and buggy compiler Unity uses for some of those platforms. But Unity's got a broader platform set than XNA and MonoGame combined, which unfortunately for me trumps the rest. I'd unscientifically wager it has far more libraries and middleware being written with it in mind. Maybe that will change. I would welcome such change. There have already been changes, even. But I'm not holding my breath - even if it does, it's too little and far too late for my day job.
        _random_ 13y ago
        "I don't mean to imply Unity is 1:1 API replacement for XNA" - this is what I meant. You cannot build your own engine on top of Unity, but some people don't need to.
- alkonaut 13y ago
  A lot of the content tooling for games is usually written in some other more productive language (C#, python, ...), so there is a lot of contact between managed and native even for AAA games, even though very little of what actually ships in the game is managed code. Getting a performance boost (or not having to interop) in a level editor, texture tool etc. will likely be welcome. The tradeoff between safety/convenience/productivity vs. performance of C# vs C++ for example can't be motivated at the moment, and probably won't be with SIMD. Writing .NET code with deterministic performance is hard, so hard that C# is no more convenient than C++. I think any complex performance sensitive (Web browser, Game, SSL-Implementation...) is soon too complex to be done in C++ and too performance sensitive to be done in managed. Rust can't be released soon enough.

protomyth 13y ago

> Kind of hard to believe it took this long to get SIMD though! Does the JVM have SIMD?

stusmall 13y ago
Yes but there is room to improve. https://bugs.openjdk.java.net/browse/JDK-6340864 https://bugs.openjdk.java.net/browse/JDK-6340864
- kvb 13y ago
  That's a bit different; this is about user-controlled SIMD instructions, not whether .NET can use SIMD instructions as part of its routine JIT code generation (see http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/4518... for some very old commentary on where .NET took advantage of SSE instructions in its code gen).
  - stusmall 13y ago
    Awesome! The other day I tried to find the amount of per-cpu tuning the .NET runtime was capable of but could never find anything. Thanks for the link, this is exactly what I was looking for.
rbanffy 13y ago
If what's needed is speed, neither Java nor C# are optimal choices. As for SSE/AVX from Java, http://stackoverflow.com/a/10809123/158026 http://stackoverflow.com/a/10809123/158026 shows a nice example of how it can be done. OTOH, I find this specific C# implementation neat and portable. I like it a lot.
- bunderbunder 13y ago
  If what's needed is speed, neither Java nor C# are optimal choices. True, but if you're just trying to get some numerical speed out of some specific routines in a larger .NET application then having access to SSE like this could still be very helpful. Calling into native libraries from .NET isn't necessarily a performant option because of the cost of marshaling data back and forth between the managed and unmanaged memory spaces. The end result can be pretty significant; from my own experience I'm usually pretty hard-pressed to come up with a C++ implementation that can beat the C# code it intends to replace outside of a microbenchmark. If the C# code now has the option of banging on SSE then I'm not sure it'll even be worth trying to trot out C++.