|
锁定老帖子 主题：多线程是个不靠谱的东西
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-08
引用 执行的过程中,父节点需要依赖子节点的执行.
如果是 Bottom Up, 父节点就执行子节点进行求值. 如果是 Top Down, 父节点就是展开(Unwind)子节点. 不是很明白你的意思. 引用 我想知道的是,
在Top Down的过程中, 父节点展开(Unwind)子节点的时候, 如果遇到一个 Lazy Node, 那么就不会展开,而是直接进行求值.就是说Lazy Node的执行就是要遵守Bottom Up的方式了. 是这样吗? 一种语言的求值方式要么是strict的要么是non-strict的。不存在一会用top-down，一会用bottom up. 遇到non-strict node是否要unwind，关键是看你采用树规约还是图规约。图规约可以共享sub-expression提高效率,不存在规约方向的区别.也就是说图也是分top-down,和bottom up的.另外图规约可以对non-strict 节点做展开，但是不求值，这种方式叫做graph rewrite.这个时候只展开不求值. |
| 返回顶楼 | |
|
发表时间：2008-05-20
如果是.net 环境，推荐你研究一下Robotic Studio里面附带的CCR
|
| 返回顶楼 | |
|
发表时间：2008-06-10
ray_linn 写道 WALL.E 写道 说这话没有理由。顺序代码凭什么应该顺利地迁移到并行代码？除非编写的时候就为并行优化，顺序代码一般都严重依赖上下文关系。打破这个关系自然跟重写没什么区别。
传闻IBM花了大量时间研制并行编译器。如果顺序代码都可以顺利地转化成并行代码，那这个东西早就搞出来了。而且PS3也不会弄得现在这样子。 就是因为我们编程能力已经落后于硬件的进步了.大部分时候，我们都是用顺序的方式去思考逻辑. 我的想法并不是要完全打破顺序结构,而是在顺序结构适当中引入并行结构. 比如从文件中读数据--->对每个数据进行傅立叶变换--->把结果保存到文件中. 就可以用顺序--->并行--->顺序的方式来执行. 我想从现在到未来,CPU的数目只会更多, 昨天送来的样机有2个4核CPU 加 两张 2个双核 GPU, 12个core让你使用,并行只会更重要..... 傻傻地问：操作系统对多核的支持不需要考虑么？已经能够将一个进程的多个线程分配到所有的CPU上面？还是仅仅提高了多进程的并行速度？ 记得好多年前就在己经有并行计算这个概念了，我还看过矩阵并行计算的算法，以后基本没接触了。 |
| 返回顶楼 | |
|
发表时间：2008-06-12
个人觉得多线程并不是为了程序处理速度的快，而是为了给用户一种感觉上的快，就像web上广泛使用的ajax一样，它并没有降低服务器的负担（反而加重了），但是它给了用户一种快的感觉。
|
| 返回顶楼 | |
|
发表时间：2008-06-19
lz需要一个支持数据流的管道
|
| 返回顶楼 | |
|
发表时间：2008-08-20
IO操作你是的问题的根源
---------------------- 这个世界上不是所有的东西都适合直接“多线程”操作的 典型的是IO和UI 我们可以用在某些必须的情况下（自己通过实践来确定阀值），间接的“伪多线程” |
| 返回顶楼 | |
|
发表时间：2008-08-24
aninfeel 写道 个人觉得多线程并不是为了程序处理速度的快，而是为了给用户一种感觉上的快，就像web上广泛使用的ajax一样，它并没有降低服务器的负担（反而加重了），但是它给了用户一种快的感觉。
你的多线程不过你想象中的而已,你并没有想过CPU以2*n增加的情况. |
| 返回顶楼 | |
|
发表时间：2008-11-01
楼主坐在机器面前说， 我要一个鸡蛋， 机器就吐出来一个。 我要同时给我2个鸡蛋， 机器就吐出来2个。
|
| 返回顶楼 | |
|
发表时间：2008-11-06
讨论的好热烈啊，不过越来越看不懂了。。。
现在多线程大多用于处理多路IO，IO的速度比CPU慢几个数量级，CPU大部分时间是在等待IO响应。 我理解就好比肯德基点餐，“您想点什么餐？”“我想想。。。”顾客一想就是一分钟。。。那还不如在这一分钟内让这个顾客让出位置，让另一个服务员给另一个顾客点餐。让出位置的时间就是上下文切换的开销，如果是5秒钟，那也比干等一分钟强。 |
| 返回顶楼 | |
|
发表时间：2008-11-06
问题很好，就是答的不靠谱，呵呵.
不管它多么不靠谱，我们的任务就是使他尽量靠谱，要不还要我们做什么呢... 即使cpu*n了，总线能×几？Io能*几？cache能*几？？ 还不是总要拿有限的资源去满足无限的索取... 与其考虑固定的阈值，不如考虑在运行中调整!! |
| 返回顶楼 | |
