冒昧请教几个问题。 ※ 引述《ggg12345 (ggg)》之铭言： > > 一般使用高阶语言程式与高阶API者应该不会处理的这麽细. 这已 > 经是类似粗放与细耕的代价/获益问题. 那麽，从软体人的角度来看， CPU内部，如何实现硬体的多执行绪，似乎是太过细节的问题， 如此一来，粗放与细耕应该如何取舍呢？ (通通交给作业系统与编译器吗？) > 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； 是这样吗？ 各个平台与开发工具，对於Thread的支援程度/支援方式，似乎不尽相同， 您谈到了CPU内部的暂存器(资料的存取)， 能不能也请您谈谈Pipeline与Functional Unit的部份呢(机器指令的发派)。 --

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