Типа достали меня со словами Померил. Мой вариант выполняется ничем не хуже чем вариант cppasm. В среднем 67h машинных тактов. Сразу предупрежу - в исходнике понатыкан int 3. Я гонял под SoftIce. Первое обращение специально сделал с кэш промахом. Забыл добавить - камень P4 HT И последнее - если раскоментировать строки: ; and eax,1 и ; setc al ; movzx eax,al Результаты будут прежние.
Количество обращений к памяти одинаково, остальное фигня. На современных камнях эти единичные такты никому не сдались. Только если эстетическое удовольствие получить.
MirrorBlack - я результаты не оспариваю, но на личном опыте убедился что мерять что-то на CPU с Hyper Threading не простое занятие. Результаты не стабильные очень. Кстати, ты получил ответ на свой вопрос Если мой код не медленнее, значит можно использовать его. А он на Си переписывается без проблем. К тому же к примеру Intel C++ Compiler дофига умный, и многие конструкции заменяет на команды, если они есть. Т.е. к примеру (x>>1) | ((x & 1) << 31) заменяется на ror. А вот к примеру (x<<1) практически никогда не реализуется как сдвиг - ни MS Visual C++, ни Intel C++: все заменяют на (x+x). Потому что у сложения выше вероятность что будет свободен исполнительный блок. У оптимизирующих компиляторов не всегда бывает легко предсказать, какой они код сгенерируют. Т.е. вполне может быть что на сишный код получиш в итоге свою bt, а может и не быть.
MirrorBlack На современных компах bt mem,r выполняется 8-10 тактов, а на логч.операциях 5-6. Нужна ли такая "мелочная" эконмия или нет - зависит от задачи. Для твоего примера она видимо нафиг не нужна и по смыслу и по тому, что на вызов функции тратится больше времени, чем на саму bt А вот если номер бита заранее известен как в примере #15, то тут ситуация другая, т.к. компилятор может заранее разложить число 406 на индекс байта 50 и на маску бита 100000b и юзать вместо bt команду test, которая заведомо быстрее bt на всех процессорах и не требует особых усилий и усложнения кода