|
锁定老帖子 主题：多线程是个不靠谱的东西
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-06
ray_linn 写道 seen 写道 从开发应用程序的角度来看 是否需要多线程跟应用环境有关 跟核心的多少无关
多线程的瓶颈在于切换上下文和锁 >>首先我排除了大部分的文件读写操作，顺序读取会导致文件指针的移动 >>特别是要把数据填充到一系列结构（Struct)中去的时候，多线程产生了一堆错误的结果 如果这种错误你都要犯，我只能说两点： 1 你不知道怎么合理使用锁 2 你不知道文件系统是怎么运作的 有空看看filesystem的科普文章吧，或者看看linux是怎么维护filenode的 而且，你这帖子属于文不对题，内容分明是在说：我不会用多线程 你不过是在犯傻而已. 线程是什么,CPU的时间片而已. 对于单核或者单CPU来说,线程是什么? CPU时间的轮换而已,CPU时间片的轮换必然带来开销,所以对于单核来说同样Print out一个List里的data, 多线程的速度会远比单线程慢,而多核系统,好处是两个线程可以被安排到两个核心上,才有可能加速处理玩List里的Data,(如果不是Print out这样简单的东西,而是FF变换). 第二,你压根国文就不及格.我说的是读取一系列Struct结构,文件的构成是包含的是: (Struct A)(Struct B)(Struct B)(Struct C)..... 无法使用多线程是因为Struct B的文件读取位置，受到Struct A Size的限制. 你这样傻,我为什么还要和你解释呢? 在单核机器里使用多线程的不是为了加速运算，只是充分利用CPU的计算性能而已。 计算机大多数是在跟慢速设备（例如人）打交道，如果没有多线程CPU的性能就白白浪费了， 你说的调度开销只有在CPU满载的情况下才应该考虑。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
Trustno1 写道 引用 话说回来，并发的难度比指针的难度要高多了。但世界上用c写的并发的应用并不都是失败的。
这要注意上下文的语境了. 成功!=开发低成本. 换个话题 erlang是一个天生的支持并发的环境 但是erlang并没有跑在特别的OS上 对于OS来说 进程的调度是不可或缺的一环 形形色色的锁在内核里也是星罗棋布 一个OS抽象来看就是一个for(;;)循环 中间被不停的打断 总的来看是一个顺序执行的程序 那么erlang的vm肯定就承担了把并发映射到顺序执行的责任 那么这个vm是怎么做到这点的呢？ |
| 返回顶楼 | |
|
发表时间：2008-05-06
hyf 写道 在单核机器里使用多线程的不是为了加速运算，只是充分利用CPU的计算性能而已。 计算机大多数是在跟慢速设备（例如人）打交道，如果没有多线程CPU的性能就白白浪费了， 你说的调度开销只有在CPU满载的情况下才应该考虑。 对于一个占CPU长的操作来说呢? 情况就不一样. 如果计算可以被分配到我说的那台机器的12个核心上,那才是真正充分利用CPU. |
| 返回顶楼 | |
|
发表时间：2008-05-06
seen 写道 Trustno1 写道 引用 话说回来，并发的难度比指针的难度要高多了。但世界上用c写的并发的应用并不都是失败的。
这要注意上下文的语境了. 成功!=开发低成本. 换个话题 erlang是一个天生的支持并发的环境 但是erlang并没有跑在特别的OS上 对于OS来说 进程的调度是不可或缺的一环 形形色色的锁在内核里也是星罗棋布 一个OS抽象来看就是一个for(;;)循环 中间被不停的打断 总的来看是一个顺序执行的程序 那么erlang的vm肯定就承担了把并发映射到顺序执行的责任 那么这个vm是怎么做到这点的呢？ 说起来windows也是一个天生支持并发的环境。 但如果最终windows只是运行在一个单核的机器上，结果还是串行。 我觉得windows给予应用程序的多线程的虚拟的并发环境理论上已经很足够，只是编程模型复杂，erlang把并发变得随手可得。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
>>说起来windows也是一个天生支持并发的环境。
说说看，为什么？我完全不懂win的实现 |
| 返回顶楼 | |
|
发表时间：2008-05-06
seen 写道 Trustno1 写道 引用 话说回来，并发的难度比指针的难度要高多了。但世界上用c写的并发的应用并不都是失败的。
这要注意上下文的语境了. 成功!=开发低成本. 换个话题 erlang是一个天生的支持并发的环境 但是erlang并没有跑在特别的OS上 对于OS来说 进程的调度是不可或缺的一环 形形色色的锁在内核里也是星罗棋布 一个OS抽象来看就是一个for(;;)循环 中间被不停的打断 总的来看是一个顺序执行的程序 那么erlang的vm肯定就承担了把并发映射到顺序执行的责任 那么这个vm是怎么做到这点的呢？ Erlang从我的观点看，并不适合指令级并行，它擅长的领域是任务级的并行。这是两个不同并行粒度。Lz讲的问题基本是指令并行的问题，Erlang的结构在这个上面没有优势，仅仅要比传统语言稍微好那么一点点，但是迁移仍然不是那么平滑的。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
指令并行?听起来是流水线设计的问题了？
突然想起来，cpu属于天然支持并发的模型，但是这么强大的功能居然被OS和语言们屏蔽的死死的 |
| 返回顶楼 | |
|
发表时间：2008-05-06
seen 写道 >>说起来windows也是一个天生支持并发的环境。
说说看，为什么？我完全不懂win的实现 我把windows当作一个Native VM来说。 另外， 把一系列的工作当作一个图做拓扑排序， 其中可以交换次序的节点是可并行的，但整体也存在一定的顺序性。 无论是erlang还是c++，都是在实现某些工作的并行，整体的顺序性。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
hyf 写道 seen 写道 Trustno1 写道 引用 话说回来，并发的难度比指针的难度要高多了。但世界上用c写的并发的应用并不都是失败的。
这要注意上下文的语境了. 成功!=开发低成本. 换个话题 erlang是一个天生的支持并发的环境 但是erlang并没有跑在特别的OS上 对于OS来说 进程的调度是不可或缺的一环 形形色色的锁在内核里也是星罗棋布 一个OS抽象来看就是一个for(;;)循环 中间被不停的打断 总的来看是一个顺序执行的程序 那么erlang的vm肯定就承担了把并发映射到顺序执行的责任 那么这个vm是怎么做到这点的呢？ 说起来windows也是一个天生支持并发的环境。 但如果最终windows只是运行在一个单核的机器上，结果还是串行。 我觉得windows给予应用程序的多线程的虚拟的并发环境理论上已经很足够，只是编程模型复杂，erlang把并发变得随手可得。 hoho, Erlang在Os level Thread上安排了两个Schedule,用它们来Call 所谓的VM_Level的Thread. 我上面的程序就可以看成一个 Erlang. Erlang和上面Parallel.for是一样的,根据CPU核心安排OS level的线程的.ThreadProcess就是Erlang的Scheduler, delegate action--你可以把它近似看成erlang process或者vm level thread,因为调用delegate action不需要切换线程context,所以Erlang会高效. 一个 delegate action就是一个Task而已,所以Erlang是任务并发. |
| 返回顶楼 | |
|
发表时间：2008-05-06
引用 我们不缺工具，但缺best practise
面对并行，我们现在缺的就是工具 |
| 返回顶楼 | |
