希望能够和贵站交换链接？

JUST

说实话，没啥性能上的好处。非要说那就是成本比较低，显卡verify比FPGA还是容易一点。很大程度上是为了研究GPGPU，cache simulation只是一个验证工具。

CTM把显卡指令集编码都公开了，所以能窥探到不少微架构的信息。

我们都是用trace文件来simulate，不用实时采集的数据，而且只是计算miss之类的统计。所以其实性能真的无所谓。

而且如果我深度优化一下cpu-based程序，两个核就能比gpu的快:)

20080030成电

MASA         OpenCV中文论坛 分布式计算论坛

-----------------------------
在他们的友情链接里，我看到的是这样，会不会太靠近了？前面的也是汉字，看起来很挤。
我有个建议，把“分布式计算论坛”换成“EQUN分布式计算”如何？“论坛”2字可有可无。

OpenGPU

好，我调整一下。但是我不会调整宽度，就跳顺序吧~

OpenGPU

原帖由 JUST 于 2009-11-19 12:38 发表
说实话，没啥性能上的好处。非要说那就是成本比较低，显卡verify比FPGA还是容易一点。很大程度上是为了研究GPGPU，cache simulation只是一个验证工具。

CTM把显卡指令集编码都公开了，所以能窥探到不少微架构的信息。

我们 ...

是read-only cache还是可读写cache ?

JUST

模拟的是Data Cache，可读写的。这个其实影响不大，换成I-cache更简单

不过CTM中每个shader只能输出4个Frame Buffer，每个buffer含4个float
所以subblock，write combination之类的就都没法实现了

OpenGPU

原帖由 JUST 于 2009-11-20 12:25 发表
模拟的是Data Cache，可读写的。这个其实影响不大，换成I-cache更简单

不过CTM中每个shader只能输出4个Frame Buffer，每个buffer含4个float
所以subblock，write combination之类的就都没法实现了 ...

最后一句没看懂，cache line里面如何实现subblock??干吗用的?

WC机制不是BUS和Mem Ctrl机制么?增强Burst的，和Cache有什么关系？

特此请教大牛：〉

JUST

subblock一般用于精细划分dirty bit
一般一个line就一个dirty bit，这样哪怕改变一个byte，flush的时候就要整个line都写回内存
subblock有好多dirty bit，flush的时候只要写dirty的部分

WC确实跟cache设计没啥关系。但是如果有WC机制，有一些内存请求就不会立刻提交到cache。这样cache的请求顺序，次数就会不同，统计上会有一些变化
其实主要是因为有的trace文件是根据instruction来生成的，如果在cpu和cache之间收集trace就没这回事儿了。这里处理WC相当于对trace作预处理，跟simulate关系不大

好久没看architecture的东西了，要是有说错的地方，还望指正

OpenGPU

原帖由 JUST 于 2009-11-22 17:09 发表
subblock一般用于精细划分dirty bit
一般一个line就一个dirty bit，这样哪怕改变一个byte，flush的时候就要整个line都写回内存
subblock有好多dirty bit，flush的时候只要写dirty的部分

WC确实跟cache设计没啥关系。但是 ...

恩，大牛水平了得：〉学习了。

大牛的simulator不针对MC（mem Ctrl）和BUS建模吧？

关于subblock我考虑了一下，对于一般的AXI/OCP等Split-transaction Bus来说，如果Subblock的尺寸过小，会导致写回操作由原本的一个Memory Request变成2到3个，可能会影响BUS和MC的效率?（比如不能驱动burst传输模式）

不过好处就是如果使用更加NB的AMD HT总线或是PCIE总线，那可以先把不连续地址的请求压缩到一个包里面，然后通过总线把这个包传送到MC，然后再解压缩并Merge 读写操作。不知道大牛对这个分析了没有？

[ 本帖最后由 OpenGPU 于 2009-11-23 07:48 编辑 ]

Rojer

好专业，俺是看不懂
支持能提高处理性能的活动

JUST

我的simulator只是对Dcache建模的。不过其实存储系统不是很容易分开来来考虑的。每一层的设计都影响别的层

对于总线我没啥研究。我只知道有一些设计是如果有>=2个subblock是dirty就写整个的
我觉得要综合考虑block大小，总线能力。如果block特别大，本来也没法封在一个request，那多几个request也就没overhead了

OpenGPU

嗯，一般设计的时候会考虑，假如一个cache Line就是64B，那么这就是一个Burst的大小 ：〉对于多核心处理器，还要考虑Coherency影响，等等。Coherency意味着cache之间的M.O.E.S.I等协议的通信，如何利用CUDA加速呢？CUDA不提供Block之间的通信阿。

顺便问一下，加速比最高是什么情况下的，CUDA加速对于full-associative Cache应该是最划算的吧？





今天正好一个哥们打算在CUDA上实现一个simplescalar-like Simulator，大牛可以去批评批评。

《关于利用CUDA来加速simplescalar(Wattch)-like Simulator》

http://www.opengpu.org/bbs/redir ... o=lastpost#lastpost

[ 本帖最后由 OpenGPU 于 2009-11-24 06:09 编辑 ]

JUST

我做得很简单，就是1个CPU的单级cache，所以当时这些就被忽略了
如果只是近似统计cache性能，有一些并行算法，能消除数据相关
我还是精确模拟的。送到GPU之前先对set no做了排序。所以direct-mapped应当最好，不过如果每个set中request数量差很多就会慢
对CUDA不熟，前几天听过一个tutorial，好像有一些atomic运算，是否能跨block作同步呢
总的来说，GPU不太适合作精确的cache simulation。因为cache simulation本身就是串行的，除非用近似算法来分隔。而且本身simulation也没有很多计算量，发挥不了GPU的能力。GPU主要的优势就是相关度高了以后对tag作查找会比CPU方便，用predictor。不过CPU也能emulate出predictor，也能消除查找时候的分支。


这两天忙着考试，我过几天再拜读

[ 本帖最后由 JUST 于 2009-11-24 12:15 编辑 ]

OpenGPU

可以把功耗模拟加上去？这样计算量就上去了，哈哈~~

另外，full-associative也是增加计算量的好方法，比如Branch predicator/TLB用到FA$都相对比较吃带宽和性能。

JUST

full-associative就没法并行处理request了。每个request能够向量处理，但CPU一样可以，而且一次能比较的更多

GPU做timestep的模拟那是最合适了

OpenGPU

大牛能解释一下为什么“GPU做timestep的模拟那是最合适了” ？？？



另外，还要请教一下，如果依靠并行处理request来加速的话，那如何避免替换机制引起的cache miss改变后续request的命中结果呢？？？以及Request之间的RAW dependency由谁来检测？


不好意思，才疏学浅，问了很多问题~~