解决方案:显然，罪魁祸首是floor()的使用，它的性能在glibc中是依赖于操作系统的。
这是之前一个问题的后续问题:同样的程序在Linux上比Windows上快——为什么?
我有一个小的c++程序，当用nuwen gcc 4.6.1编译时，在Wine上运行得比Windows XP快得多(在同一台计算机上)。问题是:为什么会发生这种情况?
Wine和Windows的时间分别为~15.8秒和25.9秒。注意，我讨论的是相同的可执行文件，而不仅仅是相同的c++程序。
源代码在文章的末尾。编译后的可执行文件在这里(如果你足够信任我的话)。
这个特定的程序没有做任何有用的事情，它只是从我的一个更大的程序中提炼出来的一个最小的例子。请参阅另一个问题，了解原始程序的更精确的基准测试(重要!!)和最常见的可能性被排除(例如其他程序占用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;
}
似乎如果我用确定性的东西代替上面的irand()，如
int irand(int top) {
static int c = 0;
return (c++) % top;
}
则时间差消失。我想指出的是，在我最初的程序中，我使用了一个不同的RNG，而不是系统rand()。
更新2
现在，我将irand()函数替换为与原始程序中相同的函数。它有点长(算法来自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));
}
edit:事实证明，罪魁祸首是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 NT内核。这种复制方法与其他可能被认为是模拟的方法不同，Windows程序在虚拟机中运行。[2]酒是主要使用黑盒测试逆向工程编写避免版权问题。
这意味着wine的开发人员可以用任何东西替换api调用，只要最终结果与本机窗口调用相同。我想他们并没有因为需要使它与Windows的其他部分兼容而受到限制。
据我所知，在这两种不同的情况下使用的C标准库是不同的。这会影响rand()调用和floor()。
From the mingw site…MinGW compilers provide access to the functionality of the Microsoft C runtime and some language-specific runtimes.在XP下运行，这将使用Microsoft库。看似很简单。
然而，葡萄酒下的模型要复杂得多。根据这个图，操作系统的libc开始发挥作用。这可能是两者的区别
虽然Wine基本上是Windows，但你仍然在比较苹果和橘子。而且，不仅是苹果/橙子，运输这些苹果和橙子的底层车辆也完全不同。
简而言之，你的问题可以简单地改写为"这段代码在Mac OSX上运行得比在Windows上快"，并得到相同的答案。