※ 引述《ledia (下班後才下棋)》之铭言： : ※ 引述《guest0079 (火辣辣的大姊姊)》之铭言： : : 1.效能也许会较差(这一点两位y兄争了很久)： : : 　说真的，我完全不能证明C++比C效能还差，甚至我可以证明，C效能永远不比C++好 : : 　证明如下： : : 　若set_Y为C中效能优於C++的子集合，已知C++为C的超集，set_Y必然也是C++的子集 : : 　set_Y at C > set_Y at C++，固set_Y为空集合 : : 　总之，C做得到的C++也做得到，C++的效能没理由较差 : C 和 C++ 谁比较好这个问题对我来说太沉重 : 毕竟我完全不懂 C++ : 不过你的证明.... 应该只是缓和气氛的吧 ? : 因为 C++ 就算是 C 的超集 : 他们的 compiler 不是同一个 : C 做得到的 C++ 也做得到也许是对的 : 但是你也得先证明一下 C++ 是用不坏於 C 的效率去做的呀 : 不然怎麽能说 C++ 的效能没理由较差呢 ? → xam:证明1就证错方向了..没抓到重点.. end 03/07 02:40 推 zerodevil:『一个人没料的时候... (下略)』 03/07 02:44 看完你的文章，我就知道为上面两位版友为什麽会有此反应了 以下针对效能这点再作说明(好啦，我知道场子已经冷了) 在我所发的文中，强调的是语言本身的特性，而不是编译器的好坏。效能、易读性、物件 导向、复杂度，四点内容所讲的全是"语言本身"。问题出在於："语言本身"所代表的效 能涵意是什麽？"程式码的效能"事实上是与平台密切相关的，但是语言本身又与平台无 关。所以语言本身与实际测到的效能是完完全全的两回事。比较C与Java两种语言，哪种写 出来的程式效能会比较好？答案是：视执行平台而定。(说这句一定有人想转joke了) 在一般的处理器上(x86, 8051, ARM, xxx单晶片)，绝对是用C写的程式的效能较高 只要系统的RAM够大，再把用C写的JVM porting到某平台上，就能跑JAVA程式，但是效能 一定很差。但是，如果SUM出了一颗新CPU，是一颗JVM硬体处理器，也就把本来是软体的 JVM用硬体来实作，则Java程式在该颗CPU上会拥有绝佳的效能，同时，这时候想在上面 跑C也不是不可能，只要写得出compiler就行了。此时，用C程式在这颗CPU上跑的程式八 成会远较Java程式慢 (N年前就听说SUM要出这种Java专用的CPU，不知出了没有，我想这 有一定的难度) 我举这个例子，就是想说明如果要比较程式码的效能，就一定要指定特定的编译器与执 行平台才有意义 但是我从头到尾所讲的就不是"程式码的效能"，而是"语言本身特性所造就出来的效能差 异"。C、C++语言当初在设计，从一开始就定位在source code层级与平台无关的语言， "语言本身"与平台无关，也与编译器无关，同样的code可以用不同compiler编译，也能 run在不同平台上。以上讲的都是浅而易见的道理，会上这个版的人都明白 但是为什麽大家扯到效能的时候都隐含地把编译器的因素考虑进去了？ 如果把编译器的因素考虑进去，就不必浪费时间讨论了。今天我用code size最佳化的 compiler去编C，跟你用效率最佳化的C++ compiler去比较C与C++的效能有意义吗？ 另外，又假设C/C++两者都用效能最佳化的原则编译，来比较效能，就如同某版友所说 的： 推 buganini:呃 要怪就全部怪在compiler头上就好了 所有的程式语言 03/07 13:36 → buganini:都是turing equivalent 极限最佳化结果应该都一样 03/07 13:37 → buganini:所以都是compiler不好 *flee* 03/07 13:37 也就是说，若真的做到最佳化，根本都一样快啊，这样比也是没意义 说到底，要比较C/C++效能，就我个人初浅的认知是"只能从语言的特性"去比较 假设某人设计出一种程式语言，他只定义一种资料型态 double 语言规定任何资料都以IEEE754的格式存於电脑中，所有资料都当成double来做运算 想必用这种程式语言来设计OS会有极大的困难，就算设计出一套程式，想必也是慢到不行 造成效能不张的原因最主要还是跟语言特性有很大的关系 另一个语言特性造成效能不张的例子就是Java。Java慢的原因大家都知道(JVM嘛)， Java慢不是编译器太差，而是当初就是以binary code层级跨平台为目标，再加上安全性 、gc等重重考量来设计这种语言，有VM的语言慢也是正常的 总结上面三段：我们说一个语言的效能好或坏，只看它编译後的程式执行起来的速度是 不够的。真正比较全面的评断方法是：看语言特性(是不是能让人编译出有效率的程式、 是不是能设计出够好的编译器…，量测程式执行速度只是其中一个环结) 再回到C/C++的讨论，我提的证明与针对C++的效能评论就是针对"语言特性"而来 :　a. C++太多太杂太难掌握，让程式人员浪费太多时间在语言本身而非问题的最佳解上 : b. C++会偷偷增加一些程式码来维持本身的OO特性，一不小心就多出了不必要的code : c. C++会偷偷增加一些程式码来维持运算子过载特性，一不小心就多出了不必要的 code :　d. 用C++物件导向实作的函式库，很方便使用没错，但代价就是负担太大(如Qt) 请不要再提什麽compiler了，用gcc/g++编译，效能根本没太大差异 对於xam版友所说的： → xam:证明1就证错方向了..没抓到重点.. end 请问你说的重点是不是在於compiler？是不是在於library的实作？ 如果是的话，你说的重点就我看来根本不是重点 什麽是语言，什麽是程式，先搞清楚，再来讨论C/C++的效能才有意义 如果有人觉得我的论点是错的，也请提出来讨论 算了啦，散场了啦 --

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