General Category > Общий раздел
Странные битовые операции
kkkk:
--- Цитировать ---видимо, return (x > clip_box.x2) | ((x < clip_box.x1) << 2);
на обероне будет как-то так:
RETURN SYSTEM.VAL( UNSIGNED32, SYSTEM.VAL( SET, ORD( x > clipBox.x2 )) + SYSTEM.VAL( SET, ASH( ORD( x < clipBox.x1 ), 2)));
--- Конец цитаты ---
А почему не так?
--- Код: --- RETURN ORD( x > clipBox.x2) + ORD( x < clipBox.x1 ) * 4
--- Конец кода ---
Или я что-то упустил? Ещё я не припомню гарантий в описании, что ORD(TRUE) = 1, а ORD(FALSE) = 0, но иначе ORD для BOOLEAN не имел бы смысла.
В Си где только можно использую нормальную арифметику вместо битовых операций и не чувствую, что чего-то не хватает.
Geniepro:
Так это у них там помешанность на маловразумительном типе SET. Теорию множеств не любят, но множества обожают. Странные они...
Geniepro:
--- Цитата: kkkk от Ноябрь 18, 2016, 03:52:59 pm ---В Си где только можно использую нормальную арифметику вместо битовых операций и не чувствую, что чего-то не хватает.
--- Конец цитаты ---
Вообще в зависимости от компилятора может порождаться разный по быстродействию код. На такой тестовый пример:
--- Код: ---int test(int x, int num1, int num2) {
return (x > num1) | ((x < num2) << 2);
}
int test2(int x, int num1, int num2) {
return (x > num1) + (x < num2) * 4;
}
--- Конец кода ---
https://godbolt.org/
Компилятор clang 3.9.0 генерирует почти одинаковый код, заменив умножение на сдвиг, разница лишь в том, что он оставляет команды or и add.
Компилятор gcc 6.2 тоже генерирует почти одинаковый код, заменив и умножение, и сдвиг на готовую сдвинутую константу (4), и опять разница лишь в том, что он тоже оставляет команды or и add.
А вот компилятор icc 17, как ни странно, генерирует код, соответствующий коду на си -- то есть в первом случае shl и or, а во втором случае imul и add. Не помню, какие там растактовки команд у современных процессоров, но в принципе код от icc может быть медленнее, чем у других компиляторов, ведь обычно команда умножения гораздо сложнее и дольше, чем сдвига (ну по-крайней мере на старых процессорах).
PS. Впрочем, с включенными оптимизациями код сильно меняется, так что может эти рассуждения и бесполезны, хз...
kkkk:
Может, современные интелы настолько круты, что умножение на степень 2-ки выполняют столь же быстро, как битовый сдвиг, поэтому интеловский компилятор и не напрягается ;D ?
trurl:
Помню как-то хаяли компилятор, который генерировал add 1, а не inc. Как оказалось, актуальный на то время процессор выполнял add быстрее, чем inc.
Навигация
Перейти к полной версии