603
社区成员
发帖
与我相关
我的任务
分享为什么CL社区不火？
原因有很多种，有想法的往下接，
我觉得CL社区不火的原因，
1 我们只为了异构而异构，而对于算法方面谈论的比较少，CL主要用于加速，只有把加速的效果展现出来，才能更加吸引人。
2 异构可以在不同平台上进行，在QQ的群中很多人认为只在GPU上进行加速。实际上嵌入式系统中也能应用CL，应该拓展这些方向。由于PC份额的减少或者移动通信的普及，移动化是CL的必经之路，而我们却几乎没有人尝试在移动设备上使用CL。Mali 高通都有相应的CL开发环境。
3 很多人对于超级计算机不太了解，所以CL在超级计算机上的应用和我们平时使用的通用程序有一定的距离，不是任何人都需要了解流体模拟是怎样在CL中加速的。
本人愚见，欢迎拍砖，呵呵
我觉得CL社区不火的原因，
1 我们只为了异构而异构，而对于算法方面谈论的比较少，CL主要用于加速，只有把加速的效果展现出来，才能更加吸引人。
2 异构可以在不同平台上进行，在QQ的群中很多人认为只在GPU上进行加速。实际上嵌入式系统中也能应用CL，应该拓展这些方向。由于PC份额的减少或者移动通信的普及，移动化是CL的必经之路，而我们却几乎没有人尝试在移动设备上使用CL。Mali 高通都有相应的CL开发环境。
3 很多人对于超级计算机不太了解，所以CL在超级计算机上的应用和我们平时使用的通用程序有一定的距离，不是任何人都需要了解流体模拟是怎样在CL中加速的。
本人愚见，欢迎拍砖，呵呵
...全文
请发表友善的回复…
发表回复
outstander 2013-09-30
- 打赏
- 举报
人气会在不知不觉的坚持中慢慢增长的，一起努力吧。[/quote]
:)
HomeAnimator 2013-09-29
- 打赏
- 举报
安心做事把！ 是金子，总会发光的！
u011220699 2013-09-27
- 打赏
- 举报
很快会火起来的！！！
lcwyylcwyy 2013-09-19
- 打赏
- 举报
人气会在不知不觉的坚持中慢慢增长的，一起努力吧。
lcwyylcwyy 2013-09-19
- 打赏
- 举报
现在，也有很多 U 大一就用GCC教学，随着时间流逝，不同的编译器会再我大China流行起来的。还有，我们永远无法回避MS带来的影响，我在Eclipse VS 和Vim上都开发过项目，个人感觉这几个各有优点也各有缺点，怎么说呢，开发Windows上的程序时，我们永远绕不开VS+VA的组合，它只是在Windows上稍微方便一点吧，确实感觉不如配置好的Vim，但是Eclipse真是感觉有点烂了。另外，成为有经验的人需要时间的磨练，又有多少码农能够静下心来在一个领域耕耘积累呢？呵呵，人来人往的交接会成为一个难以回避的话题，如果无法交接好，项目会难以维护的。
outstander 2013-09-16
- 打赏
- 举报
咳咳~追加一个非技术原因:
版主个人魅力不够(掩面而泣)
lcwyylcwyy 2013-09-14
- 打赏
- 举报
呵呵，所以这又回到了俺在4楼所提到的。现在主流CPU架构不外乎x86和ARM，所以要进行调整、适配，工作量倒是还好。另外，如果你的解决方案仅选用NV家的GPU，那用CUDA内联PTX未尝不可～现在HPC领域看上去虽然像似桌面应用，但实质上定制化程度比较高，尤其是超级计算机一般会选定用某一批规格的处理器。像天河2号用的GPU就是NV家的。
当然，OpenCL的意义在于标准开放之后，除了CPU、GPU之外，其它设备也能适用，包括Power CELL、DSP、甚至FPGA。倘若OpenCL能早点出来的话，Power CELL的境地也不会像现在那么糟糕了。Power CELL已经有HSA这种意思在里面了，但是没有良好的软件工具支持也是无法很好地市场化的。所以怎么去应用OpenCL，结合CPU与各种加速处理器的协作是商用软件项目上所需要思考的问题。像CPU也用OpenCL未必能取得好的效果。OpenCL应该用在更适合它的设备上。[/quote]
CL统一分配计算资源，进行并行计算，以最小开发代价更加充分的利用各种计算资源才是根本性的。否则，开发一套软件需要不同平台优化，也可能无法充分利用所有可计算资源。理想状态也许和你所说一样，但是当你在不同平台优化完成时，同样功能的其他商业应用可能已经发行。实际上，优化到极限时，开发代价是呈指数级增长的，容易使软件成了一个为了优化而优化的产品了。CL的思路是在相对较低的开发代价内，根据最大可用计算资源进行数据划分，最终提高设备利用率。用汇编和高级语言比较性能，个人认为根本不在一个等级上。CL可以以很低的开发代价进行CPU+GPU方式运算，你的指令级别优化又能以多低的代价进行CPU+GPU性能优化呢？CL也许不能够最大限度的发挥CPU的性能，但是在通用应用中，用CPU辅助GPU，这样的性能是不是会比只是用CPU指令优化快一些呢？当然，其性能是无法和CPU指令+GPU指令相比，但是开发代价呢？汇编是一个过程化的语言，不同平台的统一化处理还是需要借组高级语言的，如果这样不是又回到CL的思路上了吗？世界上没有无商业模式的软件，包括开源软件，所以还是需要考虑技术的商用化问题的。intel IBM都有自己的编译器，但为什么没有GCC VC 普及呢？因为他们只为自己平台服务，而CL是跨平台，跨操作系统的。也许这就是传说中的劣币驱逐良币吧。
zenny_chen 2013-09-14
- 打赏
- 举报
另外，你所举的VC比ICC等编译器流行的例子显然是因为本朝基础教育的问题。学校里都让学生用VC，一时半会儿这习惯还真不好改〜
不过幸亏现在iOS、Android开发流行起来，终于本朝码农们可以摆脱巨硬的洗脑了〜巨硬这或最可恶的就是不遵守行业规范，目录分隔符用SB的\而不是/；编码格式么又是乱七八糟，在VC里也没法设置。VC是一款非常矬的IDE，比Eclipse还矬。俺现在用切仅使用遵守GNU规范的C/C++编辑器，并且仅使用系统默认编码为UTF-8的操作系统〜
不过幸亏现在iOS、Android开发流行起来，终于本朝码农们可以摆脱巨硬的洗脑了〜巨硬这或最可恶的就是不遵守行业规范，目录分隔符用SB的\而不是/；编码格式么又是乱七八糟，在VC里也没法设置。VC是一款非常矬的IDE，比Eclipse还矬。俺现在用切仅使用遵守GNU规范的C/C++编辑器，并且仅使用系统默认编码为UTF-8的操作系统〜
zenny_chen 2013-09-14
- 打赏
- 举报
用CPU辅助GPU又不需要你把CPU作为计算设备〜CPU本身就是作为Host，通过灵活使用OpenCL提供的命令队列和事件响应接口即可把CPU与GPU之间的并行协作机制盘活。
将CPU作为作业流水线的一个或若干个阶段；或是将CPU与GPU共同并行完成同一个较简单的任务等都是可行的。但是在CPU做HPC时，人工汇编显然能把效率最大化。对于有经验的开发者，写汇编跟写C没太大区别，所以就成本而言就看你找谁合作了，呵呵〜
将CPU作为作业流水线的一个或若干个阶段；或是将CPU与GPU共同并行完成同一个较简单的任务等都是可行的。但是在CPU做HPC时，人工汇编显然能把效率最大化。对于有经验的开发者，写汇编跟写C没太大区别，所以就成本而言就看你找谁合作了，呵呵〜
lcwyylcwyy 2013-09-13
- 打赏
- 举报
我已经把OpenCL已经引入生产环节，性能还是非常不错的。GPU的公司虽多但体系结构基本一致，NV和AMD的体系越来越同质化，可以去看一看新的GPU平台资料。我感觉你并没有真正在生产环节上使用CL，所以会觉得调试困难，平台工作差异，个人感觉其调试难度和Linux平台调试C差不多。实际上，我们一般使用CPU方式调试CL，再放到GPU上运行，当前的CL对硬件的抽象及可移植性还是比较令人满意的。就图像技术本身而言，GPU的性能超过CPU很多，我在HD6750上调试，卷积部分的加速可以达到多线程方式的7倍以上，在GTX 680上，其加速性能接近1X倍，但我们还在生产环节中，同时使用CPU和GPU平台进行加速。另外，CL是个通用平台，并不是和CPU平台对立的GPU平台，其在CPU上的运行性能也非常优秀。对于不同的领域需要不同的解决方案，CL的使用和并行计算一样，和领域相关度很高。不过，CL应该是CPU和GPU计算联合进行加速的一个选择，而不是CPU GPU alternative。还有我觉得SDK 及在什么系统下运行和CL的开发没有直接联系，完全可以在一个平台或系统上开发，之后在另一个平台或系统上运行。一开始我也觉得CL商业化上有问题，但是很多技术开始时都是这样，以后欢迎一起交流CL CUDA的知识，我也是从玩CL到真正使用CL。
zenny_chen 2013-09-13
- 打赏
- 举报
呵呵，所以这又回到了俺在4楼所提到的。现在主流CPU架构不外乎x86和ARM，所以要进行调整、适配，工作量倒是还好。另外，如果你的解决方案仅选用NV家的GPU，那用CUDA内联PTX未尝不可～现在HPC领域看上去虽然像似桌面应用，但实质上定制化程度比较高，尤其是超级计算机一般会选定用某一批规格的处理器。像天河2号用的GPU就是NV家的。
当然，OpenCL的意义在于标准开放之后，除了CPU、GPU之外，其它设备也能适用，包括Power CELL、DSP、甚至FPGA。倘若OpenCL能早点出来的话，Power CELL的境地也不会像现在那么糟糕了。Power CELL已经有HSA这种意思在里面了，但是没有良好的软件工具支持也是无法很好地市场化的。所以怎么去应用OpenCL，结合CPU与各种加速处理器的协作是商用软件项目上所需要思考的问题。像CPU也用OpenCL未必能取得好的效果。OpenCL应该用在更适合它的设备上。
lcwyylcwyy 2013-09-13
- 打赏
- 举报
我已经把OpenCL已经引入生产环节，性能还是非常不错的。GPU的公司虽多但体系结构基本一致，NV和AMD的体系越来越同质化，可以去看一看新的GPU平台资料。我感觉你并没有真正在生产环节上使用CL，所以会觉得调试困难，平台工作差异，个人感觉其调试难度和Linux平台调试C差不多。实际上，我们一般使用CPU方式调试CL，再放到GPU上运行，当前的CL对硬件的抽象及可移植性还是比较令人满意的。就图像技术本身而言，GPU的性能超过CPU很多，我在HD6750上调试，卷积部分的加速可以达到多线程方式的7倍以上，在GTX 680上，其加速性能接近1X倍，但我们还在生产环节中，同时使用CPU和GPU平台进行加速。另外，CL是个通用平台，并不是和CPU平台对立的GPU平台，其在CPU上的运行性能也非常优秀。对于不同的领域需要不同的解决方案，CL的使用和并行计算一样，和领域相关度很高。不过，CL应该是CPU和GPU计算联合进行加速的一个选择，而不是CPU GPU alternative。还有我觉得SDK 及在什么系统下运行和CL的开发没有直接联系，完全可以在一个平台或系统上开发，之后在另一个平台或系统上运行。一开始我也觉得CL商业化上有问题，但是很多技术开始时都是这样，以后欢迎一起交流CL CUDA的知识，我也是从玩CL到真正使用CL。[/quote]
就目前俺所看到的，如果用CPU做OpenCL计算，效率远远不及俺手工汇编优化的。另外，你说卷积速度是CPU的7倍，这也是因为你没有好好优化CPU端的代码而已。你可以从App Store下载一下CPU Dasher就知道，如果没有OpenCL，单用GLSL来做3x3的卷积是多么糟糕的事情。从Apple A4到Apple A6俺都测过了，即便俺不用SIMD来优化，就用ARMv5TE的指令集手工汇编优化就超GPU的性能了。当然，OpenCL Capable的GPU在数据类型和访存上比GLSL要灵活得太多。GLSL上的性能慢主要还是sampling的访存问题。
另外，OpenCL确实可以商用，这点没啥问题。我上文说的是Intel HD Graphics目前无法在OpenCL上商用。如果你想基于Intel处理器做优化的话，那么直接使用Intel Parallel Desktop更为适宜。虽然OpenCL是个开放计算平台，能兼容各种设备，但是就目前而言，CPU在上面的计算效率仍然不够理想，所以就目前家用的机器而言，最好还是通过GPU做OpenCL计算才能发挥其最大效能。[/quote]
优秀的性能确实少不了各种优化,我没有做过汇编方式的优化，但CPU和GPU我们都没有使用任何优化。如果像你所说，每一种处理都是用CPU进行指令级别优化，移植起来开发的成本比较高，而且不是很多新人都能掌握的。CL只要支持1.1版本，基本可以满足大多数应用和大多数平台，开发代价相对比较低。而实际上，GPU也是可以进行汇编指令或类汇编指令优化的，比如CUDA可以嵌入PTX指令，这个方面超过了我的研究范围，欢迎你也研究一下，也是一个GPU应用优化方向。从指令集来说，GPU平台确实不像x86平台这么统一。通用应用，我们采用的一般是CPU+GPU方式，因为CL可以对数据进行划分，然后分别使用不同设备进行计算，所以，联合CPU GPU应用是以后的方向，新的AMD显卡支持映射显存，理论性能有所提升，我觉得Intel支持核显也是为了联合CPU GPU进行计算。新的Intel HD也有一部分部分支持CL了，商用CL虽然没问题，但是还有很长的路要走，毕竟x86平台是Intel的看家本事。
zenny_chen 2013-09-13
- 打赏
- 举报
我已经把OpenCL已经引入生产环节，性能还是非常不错的。GPU的公司虽多但体系结构基本一致，NV和AMD的体系越来越同质化，可以去看一看新的GPU平台资料。我感觉你并没有真正在生产环节上使用CL，所以会觉得调试困难，平台工作差异，个人感觉其调试难度和Linux平台调试C差不多。实际上，我们一般使用CPU方式调试CL，再放到GPU上运行，当前的CL对硬件的抽象及可移植性还是比较令人满意的。就图像技术本身而言，GPU的性能超过CPU很多，我在HD6750上调试，卷积部分的加速可以达到多线程方式的7倍以上，在GTX 680上，其加速性能接近1X倍，但我们还在生产环节中，同时使用CPU和GPU平台进行加速。另外，CL是个通用平台，并不是和CPU平台对立的GPU平台，其在CPU上的运行性能也非常优秀。对于不同的领域需要不同的解决方案，CL的使用和并行计算一样，和领域相关度很高。不过，CL应该是CPU和GPU计算联合进行加速的一个选择，而不是CPU GPU alternative。还有我觉得SDK 及在什么系统下运行和CL的开发没有直接联系，完全可以在一个平台或系统上开发，之后在另一个平台或系统上运行。一开始我也觉得CL商业化上有问题，但是很多技术开始时都是这样，以后欢迎一起交流CL CUDA的知识，我也是从玩CL到真正使用CL。[/quote]
就目前俺所看到的，如果用CPU做OpenCL计算，效率远远不及俺手工汇编优化的。另外，你说卷积速度是CPU的7倍，这也是因为你没有好好优化CPU端的代码而已。你可以从App Store下载一下CPU Dasher就知道，如果没有OpenCL，单用GLSL来做3x3的卷积是多么糟糕的事情。从Apple A4到Apple A6俺都测过了，即便俺不用SIMD来优化，就用ARMv5TE的指令集手工汇编优化就超GPU的性能了。当然，OpenCL Capable的GPU在数据类型和访存上比GLSL要灵活得太多。GLSL上的性能慢主要还是sampling的访存问题。
另外，OpenCL确实可以商用，这点没啥问题。我上文说的是Intel HD Graphics目前无法在OpenCL上商用。如果你想基于Intel处理器做优化的话，那么直接使用Intel Parallel Desktop更为适宜。虽然OpenCL是个开放计算平台，能兼容各种设备，但是就目前而言，CPU在上面的计算效率仍然不够理想，所以就目前家用的机器而言，最好还是通过GPU做OpenCL计算才能发挥其最大效能。
zenny_chen 2013-09-11
- 打赏
- 举报
高端的东西讨论的人永远是最少的。如果是讨论Java、C++这种，人气肯定高～
这个世界上精英是少数～
zenny_chen 2013-09-11
- 打赏
- 举报
除此之外，其实真正让OpenCL用得好还是得有良好的计算环境。对于高密集计算OpenCL方有发挥优势，如果对于一般通用计算或是计算量较少的计算需求，那么我直接用CPU通过SIMD来做反而会比GPU更快。现在x86的CPU端都支持了256位的SIMD向量操作，32位有8个YMM寄存器，64位有16个YMM寄存器；ARM处理器的NEON也支持了128位的SIMD向量操作，而且32位有16个Q寄存器，64位有32个Q寄存器。并且现在主流的处理器都至少有两个核心。因此，CPU端也提供了非常不错的多媒体处理计算性能，如果就单单做诸如图像半透明效果之类的CPU未必比普通GPU差。而且，由于现在在CPU端，主要就是被x86和ARM所垄断，因此所要做的优化工作其实不会太麻烦。GPU端的话，做的公司太多了，架构也多——AMD（Radeon HD Graphics、Fire Pro）、nVidia（GeForce、Quadro、Tegra核心GPU）、ARM（Mali）、Intel（Intel HD Graphics）、Qualcomm（原AMD的移动GPU部门的Adreno）、Imagination Technology（PowerVR）等等。尽管OpenCL能抽象掉大部分硬件独有特性，但是同一套程序未必在每款GPU上都工作得那么好，甚至可能会有一些意想不到的BUG。由于GPU端的调试始终比较麻烦，所以一旦发生问题去寻找BUG也是个问题～
所以，个人感觉现在玩OpenCL的话，主要就是AMD平台比较合适。如果是用nVidia的话，还是用CUDA比较好。尽管Intel现在也发布了OpenCL1.2 SDK，但只有瘟抖死版本，没有Linux版本的，所以这个对于要在服务器上做高性能计算的几乎就没啥可用的，根本就无法商用。
如果你用的是Mac，那么也只能在15英寸的MacBook Pro或是Mac Pro上玩。当然，2012年版本的带有AMD Radeon HD 6630M GPU的Mac Mini也能玩玩OpenCL1.1。
Sanicle 2013-09-10
- 打赏
- 举报
直接讨论opencv就火了。。。
lcwyylcwyy 2013-09-10
- 打赏
- 举报
CV只是图像领域，CL还可以有很多领域，比如，流体模拟，光线跟踪，随机数生成等等。
