多线程

图像处理的多线程计算

图像处理的算法复杂度通常都比较高,计算也相应比较耗时。利用CPU多线程处理能力可以大幅度加快计算速度。但是,为了保证多线程处理的结果和单线程处理的结果完全相同,图像的多线程计算有一些需要特别考虑的地方。

基本思路:为了能让多个线程同时并行处理,那么各自处理的数据不能有交集,这很好理解。那么基本思路是将一副图像分成多个子块,每个子块数据肯定是没有交集的,每个线程对一个子块数据进行处理,完成后将所有子块处理结果合成最终图像。

首先,每个子块的大小当然是必须考虑的问题。通常当应用进行一个较长时间的操作,应该用合适的方式告知用户。既然我们把图像分子块处理,如果单个子块处理时间很短,那么每当有一个子块的数据处理完成,我们就可以立即把它相应的处理结果展示给用户。用户就会看到这个图像各个部分的处理结果不断展示出来,直至整个图像完成。这样某种程度上用这种方式就是在告知用户正在处理进行中,避免为了把整个图像处理完成,用户需要等待太长时间。从这个角度来说,如果子块尺寸取的太大,每个子块计算时间肯定相应地加长,对于快速显示部分处理结果给用户是不利的。但是如果子块太小,子块总数就会增加,肯定会增加线程开销和其他一些开销(分割图像,分配子块数据等等),对于总的计算时间是不利的。这是一个权衡问题,可以根据具体情况确定。

cocos2d-x多线程渲染的一些探讨

可行性:

游戏循环主要包括这几个部分:
1、硬件事件,主要就是指触屏事件,按键事件和鼠标事件;
2、游戏事件,主要指定时器事件和预定义事件,比如schedule;
3、游戏逻辑,对于胖脚本端来说,这个就指的脚本逻辑;
4、渲染数据的生成,在引擎里面就是指node的visit,这里计算生成所有即将发往OpenGL的数据,包括顶点纹理坐标等attribute数据,变换矩阵纹理等uniform数据,混合模式等渲染状态;
5、通过OpenGL接口把所有数据发往OpenGL。

这几个步骤里面,只有第五个步骤需要涉及到OpenGL操作,而前面四个步骤都是为第五个步骤做准备,而第五个步骤不用或者很少需要反馈数据给前面四个步骤。这是一个典型的生产者消费者模式,在很低线程同步开销的情况下课采用多线程处理。

必要性:

处理游戏逻辑(包括前四个步骤)承担了太多cpu运算,而发数据到OpenGL也相当耗时,尤其涉及到多次的渲染状态切换。在多核cpu上面把二者分开可以提高并行性,进而提高游戏帧率。

一些方案:

基础知识:线程,进程。多进程,多线程。并发,并行的区别

一、线程与进程

1.概念

线程:是程序执行流的最小单元,是系统独立调度和分配CPU(独立运行)的基本单位。

进程:是资源分配的基本单位。一个进程包括多个线程。

2.区别:

1.线程与资源分配无关,它属于某一个进程,并与进程内的其他线程一起共享进程的资源。

2.每个进程都有自己一套独立的资源(数据),供其内的所有线程共享。

3.不论是大小,开销线程要更“轻量级”

4.一个进程内的线程通信比进程之间的通信更快速,有效。(因为共享变量)

二、多线程与多进程

多线程:同一时刻执行多个线程。如,用浏览器一边下载,一边听歌,一边看视频,一边看网页......

图像处理的多线程计算

图像处理的算法复杂度通常都比较高,计算也相应比较耗时。利用CPU多线程处理能力可以大幅度加快计算速度。但是,为了保证多线程处理的结果和单线程处理的结果完全相同,图像的多线程计算有一些需要特别考虑的地方。

基本思路:为了能让多个线程同时并行处理,那么各自处理的数据不能有交集,这很好理解。那么基本思路是将一副图像分成多个子块,每个子块数据肯定是没有交集的,每个线程对一个子块数据进行处理,完成后将所有子块处理结果合成最终图像。

首先,每个子块的大小当然是必须考虑的问题。通常当应用进行一个较长时间的操作,应该用合适的方式告知用户。既然我们把图像分子块处理,如果单个子块处理时间很短,那么每当有一个子块的数据处理完成,我们就可以立即把它相应的处理结果展示给用户。用户就会看到这个图像各个部分的处理结果不断展示出来,直至整个图像完成。这样某种程度上用这种方式就是在告知用户正在处理进行中,避免为了把整个图像处理完成,用户需要等待太长时间。从这个角度来说,如果子块尺寸取的太大,每个子块计算时间肯定相应地加长,对于快速显示部分处理结果给用户是不利的。但是如果子块太小,子块总数就会增加,肯定会增加线程开销和其他一些开销(分割图像,分配子块数据等等),对于总的计算时间是不利的。这是一个权衡问题,可以根据具体情况确定。

深度分析异构技术如何让性能功耗鱼与熊掌兼得?

作者:Dev Tech

一般来讲高性能处理器都会采用深度压缩、多管道、分支预测和动态执行等技术来最大限度的提升性能,但是这也都是有代价的,尤其会影响功率的效率。

如果这些任务是可以并行执行的,那么就可以采用更多CPU的解决方案,不仅提升了性能还提高了功率效率。为了实现这个功能,CPU供应商开始提供多核和多集群的解决方案,此外操作系统和应用开发者们也开始调整他们的软件设计来利用这些特性。

随着时间的推移应用的性能要求也在不断的变化,因此如果可能,我们需要将它们移植到更高效的CPU上来执行提升功效。对于专业的计算密集型任务,专用的加速器能够提供非常好的功效,但是不宜长时间使用。

当异构处理器时代到来,从性能和低功耗的角度来看我们需要考虑哪些因素呢?不妨看看下面几条。

多线程

对话Imagination:畅谈MIPS架构处理器的未来

作者,张国斌
MIPS架构处理器是全球最早的RISC处理器也是最早推出64位架构的处理器,与ARM处理器专注移动便携领域不同,MIPS处理器在数字电视、网络应用、机顶盒、ADAS、物联网等领域有广泛应用,随着人工智能时代来临,MIPS架构处理器有哪些新的发展趋势?在最近闭幕的CES2017上,我采访了著名的IP处理器供应商Imagination公司MIPS 处理器 IP 执行副总裁Jim Nicholas,与他就MIPS处理器未来发展进行了互动,他分享了MIPS架构处理器未来发展的策略。

【资料下载】MIPS架构之多线程介绍

当今包括智能手机、平板电脑、IP机顶盒、智能家用网关和SSD存储设备在内的各种嵌入式设备的功能性、互联性和应用的丰富性都在不断升级。这些功能先进的设备拥有巨大的需求空间,随之而来的也有各种特有的挑战。片上系统 (SoC) 供应商和原始设备制造商 (OEMs) 们必须以尽可能低的成本创造高产量,满足各种富有挑战性的性能要求,针对时延敏感的流量支持“服务质量” (QoS) 技术,尤其是在要求超低功耗的移动应用中,还必须对功率损耗进行管控。在如此大需量的中端应用领域保持性能、功率损耗和成本之间的平衡,这样激烈的挑战前所未有。

为应对这些挑战,SoC供应商们有几种选择。提高处理器的时钟频率,从而大幅提升性能;但这并不是最理想的解决方案,因为它也大幅加剧了功率损耗。另一种选择是采用多核,以此分散处理负载,进而实现性能提升。但这种方法可能因IP授权、生产 (因硅芯片尺寸较大) 和功率损耗而导致成本增加。

Vulkan:扩展到多个线程

我们发布了系列有关Vulkan的文章——希望您已阅读其他文章或已关注我们的在线研讨会。

本文将讨论扩展到多个线程的重要性,以及Vulkan如何实现这一目标。

CPU瓶颈——redux

现代CPU有多个内核,在此我不过多讨论。为了获得特定CPU的最佳性能,通过多线程来充分利用这些额外的内核至关重要。如果不有效利用这些内核,你会局限于单个内核的性能——很多性能(效率)不能被合理利用。之前,我编写了相关代码,即GPU在CPU上保持无期限等待状态,以此作为具有高CPU消耗的低效API函数。但即使高消耗,这一问题也可能通过传播到多个线程而有所缓和。

如果您细看我们Gnome Horde 演示上的CPU图表,您会发现即便是相同的内容,OpenGL ES的峰值仍会高很多。内核0和内核1在不断消耗,性能也大为降低。但有四个Intel CPU内核在Nexus player上可用,且其中两个似乎处于备用闲置状态。实际上,确有三个内核在给定时间内处于闲置状态。您看到两个内核状态活跃的唯一原因是,操作系统在内核之间进行线程跳跃,以试图保持芯片冷却。

Android 多线程-----AsyncTask详解

本篇随笔将讲解一下Android的多线程的知识,以及如何通过AsyncTask机制来实现线程之间的通信。

一、Android当中的多线程
在Android当中,当一个应用程序的组件启动的时候,并且没有其他的应用程序组件在运行时,Android系统就会为该应用程序组件开辟一个新的线程来执行。默认的情况下,在一个相同Android应用程序当中,其里面的组件都是运行在同一个线程里面的,这个线程我们称之为Main线程。当我们通过某个组件来启动另一个组件的时候,这个时候默认都是在同一个线程当中完成的。当然,我们可以自己来管理我们的Android应用的线程,我们可以根据我们自己的需要来给应用程序创建额外的线程。

Vulkan:多线程命令的生成

OpenGL ES的命令生成和命令提交毫无区别。当调用“glDraw”,所有当前的状态都将转换供硬件消耗的状态,并提交执行。生成的命令实际上是一个相当耗成本的操作(OpenGL ES的低效率更是让其雪上加霜)。且由于需要将所有提交的命令序列化,因此每次命令的生成需要在线程上完成。

对于Vulkan,生成和提交是两个完全不同的概念。命令首先记录在命令缓冲区对象中,然后再提交给硬件队列。这使应用程序可在其他线程中记录命令缓冲区,且事实上也可在多个线程中记录命令缓冲区,只是提交的CPU操作成本比较低,可以在任何一个线程中完成且影响甚小。

Vulkan

这使得分工更加有效,扩展至多线程的记录不会带来额外的处理成本。

记录成本可能使命令难以扩展——命令缓冲区需要记录内存,但不可能事先了解需要多少内存。在基层分配内存是一个全局性的操作——需要某种形式的锁定且阻塞其他线程。为了缓解这个问题,命令缓冲区使用了几个不同的策略来避免使用系统内存:

同步内容
--电子创新网--
粤ICP备12070055号