s*****n
发帖数: 5488 | 1 假设是location 相关数据，数据可以放到内存，新数据可以通过加server扩容，
数据通过mongoDB这种东东存到硬盘上。 |
m********5
发帖数: 17667 | 2 你这个简直就是非要用黄金当车轴, 性能要求不match
GPU不适合做data intensive computing, 光数据上下载就比只用CPU慢多了.
我做过一个项目是data intensive的, 但是它是个特例, 就是数据是稀疏的,可以用很
大压缩率上载给VRAM, 然后再用GPU解压出来算.
做data intensive的人最好看看out of core的概念, 其实CPU消耗根本很低,主要时间
在I/O上
【在 s*****n 的大作中提到】
: 假设是location 相关数据，数据可以放到内存，新数据可以通过加server扩容，
: 数据通过mongoDB这种东东存到硬盘上。
|
s*****n
发帖数: 5488 | 3 理论上GPU带宽更加宽，而且数据都在内存里面，几乎没有I/O。计算都是简单hash,
scan, combine， join. 有500多个核的GPU至少应该有50倍的性能提高。 |
m********5
发帖数: 17667 | 4 你实际用用就知道了
从system RAM上载到VRAM效率是很低很低的
如果你所有数据都能一次性load到VRAM不算data intensive
【在 s*****n 的大作中提到】
: 理论上GPU带宽更加宽，而且数据都在内存里面，几乎没有I/O。计算都是简单hash,
: scan, combine， join. 有500多个核的GPU至少应该有50倍的性能提高。
|
N*****m
发帖数: 42603 | 5 那是指GPU内部带宽，系统内存到GPU太慢了，而且GPU的内存也满足不了data intensiv
e的应用。
GPU适合computation intensive的应用。
【在 s*****n 的大作中提到】
: 理论上GPU带宽更加宽，而且数据都在内存里面，几乎没有I/O。计算都是简单hash,
: scan, combine， join. 有500多个核的GPU至少应该有50倍的性能提高。
|
I******c
发帖数: 163 | 6 多大的数据才算data intensive? 现在gpu的global memory有5，6G了。
另外，数据从cpu主存到gpu global memory的传输是和gpu本身的计算是并行的。即使
你需要传几次数据，传输的时间也是可以被计算的时间tolerated的。
【在 m********5 的大作中提到】
: 你实际用用就知道了
: 从system RAM上载到VRAM效率是很低很低的
: 如果你所有数据都能一次性load到VRAM不算data intensive
|
I******c
发帖数: 163 | 7 最近两年ipdps上有几篇关于在gpu上实现mapreduce的文章。你可以看看。实用不实用
就不知道了。
【在 s*****n 的大作中提到】
: 假设是location 相关数据，数据可以放到内存，新数据可以通过加server扩容，
: 数据通过mongoDB这种东东存到硬盘上。
|
I******c
发帖数: 163 | 8 GPU上跑程序得到的speedup有时候取决于gpu内存的带宽。现在gpu内存的带宽虽然比
cpu的快，但是有没有快50倍？ 另外，我个人理解gpu的带宽是指在最佳情况下，比如
说所有内存的读写都是coalesce了，这个在实际中并不是都可以实现。
【在 s*****n 的大作中提到】
: 理论上GPU带宽更加宽，而且数据都在内存里面，几乎没有I/O。计算都是简单hash,
: scan, combine， join. 有500多个核的GPU至少应该有50倍的性能提高。
|
N*****m
发帖数: 42603 | 9 5,6GB太小了，现在laptop都8G起步了
【在 I******c 的大作中提到】
: 多大的数据才算data intensive? 现在gpu的global memory有5，6G了。
: 另外，数据从cpu主存到gpu global memory的传输是和gpu本身的计算是并行的。即使
: 你需要传几次数据，传输的时间也是可以被计算的时间tolerated的。
|
s*****n
发帖数: 5488 | 10 我也是从 mapreduce看过来的。具体的慢慢研究吧。
【在 I******c 的大作中提到】
: 最近两年ipdps上有几篇关于在gpu上实现mapreduce的文章。你可以看看。实用不实用
: 就不知道了。
|
s*****n
发帖数: 5488 | 11 数据还没搞，大概是10-15G,基本都是静态的，会有一个field 刷新。
然后来一个很小的数据开始做matching或者shortest path运算。
最后combine.
【在 I******c 的大作中提到】
: 多大的数据才算data intensive? 现在gpu的global memory有5，6G了。
: 另外，数据从cpu主存到gpu global memory的传输是和gpu本身的计算是并行的。即使
: 你需要传几次数据，传输的时间也是可以被计算的时间tolerated的。
|
g*****g
发帖数: 34805 | 12 这个算啥data intensive? 这个级别，内存里建索引，CPU计算足够了。
【在 s*****n 的大作中提到】
: 数据还没搞，大概是10-15G,基本都是静态的，会有一个field 刷新。
: 然后来一个很小的数据开始做matching或者shortest path运算。
: 最后combine.
|
m********5
发帖数: 17667 | 13 按经验, 大小0.1TB起算
data feeding速度超过100MB/s
一次性需要操作大于内存容量的数据, 比如想在一般的PC上对几十个GB的矩阵进行操作
.
如果传输时间远低于计算时间,那么我认为是典型 computing intensive, 用GPU问题不
大. 这个楼主完全可以用CPU测一下. 但看起来楼主说的计算复杂度似乎不高, 感觉GPU
提升有限, 浪费精力不划算. 即使是8GB-VRAM,只有10GB静态数据,如果不能一次性传入
VRAM, 又需要random access, 上下载是会很频繁的. 得不偿失. 如果楼主的数据可
以用random access性能较好的压缩算法来进行大比例压缩, 可以去偿试一下. GPU和
VRAM之间的带宽只有在数据
能全部upload到VRAM, 或者可顺序读写的时候才能体现优势. 另外楼主认为所有数据包
括中间数据储存在内存(用CPU计算)就没有I/O或者I/O的时间消耗就可忽略不计也是错
误的, 如果是这样我们就不用讨论FFT的算法优化, 当然楼主的case应该不是这种.
关于GPU有很多学术文章已经发过了, 一直很热, 版上的讨论不知道为何总是那么奇怪,
与其在这里瞎放炮, 不如多看几篇文献. GPU数据上下载是最大瓶颈, 这个是定论的.
【在 I******c 的大作中提到】
: 多大的数据才算data intensive? 现在gpu的global memory有5，6G了。
: 另外，数据从cpu主存到gpu global memory的传输是和gpu本身的计算是并行的。即使
: 你需要传几次数据，传输的时间也是可以被计算的时间tolerated的。
|
r******n
发帖数: 4522 | 14 我本来也想用GPU做些数据分析、优化，后来还是放弃了。数据倒进倒出的太浪费时间
。觉得只适合小数据，或者即使大量数据，但无关联可以分割。GPU板上的内存速度是
很快，但size实在太小。现在CPU也能搞很多core，我最后就是弄了两片xeon, 16core,
32thread跑。 |
