在Wine上，可执行文件在Windows上的运行速度比Windows快-为什么? [英] Executable runs faster on Wine than Windows -- why?
问题描述
解决方案:显然，罪魁祸首是使用floor()，其性能在glibc中取决于操作系统.
Solution: Apparently the culprit was the use of floor(), the performance of which turns out to be OS-dependent in glibc.
这是较早版本的后续问题:相同程序的速度更快在Linux上而不是Windows上-为什么?
This is a followup question to an earlier one: Same program faster on Linux than Windows -- why?
我有一个小型C ++程序，当使用 nuwen gcc 4.6.1 ，在Wine上运行的速度要比Windows XP(在同一台计算机上)快得多.问题:为什么会这样?
I have a small C++ program, that, when compiled with nuwen gcc 4.6.1, runs much faster on Wine than Windows XP (on the same computer). The question: why does this happen?
Wine和Windows的时间分别为〜15.8和25.9秒.请注意，我所说的是同一个 executable ，而不仅仅是同一个C ++程序.
The timings are ~15.8 and 25.9 seconds, for Wine and Windows respectively. Note that I'm talking about the same executable, not only the same C++ program.
源代码在帖子的结尾. 此处(如果您对我足够信任的话).
The source code is at the end of the post. The compiled executable is here (if you trust me enough).
这个特定的程序没有任何用处，它只是我拥有的一个较大程序的一个最小示例.请参阅此其他问题，以获取有关该基准的一些更精确的基准原始程序(重要！)和最常见的可能性排除在外(例如其他程序在Windows上占用了CPU，进程启动损失，系统调用的差异(例如内存分配)).还要注意，尽管在这里我使用rand()为简单起见，但在原始版本中，我使用了我自己的RNG，我知道它没有堆分配.
This particular program does nothing useful, it is just a minimal example boiled down from a larger program I have. Please see this other question for some more precise benchmarking of the original program (important!!) and the most common possibilities ruled out (such as other programs hogging the CPU on Windows, process startup penalty, difference in system calls such as memory allocation). Also note that while here I used rand() for simplicity, in the original I used my own RNG which I know does no heap-allocation.
之所以打开关于该主题的新问题，是因为现在我可以发布一个实际的简化代码示例来重现该现象.
代码:
#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()替换为确定性的内容，例如
It seems that if I replace irand() above with something deterministic such as
int irand(int top) {
static int c = 0;
return (c++) % top;
}
然后，时间差消失了.我想在我的原始程序中指出我使用了其他RNG，而不是系统rand().我现在正在研究它的来源.
then the timing difference disappears. I'd like to note though that in my original program I used a different RNG, not the system rand(). I'm digging into the source of that now.
更新2
现在，我用与原始程序中相同的功能替换了irand()函数.这有点冗长(算法来自数字食谱)，但重点是要证明没有系统库是被显式调用(可能通过floor()除外).但是时间差仍然存在！
Now I replaced the irand() function with an equivalent of what I had in the original program. It is a bit lengthy (the algorithm is from Numerical Recipes), but the point was to show that no system libraries are being called explictly (except possibly through floor()). Yet the timing difference is still there!
也许是floor()的罪魁祸首?还是编译器生成对其他内容的调用?
Perhaps floor() could be to blame? Or the compiler generates calls to something else?
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的问题顶部的更新.
edit: It turned out that the culprit was floor() and not rand() as I suspected - see
the update at the top of the OP's question.
程序的运行时间主要取决于对rand()的调用.
The run time of your program is dominated by the calls to rand().
因此，我认为rand()是罪魁祸首.我怀疑基本功能是由WINE/Windows运行时提供的，并且两个实现具有不同的性能特征.
I therefore think that rand() is the culprit. I suspect that the underlying function is provided by the WINE/Windows runtime, and the two implementations have different performance characteristics.
检验该假设的最简单方法是在循环中简单地调用rand()，并在两种环境中对相同的可执行文件计时.
The easiest way to test this hypothesis would be to simply call rand() in a loop, and time the same executable in both environments.
编辑我看过WINE源代码，这是它的rand()的实现:
edit I've had a look at the WINE source code, and here is its implementation of 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;
}
I don't have access to Microsoft's source code to compare, but it wouldn't surprise me if the difference in performance was in the getting of thread-local data rather than in the RNG itself.
这篇关于在Wine上，可执行文件在Windows上的运行速度比Windows快-为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
