※ 引述《JohnLinq (林约翰)》之铭言： : 冒昧请教几个问题。 : ※ 引述《ggg12345 (ggg)》之铭言： : > 一般使用高阶语言程式与高阶API者应该不会处理的这麽细. 这已 : > 经是类似粗放与细耕的代价/获益问题. : 那麽，从软体人的角度来看， : CPU内部，如何实现硬体的多执行绪，似乎是太过细节的问题， : 如此一来，粗放与细耕应该如何取舍呢？ : (通通交给作业系统与编译器吗？) 交给 OS 会消耗 runtime 资源， 交给 compiler 会有难以预测 runtime 行为的问题而太保守， 纯手工来 tune 通常是最好的， 至於要 tune 哪里可以看 profiling 结果来决定， 一开始你可以都交给 OS or compiler。 : > Multi-thread 要发挥效用, 程式设计者就要考虑到相当细节的部份, 同 : > 步与切换的排程问题都得亲自处理, 才能发挥出并行处理又无太多 overhead : > 的效用. : > 由 compiler 与 library API 支援的 multi-thread 在启动与切换 thread : > 时就是让不同 thread 使用不同的 register set. 在共用 process memory : > space 与工作环境的假设下, user program 的 threads 间不会自寻烦恼的相互 : > 干扰, 因此就不必类似 multi-process 般的做此制式 save/restore 动作. 而 : > 使用不同组的 register set, 当然更是不必全做存回 memory 的 save/restore : > 动作, 此类 overhead 就省了. : > Multi-thread program 通常写成同一份的 program 给 compiler 编译, 同 : > 时指明要使用 thread 特性, 此时 compiler 就可细查会相互干扰的 register : > 有那些, 在切换时就可只针对会干扰到的 register 做最有效的暂存与还原. : 使用类似POSIX Threads这样的东西，软体人是不是就需要考虑较多的硬体细节？ : 而当使用OpenMP、Intel Threading Building Blocks这样的东西的时候， : 就可以把硬体细节丢给Compiler与Library API； : 是这样吗？ 没听说过用 pthread 就要考虑到硬体， 顶多去了解它是什麽 thread model， 是不是在 kernel space， 还有是 compiler 还是 library 支援而已， 这些都是完全在软体角度思考， 除非你想去搞清楚每个 cycle 的时间到底被花在哪里。 稍稍深入分析 multi-thread 程式的效能时， 难免就多少会跟 computer architecture 有点关系， 但是它并非硬体「细节」， 只是一个抽象概念而已， 你就算用了 OpenMP 还是其它什麽的要深究的话还是会接触到， 比方说你要去看 compiler 到底怎样处理那些 directives， 然後钻进 library or OS 里面追查 thread 到底是被怎样处理的， 最後还是得去了解你执行环境的电脑是什麽样的架构， 然後去追 cache、speculation、prediction 等等有的没的参数， 这些在你真的想去抓最根本的原因时都不可能避免； 就算你是写 Java 用的是 Java Thread， 你想追根究底的时候也不可能永远在抽象的 VM 层级上看， 毕竟真正影响程式执行效率的还是 architecture 本身。 所谓硬体细节一般是指 organization 的部分， 不需要跳到这麽底层来写程式已经很好了， 这不是文字游戏， architecture 本身就是被定位在偏写程式相关的那边， 在你需要斤斤计较的时候无视 architecture 特性是不可能的， 不会因为是以哪种形式支援 thread 而有所差异。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://www.tinlans.org --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.160.114.73