多说无益，看来版主水平有限！
:lol
嗯嗯。
感谢您莅临CUDAZone China.
祝您生活，工作愉快！
不过只是对这个问题认识水平有限。
不代表别的。其实很多其它问题还是了解很多的！
希望您能够认真思考。
当然我依然希望从您那里学到您懂得的其它东西！
感谢您对我的“我对这个问题认识有限”的评论。
您的评论是我进步（or退步?)的动力。
祝您愉快！
我想只要您认真思考了，不大可能不懂。
我所说应该很容易理解。自认为都是很浅显的道理
当然，如果我理解错了，您也应该能够一语中的的指出才对。
但我没看明白您说的到底何物？
好的。
以下内容引用自40#楼。
横扫千军写道：
您依然强调您的“搞好延迟就搞好了社_会_主_义建设”的论点。
但是我已经反对过多次了，请看上面众楼，例如女神楼和20楼的说法，只要能运行到某组件的极限，何必又搞些其他的不能解决瓶颈的东东呢！
是吧。
您如果已经达到了访存的极限吞吐量了，您用10000…000(省略一堆0)条指令的提前量来读，依然无法改善贵kernel的性能。
祝您愉快！
8-32指令，带宽满足了，但是32个WARP都执行了这8-32条指令后，就都歇菜了。
等到延迟后，再重新干活；然后又是歇菜，再等延迟，在干活，再歇菜，如此反复。
看来在您的脑子里面根本就没有延迟的概念！只有带宽吞吐率的概念！
所以您才如此说。
请您直接回复我的40楼，或者楼上。不要转移话题。
的确是“歇菜”，但如同上面说的水桶论，您最短的木板已经到顶了（我指达到了瓶颈，也就是您说的“8-32指令，带宽满足了"之类的）。您再无辜的加长其他的本来够用的那些木板，何必了？
我反复直接对您表达我的观点多次。也直接对您“还能改善性能论"反驳多次。可是您一直顾左右而言他。
建议您认真阅读。
谢谢。
到此打住吧，既然您根本就没有延迟的概念，还是先建立起延迟的概念来再讨论不迟。
感谢您的来访。
祝您工作，生活愉快！
这个显然是错误的。
我的代码假设每访存一个字节20条指令这个密度间隔，而带宽的需求是只需8指令间隔即可。何谈已达极限访存吞吐量？
而真正等待的是延迟，此时即便将硬件带宽提高1000倍，等待的还是延迟。
难道您真的认为“8>200”？
此时内核函数的90%的时间将处于等待延迟的消耗之中。