大数运算用低阶语言实做会比高阶语言快? 这是直觉, 但不一定正确的想法 举例来说, 若把一个大数加在另一个大数身上 组语写出的的结果, 假设是100个 x86 指令 但一个支援大数运算高阶语言 compile 出来的结果, 只是 add A, B 1个 VM 指令而己 不过若是要在 x86 中执行它, 却可能需要 110个 x86 指令... 110 > 100 所以组语快 10%, 是这样吗? 若是该 VM 发现该电脑上有特别的硬体, (如Java Chip) 或是发现 现在所执行的CPU的有支援某些 SSE 指令 或是连发现有装 显示卡 ,把显卡也拿来运算 或是异想天开地, 丢给最近很红的 ....天边一朵云 去计算 或是我所没写出来的, 更多种种的可能 原本让人觉得是 "overhead" 的 VM 却让100个指令的组语, 变成反而可能是 "最慢" 的了 当然, 听到这里, 可能有人就会想, 再用组语追逐上面提的种种可能... 甚至底下提到的GC, 自己也可以去实做出取代它的功能 但那就只是自己去实做出了一部份的高阶语言, 或VM , 或Java罢了 个人浅见 ----- 另外几百个人一起写code现实中是有的 不过如果其中每一个人的code, 都会跟另外几百人有关联 或是一个错误发生, 几百人都要一起找bug ...那这种案子算是很特别 ※ 引述《Aurim (Who cares?)》之铭言： : 不同时期的人有不同看法吧。 : 当你的工作是OS/driver或比较大型的软体系统时，看到底下的#1，我想问： : 哪时候才会没有问题发生呢？ : 小公司一个专案的bug编号了不起三位数、四位数，我会说你说得还好。 : 大公司一个长期维护的产品bug编号会是六、七位数以上，每天几百个人一起改code， : 几乎每天都有固定数量以上的bug被提报，没问题发生就是要发生大事了。 : 如果你的工作大半都是在别人几天前、几星期前、几个月前写的code上抓bug， : 某个程度上，你一定要知道别人、编译器、作业系统、硬体到底干了哪些事情的啊， : 只是搞得多清楚的差别。 : ※ 引述《lgd1008 (lgd1008)》之铭言： : : 另外不必事事知道底层的例子, 可以参考自己与身旁同事的 program integration : : 你何时需要知道同事的实作细节? 太概就只有 : : 1.问题发生的时侯, 2.交接的时侯, 3.想找东西学习的时侯... : 你底下说的不一定，我都干过了，所以我不认为弄半天也没办法弄出那样的效能； : 当然这感受是因人而异的。我会说那并不是什麽大不了的事情。 : 举个简单的例子，我高中时曾经用几个不同语言写阶乘计算的小东西来磨练自己， : 目标是能够算出电脑记忆体能够允许的最多位数的阶乘。 : 这是个小题目，可是可以让一个人在已经做好的东西不断再去加强效能， : 思考怎样可以让它跑得更快，比较各种手法的不同效率。 : 因为高阶语言的overhead，大数计算用组语作在执行效能上仍然会是最快的。 : 即使是今日，几乎天天在看微软的编译器生出来的机械码，我的意见不会改变。 : 凡事都有边际效益的差别，同样做个对照，低阶语言 vs. 高阶语言，C vs. Java： : Java JIT再怎麽强，跟C/C++生的原生code就是有效能差异。 : 就算单纯是一个固定比例的差异，10%来讲，当CPU时脉愈来愈高， : pipeline内能够同时执行的指令愈多，差那10%，可能代表的就是0.1 GFLOPS的差别。 : 实际上是差更多，我看过的一些案子就是，实际上处理的资料量明明就没那麽大， : 可是因为garbage collection没办法那麽有效消化垃圾，应该是几台高档PC当server : 跑起来应该要OK的东西，搞到要用很贵的机器来让客户觉得效能能够令人接受。 : （几亿元的机器来跑，效能仍然令人不满意，只是可以接受而已） : 关键在於你牺牲那些效能，能提高多少生产力，节省多少开发时间， : 会不会有别的问题伴随而来？上面就提到了garbage collection的问题。 : 不同工具，适合的工作也不同。 : 我只是组语摸了20年，几个高阶语言跟VM的runtime library内部实作看透透， : 在几个不同领域待过，一点浅见而已。 --

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