system888net 发表于 2009-03-13 20:38

CPU自己的并行调度是非常有限度的.
从另一个角度来看,比如异构系统中,通过编译器处理过的配合OS的并行调度可移植性会好过过分依赖CPU的"硬件并行"

system888net 发表于 2009-03-13 20:40

回复 #21 system888net 的帖子

当然不排除未来发展的一些变化,技术这东西就是有个特点: "不能下结论某个东西一定不行!"

prolj 发表于 2009-03-13 20:43

回复 #21 system888net 的帖子

更理想的情况是，粗粒度（任务级）并行交给 OS ， 细粒度（ILP）还是编译器干， CPU 就在哪儿听话的跑指令。
其实，硬件不支持不重要，关键是你的接口设计要清晰，硬件不支持的功能可以用软件模拟（不同的人有不同的方案），那个该死的 libgcc 就模拟 N 多功能，比如浮点操作。

system888net 发表于 2009-03-13 20:45

原帖由 prolj 于 2009-3-13 20:43 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
更理想的情况是，粗粒度（任务级）并行交给 OS ， 细粒度（ILP）还是编译器干， CPU 就在哪儿听话的跑指令。
其实，硬件不支持不重要，关键是你的接口设计要清晰，硬件不支持的功能可以用软件模拟（不同的人有 ...

有道理.

system888net 发表于 2009-03-13 20:47

原帖由 prolj 于 2009-3-13 20:07 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
我的想法之一就是解决这个问题，当然，没做出来之前咱不吹牛。
...

有想法是好事情,正所谓 "心都不想,何以成事".
关注中!

Cyberman.Wu 发表于 2009-03-13 20:54

志存高远啊，呵呵。不知道你想如何解决？Intel好像对IA64提供了一个二进制文件的“编译器”，对原来的二进制指令重新调整以在IA64上运行。
从CPU本身的角度来说，有些在VLIW的基础上扩展了一些想法，可以参考一下这篇Wiki：
http://en.wikipedia.org/wiki/Explicitly_Parallel_Instruction_Computing

system888net 发表于 2009-03-13 20:57

原帖由 Cyberman.Wu 于 2009-3-13 20:54 发表 http://linux.chinaunix.net/bbs/images/common/back.gif
Intel好像对IA64提供了一个二进制文件的“编译器”，对原来的二进制指令重新调整以在IA64上运行。
从CPU本身的角度来说，有些在VLIW的基础上扩展了一些想法，可以参考一 ...

有见解.

prolj 发表于 2009-03-13 20:57

想得多没用，一千行文字抵不过一张照片。
其实很多还不懂，看见水木那几个人心里就火大，啥时候跟人家那样啊，无论是理论还是实践，都有差距。
说白了吧，模拟硬件功能我推崇 JIT ， Apple 的 OpenGL 已经做了，看着别人一个个实现新功能，不如自己把脚下的路走平。

system888net 发表于 2009-03-13 20:59

并行的道理很简单,但把他落到实处,或者说把并行发挥到什么程度,考虑的问题和方面就比较多了.

system888net 发表于 2009-03-13 21:07

回复 #29 system888net 的帖子

如:
常规的:
class A {
   private:
      int count;
   public:
      A();
      ~A();
      int get_count();
      ........................
};

A *p=new A;   //由同一个程序执行段(或同一时刻只能有一个CPU)来执行这100个A()


并行的:
//代码没有变,但可以变成并行了,这是编译器的相对优势.
class A {
   private:
      int count;
   public:
      A();
      ~A();
      int get_count();
      ........................
};

A *p=new A;   //可有多个CPU同时来执行这100个A()
页: 1 2 [3] 4 5 6 7 8 9
查看完整版本: Tilera公司的64核MIPS——Tile64