※ 引述《JohnLinq (林约翰)》之铭言： : 冒昧请教几个问题。 : > 一般使用高阶语言程式与高阶API者应该不会处理的这麽细. 这已 : > 经是类似粗放与细耕的代价/获益问题. : 那麽，从软体人的角度来看， : CPU内部，如何实现硬体的多执行绪，似乎是太过细节的问题， : 如此一来，粗放与细耕应该如何取舍呢？ : (通通交给作业系统与编译器吗？) 1.在单核的时代是强调 cpu 的硬体提供多组 register set, multi-thread 可以使用 shared memory. 在切换时可以降低 context switch overhead. 2.在共用 bus 与 common memory 的多处理机的时代, multi-thread 进一步 可强调 parallel thread , 但其同步与排程是在 user space 的 thread library 提供, 因此是减少透过 system call 由 kernel 做同步与排程 的 overhead. 3.在多核心的时代, 目前是以提供多个 program counter, 多组 register set 为开端. 多级的 pipleline functional unit (如阵列浮点运算)跟 简单的逻辑累算单元可以就其性质, 选择让两个不同性质的程式片段透 过多个 program counter 指向不同的 cache 区段, 同时让两个不同的 片段程式(thread 或 process)同时使用不同性质的 functional unit , 如果同时使用到同一组 functional unit 就由 cpu 内部的硬体对不同 片段指令实行延迟礼让的细部动作. 对这种 functinal unit 的专用( 不做延迟礼让的交错使用)当然也可透过事先的声告来取得, 这时候就依 靠 SMT thread library 提供界面给程式软体. 程式的使用不外是 user 自理, 不然就是由 程式语言提供 指述 或范例的叫用法, 经由 compiler 半自动协助. ====== 粗放只有一种顾虑就是不要在原则与特性上弄错. 就像 2-dimension array 在连续取得每个 element 来计算时就必需与 语言的 compiler 安排阵列的方 式相配合, 如 column majoring(FORTRAN) 的大array(如 1024 X 1024) 照 row 的次序先变化 row 去存取, 如果 real memory 不够大, 就可能造成一堆 的 page fault 使得 page memory 对整个 page 大搬家. 比照於 register set 的 context switch 或 functional pipleline 或 instruction prefetch pipleline 的打断与重灌, 也就是同样的道理. : > Multi-thread program 通常写成同一份的 program 给 compiler 编译, 同 : > 时指明要使用 thread 特性, 此时 compiler 就可细查会相互干扰的 register : > 有那些, 在切换时就可只针对会干扰到的 register 做最有效的暂存与还原. : 使用类似POSIX Threads这样的东西，软体人是不是就需要考虑较多的硬体细节？ : 而当使用OpenMP、Intel Threading Building Blocks这样的东西的时候， : 就可以把硬体细节丢给Compiler与Library API； : 是这样吗？ compiler 当然是企图朝预测与自动协助方面着手, 但 user 若要故意写一个 跟其运作原则相反的动作次序, 她也只有被跟着愚弄的下场. 所以, 完全不想知道, 不理她的硬体与编译原理, 那就是靠运气在写程式罗 ! 所谓专业或本科就是多那麽一点点的概念或养成习惯, 靠习惯减少错误. : 各个平台与开发工具，对於Thread的支援程度/支援方式，似乎不尽相同， : 您谈到了CPU内部的暂存器(资料的存取)， : 能不能也请您谈谈Pipeline与Functional Unit的部份呢(机器指令的发派)。 细节势必得针对不同 processor 的架构与指令设计 k 手册. 若是要专门配属 某个核心或 functional unit 给特定 thread/process 某段时间使用, 那又 得 k 配合 OS 提供的 thread library , 甚至是 cpu 制造商配合提供的语言 package/compiler&library. 但, 原理原则却是不太会变的. --

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