Wine上的可执行文件比Windows运行得更快 – 为什么?

解决scheme:显然罪魁祸首是使用floor() ,其性能原来是依赖于glibc的操作系统。


这是以前的一个后续问题: 在Linux上比Windows更快的相同的程序 – 为什么?

我有一个小的C ++程序,用nuwen gcc 4.6.1编译时,在Wine上的运行速度要快于Windows XP(在同一台计算机上)。 问题是:为什么会发生这种情况?

Wine和Windows的时间分别为15.8秒和25.9秒。 请注意,我正在谈论相同的可执行文件 ,不仅仅是相同的C ++程序。

源代码在post的末尾。 编译的可执行文件在这里 (如果你相信我)。

这个特定的程序没有任何用处,它只是从一个更大的程序中解脱出来的一个简单的例子。 请看另外一个问题 ,对原始程序进行一些更精确的基准testing(重要的!!)和排除的最常见的可能性(例如其他程序占用Windows上的CPU,进程启动惩罚,系统调用的不同,如内存分配) 。 另外请注意,虽然在这里我使用rand()为简单起见,在原来我使用我自己的RNG,我知道没有堆分配。

我在这个话题上提出一个新的问题的原因是,现在我可以发布一个实际的简化代码示例来重现这个现象。

代码:

 #include <cstdlib> #include <cmath> int irand(int top) { return int(std::floor((std::rand() / (RAND_MAX + 1.0)) * top)); } template<typename T> class Vector { T *vec; const int sz; public: Vector(int n) : sz(n) { vec = new T[sz]; } ~Vector() { delete [] vec; } int size() const { return sz; } const T & operator [] (int i) const { return vec[i]; } T & operator [] (int i) { return vec[i]; } }; int main() { const int tmax = 20000; // increase this to make it run longer const int m = 10000; Vector<int> vec(150); for (int i=0; i < vec.size(); ++i) vec[i] = 0; // main loop for (int t=0; t < tmax; ++t) for (int j=0; j < m; ++j) { int s = irand(100) + 1; vec[s] += 1; } return 0; } 

UPDATE

看来,如果我用上面的确定性replaceirand()

 int irand(int top) { static int c = 0; return (c++) % top; } 

那么时间差就消失了。 我想要说明的是,在我原来的程序中,我使用了不同的RNG,而不是系统rand() 。 我正在挖掘现在的来源。

更新2

现在我用相当于原始程序中的内容replace了irand()函数。 它有点冗长(algorithm来自Numerical Recipes ),但重点是显示没有系统库被明确地调用(除了可能通过floor() )。 但时间差异仍然存在!

也许floor()可能是责任? 或者编译器生成对其他东西的调用?

 class ran1 { static const int table_len = 32; static const int int_max = (1u << 31) - 1; int idum; int next; int *shuffle_table; void propagate() { const int int_quo = 1277731; int k = idum/int_quo; idum = 16807*(idum - k*int_quo) - 2836*k; if (idum < 0) idum += int_max; } public: ran1() { shuffle_table = new int[table_len]; seedrand(54321); } ~ran1() { delete [] shuffle_table; } void seedrand(int seed) { idum = seed; for (int i = table_len-1; i >= 0; i--) { propagate(); shuffle_table[i] = idum; } next = idum; } double frand() { int i = next/(1 + (int_max-1)/table_len); next = shuffle_table[i]; propagate(); shuffle_table[i] = idum; return next/(int_max + 1.0); } } rng; int irand(int top) { return int(std::floor(rng.frand() * top)); } 

编辑:事实证明,罪魁祸首是floor()而不是rand()因为我怀疑 – 见OP的问题顶部的更新。

你的程序的运行时间主要是对rand()的调用。

因此我认为rand()是罪魁祸首。 我怀疑底层函数是由WINE / Windows运行时提供的,而这两个实现具有不同的性能特征。

测试这个假设的最简单方法是简单地在一个循环中调用rand() ,并在两个环境中调用相同的可执行文件。

编辑我已经看了一下WINE的源代码,这里是它的rand()

 /********************************************************************* * rand (MSVCRT.@) */ int CDECL MSVCRT_rand(void) { thread_data_t *data = msvcrt_get_thread_data(); /* this is the algorithm used by MSVC, according to * http://en.wikipedia.org/wiki/List_of_pseudorandom_number_generators */ data->random_seed = data->random_seed * 214013 + 2531011; return (data->random_seed >> 16) & MSVCRT_RAND_MAX; } 

我无法访问微软的源代码进行比较,但是如果性能差异在于获取线程本地数据而不是在RNG本身,那么我不会感到惊讶。

维基百科说:

Wine是一个兼容层,不是模拟器。 它通过提供Windows程序调用的DLL的替代实现来复制Windows计算机的功能,[需要的引证]以及替代Windows NT内核的过程。 这种重复的方法不同于也可以被认为是仿真的其他方法,其中Windows程序在虚拟机中运行[2]。 葡萄酒主要是使用黑盒测试逆向工程书写,以避免版权问题。

这意味着只要最终结果与本机窗口调用相同,wine的开发人员就可以用任何东西来替换api调用。 而且我想他们不需要使其与Windows的其他部分兼容。

从我所知道的情况来看,所使用的C标准库在两种不同的情况下会有所不同。 这会影响rand()调用以及floor()。

从mingw站点… MinGW compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes. 在XP下运行,这将使用Microsoft库。 看似简单。

但是,葡萄酒下的模型要复杂得多。 根据这个图表 ,操作系统的libc发挥了作用。 这可能是两者之间的差异。

虽然葡萄酒基本上是Windows,但你仍然在比较苹果和橙子。 而且,它不仅是苹果/桔子,牵引苹果和橙子的底层车辆是完全不同的。

简而言之,你的问题可能会被改写为“这段代码在Mac OSX上比在Windows上运行得更快”,并得到相同的答案。