a*1
4 楼
并行吧,能上GPU计算的当然GPU快的多
i*t
5 楼
我知道的 就是5-10倍的样子
当然有更快的 我就不知道了
当然有更快的 我就不知道了
w*r
6 楼
有篇paper, 大概是说,通过最好的优化,也就是5倍的样子。
E*e
7 楼
http://www.mathworks.com/products/distriben/examples.html?file=
随便哪个结果,你觉得CPU上10秒以内能跑完?
【在 w********r 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 有篇paper, 大概是说,通过最好的优化,也就是5倍的样子。
随便哪个结果,你觉得CPU上10秒以内能跑完?
【在 w********r 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 有篇paper, 大概是说,通过最好的优化,也就是5倍的样子。
r*n
8 楼
我比较过,GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
不同肯定有出入,但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧,这样下
来纯算力GPU也就是5-10倍。但GPU内存小,通常得搬进搬出地算,还有分布后同步啥的
,许多额外开销,所以能到5已经很不错了,还得是小数据,数据量大的GPU可能时间都
浪费在搬家上,还不如CPU。但GPU堆起来比CPU容易可以插很多。
不同肯定有出入,但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧,这样下
来纯算力GPU也就是5-10倍。但GPU内存小,通常得搬进搬出地算,还有分布后同步啥的
,许多额外开销,所以能到5已经很不错了,还得是小数据,数据量大的GPU可能时间都
浪费在搬家上,还不如CPU。但GPU堆起来比CPU容易可以插很多。
i*t
9 楼
技术还在发展嘛
你说的这些问题 估计gpu也带改进了
如果经过一阵发展 能达到快5倍的话 也是很不错的提高啊 对吧
我个人还是觉得gpu是个趋势, 我倒没说 他一定比cpu好 或者占绝对优势
我的意思 这个是很不错的一个提高和可选择办法
【在 r******n 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 我比较过,GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
: 不同肯定有出入,但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧,这样下
: 来纯算力GPU也就是5-10倍。但GPU内存小,通常得搬进搬出地算,还有分布后同步啥的
: ,许多额外开销,所以能到5已经很不错了,还得是小数据,数据量大的GPU可能时间都
: 浪费在搬家上,还不如CPU。但GPU堆起来比CPU容易可以插很多。
你说的这些问题 估计gpu也带改进了
如果经过一阵发展 能达到快5倍的话 也是很不错的提高啊 对吧
我个人还是觉得gpu是个趋势, 我倒没说 他一定比cpu好 或者占绝对优势
我的意思 这个是很不错的一个提高和可选择办法
【在 r******n 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 我比较过,GPU单core的纯运算速度大概是CPU单core的1/20, 具体CPU频率跟显卡档次
: 不同肯定有出入,但应该就在这个数量级。GPU通常有几百个core, CPU4-8吧,这样下
: 来纯算力GPU也就是5-10倍。但GPU内存小,通常得搬进搬出地算,还有分布后同步啥的
: ,许多额外开销,所以能到5已经很不错了,还得是小数据,数据量大的GPU可能时间都
: 浪费在搬家上,还不如CPU。但GPU堆起来比CPU容易可以插很多。
k*z
10 楼
有那个钱为啥不把CPU搞成几百个core的?
E*e
13 楼
几千核了
http://en.wikipedia.org/wiki/GTX_Titan#GeForce_700_.287xx.29_se
【在 z***s 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 啊 gpu都几百核了? 我也太out了。。。。
: voodoo时代的人就是要被淘汰啊。
http://en.wikipedia.org/wiki/GTX_Titan#GeForce_700_.287xx.29_se
【在 z***s 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 啊 gpu都几百核了? 我也太out了。。。。
: voodoo时代的人就是要被淘汰啊。
S*n
14 楼
6000核 指日可待。
S*n
16 楼
http://news.mydrivers.com/1/279/279815.htm
【在 E***e 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 现在关键看双精度和library了。。。
: OpenCL下还是找不到类似CUDA Math和CULA的library
: 上次AMD公开的那个看了半天也就是个BLAS而已,别的啥都没有
【在 E***e 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 现在关键看双精度和library了。。。
: OpenCL下还是找不到类似CUDA Math和CULA的library
: 上次AMD公开的那个看了半天也就是个BLAS而已,别的啥都没有
h*6
17 楼
这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
CPU上跑测下时间 然后比较两个时间
GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
义的
百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
CPU上跑测下时间 然后比较两个时间
GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
义的
S*n
18 楼
NVIDIA正式宣布CUDA 6:支持统一寻址!
NVIDIA今天(2013-11-15)正式宣布了最新版并行计算开发工具CUDA 6,相比此前的CUDA
5.5有着革命性的巨大进步。
NVIDIA表示,CUDA 6可以让并行编程前所未有的轻松,能够显著节省开发人员的时间和
精力,而通过GPU加速可带来最多8倍于CPU模式的性能提升。
CUDA 6的关键新特性包括:
1、统一寻址(Unified Memory):
可直接访问CPU内存、GPU显存,无需在彼此之间手动拷贝数据,可在大量编程语言中更
简单地添加GPU加速支持。
其实CUDA 4就开始支持统一虚拟寻址,x86 CPU、GPU内存池可在同一空间内进行寻址,
但那仅仅是简单的内存管理,摆脱不了手动数据转移。
CUDA 6则在现有的内存池结构上增加了一个统一内存系统,程序员可以直接访问任何内
存/显存资源,或者在合法的内存空间内寻址,而不用管涉及到的到底是内存还是显存。
不过注意,CUDA 6并不是完全不需要数据拷贝,只不过将这个工作从程序员那里接过来
自动执行而已,它仍然受制于PCI-E的带宽和延迟,因此和AMD hUMA异构统一寻址架构
是不一样的。
另外值得一提的是,NVIDIA此前已经宣布下代GPU Maxwell将会支持统一虚拟内存,但
它要到明年才会发布。NVIDIA表示,他们找到了完全通过软件执行统一内存的方法,所
以就提前这么做了,Maxwell则会有某种硬件层面的统一内存技术(或许性能更高),但
具体细节还有待公布。
2、替换库(Drop-in Libraries):
简单地用GPU加速库替换已有的CPU库,BLAS(基础线性代数程序集)、FFTW(快速傅立叶
变换)计算即自动提速最多8倍。
3、多GPU支持(Multi-GPU Scaling):
重新设计的BLAS、FFT GPU库,单个节点可自动支持最多八颗GPU,双精度浮点性能可超
过9TFlops,并且支持最多512GB的更大负载。
此外,CUDA 6平台还会提供一整套的编程工具、GPU加速数学库、文档和编程指导。
CUDA 6目前只是纸面宣布,2014年初才会开放下载。
【在 h******6 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
NVIDIA今天(2013-11-15)正式宣布了最新版并行计算开发工具CUDA 6,相比此前的CUDA
5.5有着革命性的巨大进步。
NVIDIA表示,CUDA 6可以让并行编程前所未有的轻松,能够显著节省开发人员的时间和
精力,而通过GPU加速可带来最多8倍于CPU模式的性能提升。
CUDA 6的关键新特性包括:
1、统一寻址(Unified Memory):
可直接访问CPU内存、GPU显存,无需在彼此之间手动拷贝数据,可在大量编程语言中更
简单地添加GPU加速支持。
其实CUDA 4就开始支持统一虚拟寻址,x86 CPU、GPU内存池可在同一空间内进行寻址,
但那仅仅是简单的内存管理,摆脱不了手动数据转移。
CUDA 6则在现有的内存池结构上增加了一个统一内存系统,程序员可以直接访问任何内
存/显存资源,或者在合法的内存空间内寻址,而不用管涉及到的到底是内存还是显存。
不过注意,CUDA 6并不是完全不需要数据拷贝,只不过将这个工作从程序员那里接过来
自动执行而已,它仍然受制于PCI-E的带宽和延迟,因此和AMD hUMA异构统一寻址架构
是不一样的。
另外值得一提的是,NVIDIA此前已经宣布下代GPU Maxwell将会支持统一虚拟内存,但
它要到明年才会发布。NVIDIA表示,他们找到了完全通过软件执行统一内存的方法,所
以就提前这么做了,Maxwell则会有某种硬件层面的统一内存技术(或许性能更高),但
具体细节还有待公布。
2、替换库(Drop-in Libraries):
简单地用GPU加速库替换已有的CPU库,BLAS(基础线性代数程序集)、FFTW(快速傅立叶
变换)计算即自动提速最多8倍。
3、多GPU支持(Multi-GPU Scaling):
重新设计的BLAS、FFT GPU库,单个节点可自动支持最多八颗GPU,双精度浮点性能可超
过9TFlops,并且支持最多512GB的更大负载。
此外,CUDA 6平台还会提供一整套的编程工具、GPU加速数学库、文档和编程指导。
CUDA 6目前只是纸面宣布,2014年初才会开放下载。
【在 h******6 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
E*e
19 楼
感觉全都是噱头啊
j*n
20 楼
我上次挖矿bitcoin,用CPU和GPU分别试了一下,差别还是蛮大的:
CPU i7 4770k: 1Mps
GPU AMD 7950: 500Mps
CPU i7 4770k: 1Mps
GPU AMD 7950: 500Mps
S*n
21 楼
intel说以后会在Xeon phi中集成一个独立的能boot system的CPU。
以后就是一张卡,一个64位CPU(2-12核不等)外加近百个x86 cores.
以后就是一张卡,一个64位CPU(2-12核不等)外加近百个x86 cores.
x*o
24 楼
以前GPU对应单核或者双核的CPU有很大的优势,现在intel Xeon i7系列一颗CPU可以10
个core 20个thread,一个服务器加四个CPU很轻松到80个thread。 做计算的几乎所有
的代码都是对CPU优化,再加上内存,CPU做计算不用花多少时间就可以了。
个core 20个thread,一个服务器加四个CPU很轻松到80个thread。 做计算的几乎所有
的代码都是对CPU优化,再加上内存,CPU做计算不用花多少时间就可以了。
O*d
27 楼
游戏是典型的GPU应用。 每个像素的计算基本上是独立的,例如计算色彩的混合,光线
的反射,前后物体的遮挡,像素点在空间的平移旋转,GPU可以轻易地每秒计算几千万
到上亿个像素值,CPU根本玩不转。
的反射,前后物体的遮挡,像素点在空间的平移旋转,GPU可以轻易地每秒计算几千万
到上亿个像素值,CPU根本玩不转。
O*d
28 楼
GPU的硬件,就是优化来做浮点运算的,所以特别适合解决数学问题。 所以GPU的算法
,最好少用branching,就是少用if-else。 每个计算单元不要太大太复杂。 例如像素
的颜色混合,就是把两种颜色按照你的意愿,混合成第三种颜色。 GPU的thread有上千
,并且启动thread的overhead基本是零。 如果你把问题分解成几百万个小单元,GPU
的几千个thread可以非常快速地扫过这几百万个单元。
,最好少用branching,就是少用if-else。 每个计算单元不要太大太复杂。 例如像素
的颜色混合,就是把两种颜色按照你的意愿,混合成第三种颜色。 GPU的thread有上千
,并且启动thread的overhead基本是零。 如果你把问题分解成几百万个小单元,GPU
的几千个thread可以非常快速地扫过这几百万个单元。
E*e
29 楼
i*t
30 楼
恩
还是要看算法
看你能不能吧原来问题分解成独立的 如果能 性能肯定大幅度提高 否则 提高不大
所以说还是看1 问题 2算法
【在 h******6 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
还是要看算法
看你能不能吧原来问题分解成独立的 如果能 性能肯定大幅度提高 否则 提高不大
所以说还是看1 问题 2算法
【在 h******6 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
: 百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
: 并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
: CPU上跑测下时间 然后比较两个时间
: GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
: 员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
: 成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
: 义的
O*d
31 楼
if-else的杀伤力到底有多大,我也不是很知道。 我读过的材料,一般都说要保持
kernel的code小,复杂度要低,最好是直接运算,不要把时间花在条件判断上。 如果
你要在kernel里运行循环,如果循环的次数是compile time已知的,最好把循环展开,
而不是每次要判断循环的次数。
适合GPU的数学问题,一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
杂,还需要进一步分解。 例如,给出一个一维函数值,给每个点做一个三次方插值,
给插的值赋予颜色,再把相邻的两个颜色做平均。 你需要写三个kernel function。
第一个做插值,第二个做赋予颜色,第三个做颜色平均。 每个kernel做的事情比较简
单。 用GPU把这三个kernel串联扫过去,每扫一次kernel时,例如插值,需要把插值
kernel在全部数值上完成,才走下一个kernel。 当然你需要考虑边界数值的问题,例
如在index是0时,或index是最大值时,插值的算法不太一样, 不要在kernel里考虑边
界值,只把非边界的数值送到GPU去计算,边界值用普通CPU来计算,这样你可以减少if
-else的使用
【在 E***e 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: if else杀伤力有多大?我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛?
kernel的code小,复杂度要低,最好是直接运算,不要把时间花在条件判断上。 如果
你要在kernel里运行循环,如果循环的次数是compile time已知的,最好把循环展开,
而不是每次要判断循环的次数。
适合GPU的数学问题,一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
杂,还需要进一步分解。 例如,给出一个一维函数值,给每个点做一个三次方插值,
给插的值赋予颜色,再把相邻的两个颜色做平均。 你需要写三个kernel function。
第一个做插值,第二个做赋予颜色,第三个做颜色平均。 每个kernel做的事情比较简
单。 用GPU把这三个kernel串联扫过去,每扫一次kernel时,例如插值,需要把插值
kernel在全部数值上完成,才走下一个kernel。 当然你需要考虑边界数值的问题,例
如在index是0时,或index是最大值时,插值的算法不太一样, 不要在kernel里考虑边
界值,只把非边界的数值送到GPU去计算,边界值用普通CPU来计算,这样你可以减少if
-else的使用
【在 E***e 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: if else杀伤力有多大?我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛?
E*e
32 楼
看了大牛的描述,简单粗暴的原始人表示情绪十分稳定 lol
【在 O*******d 的大作中提到】![](/moin_static193/solenoid/img/up.png)
: if-else的杀伤力到底有多大,我也不是很知道。 我读过的材料,一般都说要保持
: kernel的code小,复杂度要低,最好是直接运算,不要把时间花在条件判断上。 如果
: 你要在kernel里运行循环,如果循环的次数是compile time已知的,最好把循环展开,
: 而不是每次要判断循环的次数。
: 适合GPU的数学问题,一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
: 杂,还需要进一步分解。 例如,给出一个一维函数值,给每个点做一个三次方插值,
: 给插的值赋予颜色,再把相邻的两个颜色做平均。 你需要写三个kernel function。
: 第一个做插值,第二个做赋予颜色,第三个做颜色平均。 每个kernel做的事情比较简
: 单。 用GPU把这三个kernel串联扫过去,每扫一次kernel时,例如插值,需要把插值
: kernel在全部数值上完成,才走下一个kernel。 当然你需要考虑边界数值的问题,例
【在 O*******d 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: if-else的杀伤力到底有多大,我也不是很知道。 我读过的材料,一般都说要保持
: kernel的code小,复杂度要低,最好是直接运算,不要把时间花在条件判断上。 如果
: 你要在kernel里运行循环,如果循环的次数是compile time已知的,最好把循环展开,
: 而不是每次要判断循环的次数。
: 适合GPU的数学问题,一般需要把复杂问题分解成独立的小单元。 如果每个单元比较复
: 杂,还需要进一步分解。 例如,给出一个一维函数值,给每个点做一个三次方插值,
: 给插的值赋予颜色,再把相邻的两个颜色做平均。 你需要写三个kernel function。
: 第一个做插值,第二个做赋予颜色,第三个做颜色平均。 每个kernel做的事情比较简
: 单。 用GPU把这三个kernel串联扫过去,每扫一次kernel时,例如插值,需要把插值
: kernel在全部数值上完成,才走下一个kernel。 当然你需要考虑边界数值的问题,例
h*6
40 楼
这么说吧 当一部分线程执行if的时候 应该执行else的那些线程是idle的 然后开始执
行else 此时if的那部分线程是idle的 所以这部分被serialize的非常厉害(branch
divergence)性能也就大打折扣了 尤其是当if和else是被同一个warp里面的线程执行
的时候 总时间=if+else
没什么好办法避免 只能优化你的算法 比如把所有的if放到一起 所有else放到一起 尽
量减少serialization增大overlap的计算
【在 E***e 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
: if else杀伤力有多大?我的应用虽然能并行但是也需要很多if else
: 还需要写min max之类的
: 这些有办法绕过嘛?
E*e
41 楼
if it is just the time cost of "if+else", I could probably live with it...
Thanks a lot!
【在 h******6 的大作中提到】![](/moin_static193/solenoid/img/up.png)
:
: 这么说吧 当一部分线程执行if的时候 应该执行else的那些线程是idle的 然后开始执
: 行else 此时if的那部分线程是idle的 所以这部分被serialize的非常厉害(branch
: divergence)性能也就大打折扣了 尤其是当if和else是被同一个warp里面的线程执行
: 的时候 总时间=if+else
: 没什么好办法避免 只能优化你的算法 比如把所有的if放到一起 所有else放到一起 尽
: 量减少serialization增大overlap的计算
Thanks a lot!
【在 h******6 的大作中提到】
![](/moin_static193/solenoid/img/up.png)
:
: 这么说吧 当一部分线程执行if的时候 应该执行else的那些线程是idle的 然后开始执
: 行else 此时if的那部分线程是idle的 所以这部分被serialize的非常厉害(branch
: divergence)性能也就大打折扣了 尤其是当if和else是被同一个warp里面的线程执行
: 的时候 总时间=if+else
: 没什么好办法避免 只能优化你的算法 比如把所有的if放到一起 所有else放到一起 尽
: 量减少serialization增大overlap的计算
O*d
42 楼
GPU不适合做有复杂逻辑的问题,最适合做直接暴力计算。 如果有复杂逻辑问题,需要
把问题分解成简单的小计算单元。 要知道, GUP的thread启动成本基本上是零。 可以
快速地对一个接一个的kernel计算。
给个例子。
你要种三种菜,莴笋,白菜,萝卜。 你有两种不同的种法。
1。 每棵莴笋白菜萝卜互相为邻,你播种上肥收割,三种菜同时管理。 这是把三个问
题合并在一个单元里。 你在处理每个单元时,要考虑莴笋白菜萝卜的不同处理方法。
2。把地分成三块,每块各种莴笋白菜萝卜。 他们的播种上肥收割是分开的。这是把三
个问题分开。先突击收割莴笋,再突击收割白菜,再突击收割萝卜。 GPU最适合这种方
式解决问题。
把问题分解成简单的小计算单元。 要知道, GUP的thread启动成本基本上是零。 可以
快速地对一个接一个的kernel计算。
给个例子。
你要种三种菜,莴笋,白菜,萝卜。 你有两种不同的种法。
1。 每棵莴笋白菜萝卜互相为邻,你播种上肥收割,三种菜同时管理。 这是把三个问
题合并在一个单元里。 你在处理每个单元时,要考虑莴笋白菜萝卜的不同处理方法。
2。把地分成三块,每块各种莴笋白菜萝卜。 他们的播种上肥收割是分开的。这是把三
个问题分开。先突击收割莴笋,再突击收割白菜,再突击收割萝卜。 GPU最适合这种方
式解决问题。
相关阅读
带IBM Thinkpad标志的早期T系列哪个型号最好?犯了低级错误,机器休眠的时候加内存2015国庆desktop dealthinkpad T450s 和 T440s 电池是通用的吗?dell显示这个底座是真心好啊Intel 10nm 跳票到2016年年底。舔脸要个淘汰的DDR3 2GB即可现在x1 carbon相比其他ultrabook还有啥优势?刚刚下了了单ENVY 750,大家看看配置价格如何?lenovo workstatioin s30 不同时支持DDR3 10600R 和 10600E 吗?请教个扫描仪的问题准备搞NAS,求推荐硬盘X205TA又打折了,纠结SP3 真是鸡肋啊,长草的都可以拔掉了使用SSD的笔记本和比使用HDD到底快多少请推荐一个100刀以下的wireless router要4k满帧是不是要上双980ti?这个显示器不错哈,$810请问linksys N600 / EA2700这个 router怎么样?机箱风的流向。