C#的优雅，强大IDE的支持，.net下各语言的二进制兼容，自从第一眼看到C#就被其良好的设计吸引。一直希望将其应用于高性能计算领域，长时间努力却效果却不尽如人意。
对于小的测试代码用例而言，C#用20-30%的性能损耗换取良好的开发维护体验倒是非常值得。
但FEM/CFD/SPH求解器的实际开发中，作为典型的运算密集型项目，对性能极其敏感。即使是单线程，未作充分优化前提下，运算耗时：
C#：ASC C 未优化= 2：1
C#：ASC C 充分优化= 4：1 如手工循环展开，内联优化等
ASC C优化 ：C++11 优化= 1：1 到1.1 ：1 说明相同编译器C 89 和C++ 11在该领域性能相当
C++11 x86 优化：C++11 x64 优化= 1 : 1.1 64bit性能略高
C++11 优化：Fortran 95默认 = 1.5 ：1
也就是说C++11 充分优化后的代码居然比Fortran 95的默认还慢了不少，而C#默认编译的只有C++11优化后的1/4, Fortran的1/6 , 而且C#的优化空间还很小。
付出了这么多精力，得到的结果却如此，难道还得继续用VIM编写Fortran代码（intel fortran 2013后对VS的支持有所提升，但还是适合自行配置VIM来开发）
对于GPU和异构计算领域，也尝试了C#，可以使用，但也是难以发挥硬件的极致性能。
并行计算的话C++ PPL 与C# TPL 在形式上非常接近，为啥性能上却相差那么大呢。
追求极限GPU性能的话CUDA >OpenCL >C++AMP = OpenACC
当然灵活性也逐渐递减。
为了让C#适用于高性能计算的话，一个思路是仅仅利用语法规则，而不使用默认的编译器，严格限定使用少量几个语法，自行开发编译前端将C#语言转译成C再编译，但开发者需要自行确保无读写访问冲突。
另一个思路是仿照CUDA/OpenCL、，将运算密集型部分抽出，转译成GPU执行，由于热点部分部分代码规模较小，可限定语法为C的子集。
但在实际应用上，两个思路也都困难重重，并且放弃了调试的便利。
哎，C#高性能计算，想说爱你不容易。