Исходное сообщение
"Представлен GCC Exlorer, интерактивный компилятор на базе GC..." Отправлено solardiz, 25-Май-12 03:59
Я даже пошел по ссылке и глянул. Предположение, что дело в количестве операций над флагами мне видится странным (вряд ли на серьезном процессоре от Intel или AMD cmov* будет реализован на микрокоде или транслироваться в большое количество uop'ов - по идее, любой из cmov* должен на этих процессорах быть в железе и выполняться не более чем за один такт по throughput при отсутствии stall'ов). Более вероятным мне представляется, что один из вариантов условия более соответствовал конкретным входным данным, что, возможно, позволяло избежать data или output dependency stall (недавно измененный операнд оказывался невостребованным или же результат оставался неизменным) в большей части случаев. Если так, то это не то, что компилятор должен угадывать сам, без хотя бы profiler feedback'а. Если такая особенность данных закономерна (статистически таких наборов данных больше, чем "противоположных"), то вместо игр с a < b vs. b > a, которые не обязаны транслироваться именно в эти инструкции, может быть лучше использовать __builtin_expect() (сначала проверив на __GNUC__), чтобы передать совет компилятору явно. Ссылку на руководство от AMD тоже глянул - она почти не в тему - там только о том как cmov* лучше branch'ей. ...Проверил на Xeon E5420 (что было под рукой) - как и ожидал, cmovl и cmovge выполняются одинаково за один такт, независимо от выполнения условия. Повлиять на stall'ы в этой или соседних инструкциях меняя cmovl/cmovge или (не)выполнение условия мне не удалось. Возможно, на другом процессоре удалось бы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Я даже пошел по ссылке и глянул. Предположение, что дело в количестве > операций над флагами мне видится странным (вряд ли на серьезном процессоре > от Intel или AMD cmov* будет реализован на микрокоде или транслироваться > в большое количество uop'ов - по идее, любой из cmov* должен > на этих процессорах быть в железе и выполняться не более чем > за один такт по throughput при отсутствии stall'ов). Более вероятным мне > представляется, что один из вариантов условия более соответствовал конкретным входным > данным, что, возможно, позволяло избежать data или output dependency stall (недавно > измененный операнд оказывался невостребованным или же результат оставался неизменным) > в большей части случаев. Если так, то это не то, что > компилятор должен угадывать сам, без хотя бы profiler feedback'а. Если такая > особенность данных закономерна (статистически таких наборов данных больше, чем "противоположных"), > то вместо игр с a < b vs. b > a, > которые не обязаны транслироваться именно в эти инструкции, может быть лучше > использовать __builtin_expect() (сначала проверив на __GNUC__), чтобы передать совет > компилятору явно. Ссылку на руководство от AMD тоже глянул - она > почти не в тему - там только о том как cmov* > лучше branch'ей. > ...Проверил на Xeon E5420 (что было под рукой) - как и ожидал, > cmovl и cmovge выполняются одинаково за один такт, независимо от выполнения > условия. Повлиять на stall'ы в этой или соседних инструкциях меняя cmovl/cmovge > или (не)выполнение условия мне не удалось. Возможно, на другом процессоре удалось > бы.
	Введите код, изображенный на картинке: