为什么跑程序是gpu比cpu慢，还慢很多

显卡gpu处于CPU下游，程序运行，都是先CPU控制硬盘读写软件运行部分到内存中，CPU开始运算输出图形构架，只有CPU输出指令和显示数据传输到gpu中，显卡才开始运算数据，给图像框架贴图，渲染，输出到显示器显示出来。

原载于机锋论坛galaxy II 9100（盖世兔）专区——2012-1-20日

-----------------原文的分割线-----------------

相信好多同学苦于兔子的耗电，看到省电牛核之后，又发现好多人说刷过之后会烧CPU，遂纠结在刷与不刷之间，下面给出我的一些看法。（新人第一次发帖，请大家轻飞板砖，大过年的，飞点金砖吧^__^）

俺对省电、降压、烧CPU的一些看法：

由于前两周刚刚入手兔子，使用中惊讶发现，这不是兔子，是电耗子。。。所以到处寻找解决办法，前天看到了这个帖子，刚刚想刷，发现底下有关于烧CPU的争论，于是考虑了一下，其实，在我看来，这是一个简单的物理题，基于能量守恒定理，电池就那么大的容量（只能提供固定的能量），想要延长使用时间，则必须降低功耗。而牛核的原理是基于降低电池给硬件的“供给”电压（不是充电电源电压，也不是电池电压，是电池给硬件的“输出”电压）来实现降低功率，从而实现节电。从公式P=UI就能看出（这个公式不需要解释吧=。=），平时使用中，U降低，P一定会下降，所以会感觉到明显省电。

可能有的同学会问，这么简单的原理，难道三星不会做，非要让我们自己来？OK，听我下面再慢慢道来。

其实每个机器CPU的最大功率（额定功率）都是一定的（不超频情况下），也就是P最大值一定（这个很好理解吧？好吧，这个不好理解，好多同学回复都在纠结它为啥是一定的？其实，可以把它理解为额定功率，就像平常的家用电器，上面都会标注一个额定功率：P=xx瓦），当你运行大程序时，我们假设一个极限情况，CPU耗用到了上限（实际消耗功率=额定功率），再看P=UI这个公式，P一定（实际消耗功率已经跑到了硬件额定功率的上限），U被人为降低，则I（电流）必须增大才能保持住P不变，而机器硬件对电流的承载也是有上限的，当超过这个上限。。。现在明白为什么会烧CPU了么？

再来解释一下三星为什么不做。像这种大公司，每出一款产品，为保证品质会做很多种测试（尤以苹果为最），他们会根据测试结果给定机器最后参数，诚如世界上没有完美的人一样，也没有完美的产品，在“提高电压参数，耗电”和“降低电压参数，有一定几率烧硬件”这两个测试结果中，三星一定会选择前者，毕竟在消费者眼中，耗电和烧硬件，孰轻孰重？其实所有大公司做这种决定，一定是偏向保守和危险性小的那种。

说到最后再多解释一下，我不是反对牛核，更不是反对大家去刷，上面我也提到过，三星设定的电压参数，一定是趋于“保守”的，对于平时手机正常使用（待机）来说，确实有些浪费，所以，我的建议是：

只用手机发短信打电话的——极限版或中和版

偶尔玩玩小游戏，装装软件的——正常版或中和版

经常跑大型游戏的——还是别闹了，要不就刷正常版拼RP和兔子体质=。=

其实跑大型游戏，即使刷了牛核也基本不会省电，W=PT，P跑到了上限，W（电量）的损耗只和T（时间）有关系，电压和电流都没意义了。

俺考虑再三，最后决定不刷，因为俺属于那种不喜欢刷机，喜欢找一个稳定平衡的ROM，然后装乱七八糟的应用那种，尤其最近刚刚安装了模拟器，感觉那个东西比较耗CPU资源（模拟运算嘛），所以就不拼RP给兔子压力了（俺RP一向拼不赢任何人T_T）。俺目前考虑的省电方向是精简或者关闭系统里面没用的进程和服务，这个还木有太多想法，请有经验的老鸟不吝指点，给些建议、帖子链接或者其它节电方向均可，先拜谢了～

最后声明一下，俺不是专家，没有做过芯片级的研究，没有做过android的开发，兔子也是这个月刚入手，有的仅仅是多年电脑、手机玩家经验，以及IT从业者相关经验，所以，上面所说的东西，可能会似是而非，面对真正的专家会贻笑大方，可以指正，请勿喷，谢谢！

------------回复节选--------------

——呵呵，感觉像是回到了初中。。。

当初我们学习的教材，U（电压）=I（电流）R（电阻），现在电阻R改用Z了么？

我们已知不变的条件：W是电池容量，不变（其实会变，我们考虑理想状况）；R是机器硬件电阻，不变

我们假设两种情况：待机和跑极限大游戏

待机时：P可变。根据U=IR，U下降，R不变，I下降；根据P=UI，UI均下降，P随之下降，这个没有疑问吧？所以待机用牛核必然是省电的。

跑极限大游戏：P不变。为什么P会不变？这个可能是没有理解的地方，当执行极限大程序，CPU达到处理能力的上限时，也就是达到了额定功率（最大功率），这时P就会不变（想再变大，除非它是变形金刚能自我进化=。=；想变小？对不起，大程序不让，一条接一条的指令需要你来运算，赶紧跑吧您nei。。。其实也会变化，游戏也好，软件也好，会有相应的释放机制，由于影响很小，我们忽略不计，仍然考虑理想状况），这个能理解吗？所以目前有三个不变条件：W，R，P，根据P=UI，P不变，U下降，则I必须上升；根据W=PT，P不变，电池电量损耗，只和时间有关系，所以，用牛核跑大游戏，基本不会省电。

这个证明应该比较清晰了吧，其实这里基本没有R什么事。。。

百度了一下TDP，全称是“Thermal Design Power”，中文直译“散热设计功耗”。CPU TDP值对应CPU 在满负荷(CPU 利用率为100%)可能会达到的最高散热热量，散热器必须保证在处理器TDP最大的时候，CPU的温度仍然在设计范围之内。

还有一段，内容不错，我直接照搬下来了：

CPU的TDP功耗并不是CPU的真正功耗。功耗（功率）是CPU的重要物理参数，根据电路的基本原理，功率（P）=电流（A）×电压（V）。所以，CPU的功耗（功率）等于流经处理器核心的电流值与该处理器上的核心电压值的乘积。而TDP是指CPU电流热效应以及其他形式产生的热能，他们均以热的形式释放。显然CPU的TDP小于CPU功耗。换句话说，CPU的功耗很大程度上是对主板提出的要求，要求主板能够提供相应的电压和电流；而TDP是对散热系统提出要求，要求散热系统能够把CPU发出的热量散掉，也就是说TDP功耗是要求CPU的散热系统必须能够驱散的最大总热量。

呵呵，看完这些可能会更好理解一些了吧。换句话说，做用于CPU为它提供能量的，只有两个：电压、电流（木有其它的东西了吧？），所以，CPU能够承受的理论电压（U）上限和理论电流（I）上限值，就是它的理论功耗P上限。能量是可以转化的，再根据能量守恒，入=出，所以CPU的功耗，一部分做功（W）用于系统运算了，而另一部分就损失在了发热（Q）上。所以，PT（时间）=W（做功）+Q（热量）

可能你将我前文中的P，理解为了上面说的W（做功）。另外你说的“光加电压不超频比不加压超频耗电都要来得猛”也是这个道理，光加压不超频，其实等同于PT上限没有变化，刚刚运行阶段，或者不满负荷运行的时候，提速很明显；但是满负荷运行的时候，速度和没加压之前基本没区别，而提高的电压，基本都用于发热了。而超频之后，相当于提高了上面的PT上限值，即使满负荷运行，虽然Q会上升，但是W也是会上升（主频升高，处理能力增强）的。

具体的热功耗计算方法，实在太复杂了，和本文没有太大关系，所以就不赘述了（俺也没那个水平T_T），有兴趣的话，可以百度（其实俺百度出来一篇，新人木有发链接权限呀。。。）

其实，由于CPU并不是每时每刻都在进行大量运算，核心电压与核心电流时刻都处于变化中，是瞬时值，所以我们只考虑待机和满负荷两种极限形态下的理想状况。

可能我们的描述过于繁琐了，你提到的“有个问题楼主没闹明白。降低电压的主要目的就是为了降低CPU的功率，并不是楼主所说，功率恒定不变。”这点我是同意的，因为待机时，CPU没有跑到上限，所以降低电压，CPU功率是降低的，P（额定输出功率）T > P（实际输出功率）T+Q（发热，这里忽略）。所以牛核在待机方面省电效果明显。

当另外一种情况，跑大游戏，将CPU达到耗用上限（CPU100%），这个时候，CPU输出功率也达到了上限值，基本不变了（这是我说的功率不变情况）P（额定输出功率）T=W（运算做功）+Q（发热）=P（实际输出功率）T+Q（发热）。所以牛核跑大游戏省电效果不会很明显。

降压脚本的大概原理应该是根据CPU不同频率，给定不同的电压。

嗯，我之前推测确实存在部分误区，猜测牛核可能是设定一个电压上限，然后根据程序不同，电压进行自适应，木有想到会通过降压脚本，划分CPU频率按step进行控制。如果CPU跑到极限，不降低电压，那么确实风险要小很多（或者说和没刷之前一样）。但同时，如果某个或某几个step给定的电压值接近物理极限，体质不好的兔子不需要跑极限大程序，可能同样也会出问题，而且几率会更大。不过大体上，这个和我的表述并不冲突，可能是我之前写的太罗嗦了。。。

作者 王文安，腾讯CSIG数据库专项的数据库工程师，主要负责腾讯云数据库 MySQL 的相关的工作，热爱技术，欢迎留言进行交流。文章首发于腾讯云+社区的腾讯云数据库专家服务专栏。

在日常工作中，发现 MySQL 的状态不太对劲的时候，一般都会看看监控指标，很多时候会看到熟悉的一幕：CPU 使用率又爆了。本文将给大家介绍 MySQL 和 CPU 之间的关系，对此有一定的了解之后可以更准确的判断出问题的原因，也能够提前发现一些引发 CPU 问题的隐患。

怎么看懂CPU使用率

以 Linux 的 top 命令为例，效果如下：

Top 命令

在 %CPU 这一列就展示了 CPU 的使用情况，百分比指代的是总体上占用的时间百分比：

%us：表示用户进程的 CPU 使用时间(没有通过 nice 调度)

%sy：表示系统进程的 CPU 使用时间，主要是内核使用。

%ni：表示用户进程中，通过 CPU 调度(nice)过的使用时间。

%id：空闲的 CPU 时间

%wa：CPU 运行时在等待 IO 的时间

%hi：CPU 处理硬中断花费的时间

%si：CPU 处理软中断花费的时间

%st：被虚拟机偷走的 CPU 时间

通常情况下，我们讨论的 CPU 使用率过高，指的是 %us 这个指标，监控里面的 CPU 使用率通常也是这个值(也有用其他的方法计算出来的，不过简单起见，不考虑其他的情况 )。其他几个指标过高也代表出 MySQL 的状态异常，简单起见，这里主要还是指 %us 过高的场景。

MySQL和线程

MySQL 是单进程多线程的结构，意味着独占的 MySQL 服务器里面，只能用 top 命令看到一行数据。

TOP 命令效果

这里能看到的是 MySQL 的进程 ID，如果要看到线程的情况，需要用top -H

TOP 命令效果

在这里能看到的是 MySQL 各个线程的 ID，可以看到 MySQL 在启动之后，会创建非常多的内部线程来工作。

这些内部线程包括 MySQL 自己用来刷脏，读写数据等 *** 作的系统线程，也包括处理用户 SQL 的线程，姑且叫做用户线程吧。用户线程有一个特殊的地方：程序端发送到 MySQL 端的 SQL，只会由一个用户线程来执行(one-thread-per-connection)，所以 MySQL 在处理复杂查询的时候，会出现“一核有难，多核围观”的尴尬现象。

参考 %us 的定义，对于 Linux 系统来说，MySQL 进程和它启动的所有线程都不算内核进程，因此 MySQL 的系统线程和用户线程在繁忙的时候，都会体现在 CPU 使用率的 %us 指标上。

什么时候CPU会100%

MySQL 干什么的时候，CPU 会 100%？从前文的分析来看，MySQL 主要是两类线程占用 CPU：系统线程和用户线程。因此 MySQL 独占的服务器上，只需要留意一下这两类线程的情况，就能 Cover 住绝大部分的问题场景。

系统线程

在实际的环境中，系统线程遇到问题的情况会比较少，一般来说，多个系统线程很少会同时跑满，只要服务器的可用核心数大于等于 4 的话，一般也不会遇到 CPU 100%，当然有一些 bug 可能会有影响，比如这个：

MySQL BUG

虽然情况比较少，但是在面对问题的常规排查过程中，系统线程的问题也是需要关注的。

用户线程

提到用户线程繁忙，很多时候肯定会第一时间凭经验想到慢查询。确实 90% 以上的时候都是“慢查询”引起的，不过作为方法论，还是要根据分析再去得出结论的~

参考 us% 的定义，是指用户线程占用 CPU 的时间多少，这代表着用户线程占用了大量的时间。

一方面是在进行长时间的计算，例如：order by，group by，临时表，join 等。这一类问题可能是查询效率不高，导致单个 SQL 语句长时间占用 CPU 时间，也有可能是单纯的数据量比较多，导致计算量巨大。另一方面是单纯的 QPS 压力高，所以 CPU 的时间被用满了，比如 4 核的服务器用来支撑 20k 到 30k 的点查询，每个 SQL 占用的 CPU 时间并不多，但是因为整体的 QPS 很高，所以 CPU 的时间被占满了。

问题的定位

分析完之后，就要开始实战了，这里根据前文的分析给出一些经典的 CPU 100% 场景，并给出简要的定位方法作为参考。

PS：系统线程的 bug 的场景 skip，以后有机会再作为详细的案例来分析。

慢查询

在 CPU 100% 这个问题已经发生之后，真实的慢查询和因为 CPU 100% 导致被影响的普通查询会混在一起，难以直观的看 processlist 或者 slowlog 来发现尊敬的大船，这时候就需要一些比较明确的特征来进行甄别。

从前文的简单分析可以看出来，查询效率不高的慢查询通常有以下几种情况：

全表扫描：Handler_read_rnd_next 这个值会大幅度突增，且这一类查询在 slowlog 中 row_examined 的值也会非常高。

索引效率不高，索引选错了：Handler_read_next 这个值会大幅度的突增，不过要注意这种情况也有可能是业务量突增引起的，需要结合 QPS/TPS 一起看。这一类查询在 slowlog 中找起来会比较麻烦，row_examined 的值一般在故障前后会有比较明显的不同，或者是不合理的偏高。

比如数据倾斜的场景，一个小范围的 range 查询在某个特定的范围内 row_examined 非常高，而其他的范围时 row_examined 比较低，那么就可能是这个索引效率不高。

排序比较多：order by，group by 这一类查询通常不太好从 Handler 的指标直接判断，如果没有索引或者索引不好，导致排序 *** 作没有消除的话，那么在 processlist 和 slowlog 通常能看到这一类查询语句出现的比较多。

当然，不想详细的分析 MySQL 指标或者是情况比较紧急的话，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做个简单的除法，比如 row_examined/rows_sent > 1000 的都可以拿出来作为“嫌疑人”处理。这类问题一般在索引方面做好优化就能解决。

PS：1000 只是个经验值，具体要根据实际业务情况来定。

计算量大

这一类问题通常是因为数据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼，反而是 slowlog 里面可能找不到，因为没有执行完的语句是不会记录的。

这一类问题一般来说有三种比较常规的解决方案：

读写分离，把这一类查询放到平时业务不怎么用的只读从库去。

在程序段拆分 SQL，把单个大查询拆分成多个小查询。

使用 HBASE，Spark 等 OLAP 的方案来支持。

高 QPS

这一类问题单纯的就是硬件资源的瓶颈，不论是 row_examined/rows_sent 的比值，还是 SQL 的索引、执行计划，或者是 SQL 的计算量都不会有什么明显问题，只是 QPS 指标会比较高，而且 processlist 里面可能什么内容都看不到，例如：

processlist

总结

实际上 CPU 100% 的问题其实不仅仅是单纯的 %us，还会有 %io，%sys 等，这些会涉及到 MySQL 与 Linux 相关联的一部分内容，展开来就会比较多了。本文仅从 %us 出发尝试梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的问题时，也可以用类似的思路，从这些指标的意义开始，结合 MySQL 的一些特性或者特点，逐步理清楚表象背后的原因。

以上就是关于为什么跑程序是gpu比cpu慢，还慢很多全部的内容，包括:为什么跑程序是gpu比cpu慢，还慢很多、关于Android手机刷降压省电内核烧硬件的看法、数据库消耗内存大还是cpu大等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！