C#在高性能计算领域为什么性能却如此不尽人意
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#高性能计算,想说爱你不容易。
最新文章
- 设计模式--适配器模式Adapter(结构型)
- [转]ORACLE中Like与Instr模糊查询性能大比拼
- touch移动触屏滑动事件
- unity中的WWW通讯问题
- intellij自动缩进排版
- SpringMVC + Spring + MyBatis 学习笔记:为MyBatis增加打印SQL功能 (最简化配置)
- Windows内存管理和linux内存管理
- 工作中遇到的UIScrollview的问题及解决方案
- Call Hierarchy(方法调用层次)
- 斯坦福IOS开发第五课(第一部分)
- 一步一步写算法(之n!中末尾零的个数统计)
- leangoo
- [JQuery] Ajax使用过程中的问题总结
- HTML相关知识
- TortoiseSVN使用经验
- geotrellis使用(三十一)使用geotrellis直接将GeoTiff发布为TMS服务
- vscode restclient 插件
- phpinfo
- Maya cmds filterExpand 列出 选择的 uvs vertices faces edges 等 component 类型
- BZOJ3817 清华集训2014 Sum 类欧几里得
热门文章
- FK JavaScript之:ArcGIS JavaScript API之地图动画
- ssh项目部署到weblogic中问题总结
- Delphi中字符串补齐方法
- NorthWind 数据库整体关系
- uploadfile图片上传和ashx
- Apache2 worker
- Android Unable to instantiate activity: Didn't find class on path
- IE 6 ~ 9 CSS Hack 写法总结
- Thinkphp查询 1.查询方式 2.表达式查询 3.快捷查询 4.区间查询 5.组合查询 6.统计查询 7.动态查询 8.SQL 查询
- Java中Set Map List 的区别