16 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Wilbur commented  ·  May 11, 2012 5:59 pm  ·  Flag as inappropriate  ·  Delete

  I sincerely hope to see MS.NET SIMD support in the next release. It's encouraging to see someone @ MS is pushing for it. Thanks Carol.

• Matt Dotson commented  ·  May 10, 2012 8:30 pm  ·  Flag as inappropriate  ·  Delete

  #2 would be awesome, even better if the common vector types were interfaces so 3rd parties could plug-in their types. I hate when I have to mix and match vector types from multiple vendors when I'm trying to patch together a solution. It would also allow vectors optimized for different purposes SIMD vectors vs sparse vectors, etc.

• Azarien commented  ·  Apr 03, 2012 7:57 am  ·  Flag as inappropriate  ·  Delete

  #1 should be the most important, the rest can wait. specifically, #3 is not very reliable, because there will always be a question whether this particular loop is being optimized or not - as we already see with regular loops and arrays.

• Tim Gordon commented  ·  Mar 19, 2012 10:28 am  ·  Flag as inappropriate  ·  Delete

  Carol
  It's good to see that someone is pushing for this. I'd given up hope.
  #3 please. It's not just specialist maths libraries that would benefit from better floating point optimization.

• Anonymous commented  ·  Mar 19, 2012 2:25 am  ·  Flag as inappropriate  ·  Delete

  @Carol
  
  #3 is the most useful (and requires the most to implement) since it would allow existing code to take advantage of vectorization while it makes it very easy to write code which utilize vectorization .
  
  #2 seems like an reasonable choice (but I definitely still like #3 to be on the roadmap) as long as it is still powerful enough for people writing math library code. Fortran has some nice support for vector arithmetic (such as c(1:nd)=a(1:nd)/b(1:nd)) witch could give some inspiration.
  
  #1, i would personally give this lowest priority since it would have the smallest target audience and most probably require the most knowledge from the people using it. I guess at most one of my coworkers would even consider looking at it.
  
  I would also suggest that you get think about if/how LINQ fits into this so that code using LINQ would still be viable for optimizations.
  I don't think that LINQ should to be the preferred way to archive vectorization (since the syntax don't fit the math domain), but it would be really nice if code using LINQ such as that below could be vectorized.
  
  ex LINQ:
  - var dotProduct = array1.Zip(array1, (v1,v2) => v1 + v2).Sum();
  - var add1 = array1.Select( (v1) => v1 + 1);
  

• codekaizen commented  ·  Feb 29, 2012 3:19 pm  ·  Flag as inappropriate  ·  Delete

  Thanks for the great feedback, Carol. My preference would be for #3, since that would be the most useful universally throughout my code. With #1 and #2, I'd also like to have access to the floating point context so I can turn off handling denormals or error trapping for example. However, the cases where I would just want the JITter to use a vectorization heuristic (and some guidance on how to make sure the vectorization is being applied) far outnumber the cases where I want explicit support in my day to day work.

• Carol Eidt commented  ·  Feb 27, 2012 5:36 pm  ·  Flag as inappropriate  ·  Delete

  Support for SIMD is, and has been, on the list of things that we consider for the CLR, and as a developer on the JIT with a background in optimization, this is one of my personal favorites. As you can imagine, there are many features that compete for resources in each release, so I will continue to do my part to push for this one! In fact, I break this down into three sub-features, which are complementary:
  1. SIMD “intrinsics”, along the lines of what Mono has provided. I would like to see us expose these with an abstracted size, so that developers could take advantage of future hardware with larger SIMD registers
  2. General vector types of any length, implemented on top of the SIMD intrinsics.
  3. Automatic vectorization of numeric code
  Although these are each sizable features, the first two are the most compatible with the existing .NET architecture, as they will not significantly impact JIT throughput. The last requires additional infrastructure to support more heavyweight optimizations, either through pre-compilation or dynamic recompilation. We’d love to hear from you regarding the relative importance of these three features.
  cteidt - MSFT

• War commented  ·  Feb 21, 2012 12:17 pm  ·  Flag as inappropriate  ·  Delete

  The CLR team has a problem. They consider assembly load time above all else. This means they are averse to adding complex optimization to the JITer. They need to realize that most .Net code today runs on servers where assembly load time is not a factor.

  I'm hoping that since the C/C++ compiler in VS11 is adding native optimization for
  SIMD (see http://community.csevn.com/showthread.php?tid=39&pid=43) I'm hoping that the new JITer will inherit some of that work.

• copathuk commented  ·  Nov 22, 2011 3:47 pm  ·  Flag as inappropriate  ·  Delete

  It will be nice if Microsoft implements SIMD feature similar to Mono SIMD namespace:
  http://tirania.org/blog/archive/2008/Nov-03.html

• Anonymous commented  ·  Nov 12, 2011 11:08 am  ·  Flag as inappropriate  ·  Delete

  JIT compiler really needs to step up and generate optimal code and give developers choice of target modern optimizations. It is way behind VC++.

• codekaizen commented  ·  Oct 27, 2011 1:16 pm  ·  Flag as inappropriate  ·  Delete

  I agree - it doesn't require IL changes at all... in fact, that is kind of the point of IL. It just requires a better JITter. I remember doing some tests with the JVM and the CLR side by side on some tight computation tests, and was surprised that the JVM won hands down. After decompiling the resulting jitted code for each, it was clear why: the JVM was vectorizing the computation quite well, where as the CLR didn't even do any. This was back in 2007, on the v2.0 CLR. I'm surprised that the v4.0 _still_ doesn't have this capability.

• peter gideon commented  ·  Oct 22, 2011 4:09 am  ·  Flag as inappropriate  ·  Delete

  This does NOT require IL changes.JVMs support excellent FP optimizations. .net is lagging far behind in numeric perf and its getting worse and worse with each new processor generation. Vectorizing compilation is known tech, what's wrong with Microsoft that they can't implement it?

• peter gideon commented  ·  Oct 22, 2011 4:09 am  ·  Flag as inappropriate  ·  Delete

  This does NOT require IL changes.JVMs support excellent FP optimizations. .net is lagging far behind in numeric perf and its getting worse and worse with each new processor generation. Vectorizing compilation is known tech, what's wrong with Microsoft that they can't implement it?

• Sirisian commented  ·  Oct 18, 2011 2:51 pm  ·  Flag as inappropriate  ·  Delete

  What you're suggesting really requires heavy changes in the IL. Ideally including all native instructions found in processors. Then you need to open that up as language features via intrinsics or writing IL inline. This opens up the huge development challenge of "so we've allowed a compiler to output IL for any known processor. Now when we JIT it to native code any of those native processor features require an alternative compilation where they aren't supported. This could mean using lesser SSE features or just converting to a platform independent IL for simplicity.

  I've contemplated such a scheme and it's a lot of work to allow that level of optimization. It would be amazing if MS went that route, but it would probably take a lot of development cost to stay up to date.

  If all you want to support is the most basic SIMD operations then this could work, but ideally that would be selling the idea short when it could allow full optimization on par with any native code.

• Don Syme commented  ·  Oct 18, 2011 2:53 am  ·  Flag as inappropriate  ·  Delete

  Note, this is really a suggestion for the .NET CLR team. Personally I consider it very important, so please move it there to make sure it gets the correct visibility

• Chris commented  ·  Oct 15, 2011 1:42 pm  ·  Flag as inappropriate  ·  Delete

  Yes - it would be great if the .net JIT compiler would optimize in-depth optimized for CPUs. IMHO: As a first step, we would be off to a good start if SSE4 and AVX would be detected and utilized for optimizations.