Можно ли использовать подсказку предсказания ветвлений в C #?

Question

Например, я знаю, что он определен для gcc и используется в ядре Linux как:

#define likely(x)       __builtin_expect((x),1)
#define unlikely(x)     __builtin_expect((x),0)

Если в C # ничего подобного не возможно, это лучшая альтернатива для ручного изменения порядка операторов if,ставить наиболее вероятный случай первым?Существуют ли другие способы оптимизации, основанные на этом типе внешних знаний?

В соответствующей заметке CLR знает, как определить защитные предложения, и предполагает, что будет выбрана альтернативная ветвь, что делает эту оптимизацию неприемлемой для использования.на страже, верно?

(обратите внимание, что я понимаю, что это может быть микрооптимизацией; меня интересуют только академические цели.)

Answer 1

Краткий ответ: Нет.

Более длинный ответ: В большинстве случаев вам не нужно действительно .Вы можете давать подсказки, изменяя логику в своих высказываниях.Это проще сделать с помощью инструмента повышения производительности, например, встроенного в более высокие (и более дорогие) версии Visual Studio, поскольку вы можете получить счетчик ошибочно предсказанных ветвей.Я понимаю, что это для академических целей, но приятно знать, что JITer очень хорош для оптимизации вашего кода для вас.Как пример (взято в значительной степени дословно из CLR через C # )

Этот код:

public static void Main() {
    Int32[] a = new Int32[5];
    for(Int32 index = 0; index < a.Length; index++) {
        // Do something with a[index]
    }
}

может показаться неэффективным, поскольку a.Length является свойствоми, как мы знаем в C #, свойство на самом деле представляет собой набор из одного или двух методов (get_XXX и set_XXX).Однако JIT знает, что это свойство, и либо сохраняет длину в локальной переменной для вас, либо указывает на метод, чтобы избежать накладных расходов.

... некоторые разработчики недооценили возможностиJIT-компилятор и попытался написать «умный код», пытаясь помочь JIT-компилятору.Однако любые умные попытки, которые вы придумали, почти наверняка негативно скажутся на производительности и затруднят чтение кода, снижая его удобство обслуживания.

Помимо прочего, он действительно идет дальше и выполняет проверку границ.однажды за пределами цикла, а не внутри цикла, что ухудшит производительность.

Я понимаю, что это не имеет непосредственного отношения к вашему вопросу, но я предполагаю, что я пытаюсьНеобходимо сделать так, чтобы подобные микрооптимизации не очень помогли вам в C #, потому что JIT обычно делает это лучше, так как он был разработан именно для этого.(Забавно, что JIT-компилятор x86 выполняет более агрессивные оптимизации, чем аналог x64)

В этой статье объясняются некоторые из оптимизаций, которые были добавлены в .NET 3.5 SP1, среди которых улучшениявыпрямление веток для улучшения предсказания и локальности кэша.

При всем этом, если вы хотите прочитать большую книгу, в которой рассказывается о том, что генерирует компилятор, и о производительности CLR, я рекомендую книгу, которую я цитировал.выше, CLR через C #.

РЕДАКТИРОВАТЬ: я должен отметить, что если бы это было возможно в настоящее время в .NET, вы могли бы найти информацию либо в стандарт EMCA-335 или работаетпроект .Не существует стандарта, который бы это поддерживал, и просмотр метаданных в чем-то вроде IlDasm или CFF Explorer не показывает никаких признаков каких-либо специальных метаданных, которые могут намекнуть на предсказания ветвления.