【问题标题】:Executable runs faster on Wine than Windows -- why?可执行文件在 Wine 上的运行速度比 Windows 快——为什么?
【发布时间】:2011-12-26 06:49:55
【问题描述】:

解决方案:显然罪魁祸首是使用了floor(),其性能在 glibc 中被证明是依赖于操作系统的。


这是上一个问题的后续问题:Same program faster on Linux than Windows -- why?

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

Wine 和 Windows 的时间分别为 ~15.8 和 25.9 秒。请注意,我说的是同一个可执行文件,而不仅仅是同一个 C++ 程序。

源码在文末。编译后的可执行文件是here(如果你足够信任我的话)。

这个特定的程序没有任何用处,它只是从我拥有的一个更大的程序中总结出来的一个最小示例。请参阅this other question 对原始程序进行更精确的基准测试(重要!!)并排除最常见的可能性(例如其他程序在 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;
}

那么时间差就消失了。我想指出,虽然在my original program 中我使用了不同的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));
}

【问题讨论】:

  • 静态/动态链接(什么 dll 依赖项?)
  • @sehe 我有一个 32 位 CPU,都是 32 位操作系统
  • 您能否消除对std::floor()std::rand() 的调用,例如通过将irand() 替换为返回相同确定性模式的函数?看看性能差异是否仍然存在会很有趣。
  • @aix 好点,如果我用int irand(int top) { static int c=0; return (c++) % top; } 替换irand,时间差就会消失(或变得非常小)。奇怪的是,在我的原始程序中,我使用的是来自 Numerical Recipes 的 RNG,而不是 systen rand()。我现在正在研究 RNG。
  • @celtschk 原来差异是由于floor()!我从没想过floor() 可能依赖于操作系统,但显然在 glibc 中它是。

标签: c++ windows linux performance benchmarking


【解决方案1】:

虽然 Wine 基本上是 Windows,但您仍在将苹果与橙子进行比较。同样,不仅是苹果/橙子,拖运苹果和橙子的底层车辆也完全不同。

简而言之,您的问题可以简单地改写为“此代码在 Mac OSX 上的运行速度比在 Windows 上运行得更快”并得到相同的答案。

【讨论】:

  • 如果代码不使用系统库,为什么会有差异?如果在同一个 CPU 上运行相同的代码,它应该花费相同的时间。我不清楚为什么它不会。
  • @Szabolcs:如果我们无法在您的计算机上进行配置,为什么还要问?您应该简单地在两端的 gprof 下运行它。或者干脆从 linux 上的 strace -c 开始。
【解决方案2】:

维基百科说:

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

这意味着 wine 的开发人员可以用任何东西替换 api 调用,只要最终结果与使用原生 windows 调用得到的结果相同。而且我想他们并没有因为需要使其与 Windows 的其余部分兼容而受到限制。

【讨论】:

  • 是的,但是你有没有假设在这种情况下 Windows API 是如何进入画面的?
  • 我的意思是这些 API 没有被调用。我看不出程序的主循环如何进行任何系统调用。
  • 您应该检查已执行程序的内存映像,以查看某些调用仅在运行用 VS 编译的代码时才被优化(由操作系统),因此 GCC 的执行速度较慢,当然除非您运行它与葡萄酒并不能效仿这种行为。 (推测:P)
【解决方案3】:

编辑:原来罪魁祸首是 floor() 而不是 rand() 我怀疑 - 见 OP 问题顶部的更新。

程序的运行时间主要由对rand() 的调用决定。

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

检验这一假设的最简单方法是在循环中简单地调用rand(),并在两种环境中为相同的可执行文件计时。

edit我看过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;
}

我无法访问 Microsoft's source code 进行比较,但如果性能差异在于获取线程本地数据而不是 RNG 本身,我不会感到惊讶。

【讨论】:

  • 即使rand运行相同的速度,如果返回不同的结果,可能会影响时序,因为结果用于索引,因此会影响缓存效率。
  • @Suma:确实。但是,由于该数组只有 150 个整数长,我怀疑在 WINE 中实际调用的速度比在 Windows 中快 2 倍。但是,目前不能排除这两种可能性。
  • @Suma 总的来说这是一个很好的观点,但我怀疑这里的情况。数组(150 个整数)应该适合缓存,并且任何非完全损坏的 rand() 都应该导致相同的(平均)访问模式。
  • @Suma:绝对是。它是 Visual C 运行时的一部分,WINE 必须对其进行模拟(请参阅我更新的答案)。
  • 我还是觉得有点奇怪,像floor()这样的基本操作并没有直接在glibc中实现,而是依赖于操作系统。我希望一个好的编译器能够内联这些函数(连同sincos 等)
【解决方案4】:

据我所知,在两种不同的场景中使用的 C 标准库会有所不同。这会影响 rand() 调用以及 floor()。

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

但是,wine 下的模型要复杂得多。根据this diagram,操作系统的 libc 开始发挥作用。这可能是两者之间的区别。

【讨论】:

    猜你喜欢
    • 2015-10-27
    • 2015-01-27
    • 2013-05-22
    • 2011-08-27
    • 2012-03-29
    • 2017-06-04
    • 2012-08-23
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多