goto优化重构

Question

我有一个"MyFunction“，我一直在纠结于是否应该或不应该在上面使用goto，并且在类似的情况下(希望是罕见的)。所以我试着在这种情况下养成一个刻不容缓的习惯。做还是不做。

int MyFunction()
{   if (likely_condition)
    {
    condition_met:
        // ...
        return result;
    }
    else /*unlikely failure*/
    {   // meet condition
        goto condition_met;
    }
}

我打算将失败的条件跳转指令的好处纳入到可能的情况中。但是，我看不出编译器如何知道在没有这样的情况下，用哪种方法来简化案例的概率。

1. 它起作用了吗？
2. 这些好处值得混淆吗？
3. 是否有更好(更少冗长、更有结构、更有表现力)的方法来启用这种优化？

Answer 1

如果正确的分支预测，现代CPU将以相同的性能接受该分支。因此，如果这是在内部循环中，if (unlikely) { meet condition } common code;的性能将与您所写的相匹配。

另外，如果您在两个分支中详细说明了公共代码，编译器将生成与您所编写的代码相同的代码:将为if子句发出公共大小写，而else子句将jmp到公共代码。在像*out = whatever; return result;这样更简单的终端案例中，您总是可以看到这一点。调试时，很难分辨您正在查看的是哪个return，因为它们都已合并。

Answer 2

在我看来，你想要做的优化大多是过时的。大多数现代处理器都内置了分支预测，因此(假设它被足够多地用于注意到)，它们跟踪一个分支被占用或不使用的频率，并根据该分支过去被占用的模式来预测该分支是否可能被占用。在这种情况下，速度主要取决于预测的准确性，而不是预测是针对已采取还是不接受。

因此，您最好使用更简单的代码：

int MyFunction() {   
    if (!likely_condition) {
        meet_condition();
    }
    // ...
    return result;
}

Answer 3

1. 看起来，只要condition_met:不跳过变量初始化，代码就会像您预期的那样工作。
2. 不，您甚至不知道混淆的版本会编译成更优化的代码。编译器优化(和处理器分支预测)在最近变得非常聪明。

3.

int MyFunction()
{
    if (!likely_condition)
    {
        // meet condition
    }

    condition_met:
        // ...
    return result;
}

或者，如果它帮助您的编译器(检查程序集)

int MyFunction()
{
    if (likely_condition); else
    {
        // meet condition
    }

    condition_met:
        // ...
    return result;
}