[cpp]请不要再把话题扯回去

[Wu Yongwei]

云风 wrote:

> 在 06-10-16，李慧霸<magazine.lihuiba at 163.com> 写道：
> 
> 非也。
> 闰年的判断占用的代码篇幅的确比较大，但是并非在主要执行分支上。
> 如果不用一个表，就需要多判断日是否超过当月的区间，且需要判断日子是不是为 
> 0 ，这才是主线分支。

顺便提一句，对于小概率分支，GCC 有特殊支持。可以使用下面的代码：

#ifdef __GNUC__
# if __GNUC__ == 2 && __GNUC_MINOR__ < 96
#  define __builtin_expect(x, expected_value) (x)
# endif
# define LIKELY(x)   __builtin_expect((x),1)
# define UNLIKELY(x) __builtin_expect((x),0)
#else /* __GNUC__ */
# define LIKELY(x)   (x)
# define UNLIKELY(x) (x)
#endif /* __GNUC__ */

>> >4.算法如何引起一次page fault ？我不认为这个算法将引起 page fault 。这 
>> 里无论是数据段还是代码段都很难超过 4k
>> >，工作的时候，无论任何 os 都不可能把内存交换出去。如果有可能，你可以 
>> 举出合理的假设。
>> 如果可用物理内存有10M，而需要处理的数据有20M，如果算法的消耗的固定内存 
>> 多一个页（即标志数组），就有可能会多引起一次pf。
>> 确实这里无论是数据段还是代码段都很难超过 4k，但请将这个实际问题放在实 
>> 际的执行环境中去考虑，请考虑全局。
> 
> 
> 如果你指的 32 位操作系统，（否则没有这个问题），10M 物理内存是无论如何都 
> 跑不起来的。即使可以跑起来，也是个不合格的 os,
> 就如当年的 win95 以上。

慧霸的的意思是你增加的 1k 可能正好会多产生一个甚至多个 page fault。我认
为是可能的。毕竟一页只有 4k，而你一下子增加了 1k。

> 而且无论哪个算法都需要一个固定数组，即使你不使用那个表，还是需要另一张表 
> 存放每个月的日期上限。虽然这个数组小的多，但是依然需要独占数据段。这张表 
> 是十多字节也好，1k
> 字节也好，标准的编译器编译出来，都需要独占一页的数据段。

你说的有问题吧，除非你只是指这个测试程序。在实际应用中，你的代码的数据占
了 1/4 页，这很可能就会造成性能的区别。

由于这些因素对性能的影响在现代的计算机中已经很难只拿部分来做分析了。通常
的推荐是，按简单的方法做，用测试工具找出瓶颈，再做优化。写库的话也只能多
拿一些实际的例子多操练操练了。

>> >把以不好分析为理由把细节掩盖过去，不像程序员的作风哟，至少不像 C/C++ 
>> 程序员的做法。
>> 注重细节曾经是c/c++语言的优势，在那个"抓程序，促生产"的年代能写出非常 
>> 高效的程序。然而现自，它已经成为c++的一道硬伤，它使得我们在许多领域的 
>> 编程效率（注意不是程序执行效率）不够高，它使得大多数人学习语言的效率不 
>> 够高，它在某些方面阻碍了生产力的发展。
>> 大概很多朋友看了会不高兴，但这却是我作为一个13年程序员的感慨。
>> 我热爱这门语言，我非常关注c++的进展。
>>
> 
> 每种语言都有适用的范围，如果 C++ 都不在意性能细节了，何不用 java ? 现在 
> 的 jit 技术已经极大的减少了一般意义上 c++
> 程序和 java 程序的性能差距了。唯一剩下的，在处理器级别思考性能，java 依 
> 然还办不到。

嘿嘿，再不同意一把。在处理器级别，我的理解是 Java 的性能已经不明显弱于
C++ 了。个人认为，大家觉得 Java 慢的最主要原因是 Java 的内存管理模式造成
内存开销通常比 C++ 大一倍甚至更多，造成大量的 page fault，甚至虚存交换，
从而性能下降。

强调一句，C++ 的很大的强项（在另外一些人眼中的弱点）是手动内存管理。这可
能是它和 Java、.NET 等语言、环境最大的区别了。有人想把垃圾收集加到 C++
里，阻力很大，是一件非常正常的事。

吴咏炜