Операции то равнозначные, но реализации различны. И поэтому "&" - выигрывает у "%" в проверке на четность.

З.Ы: Для тех кто в танке: посмотрите на реализацию % и & через дизассемблер... 

0042602E  mov         dword ptr [a],64h 
00426035  mov         eax,dword ptr [a] 
00426038  and         eax,80000001h 
0042603D  jns         WinMain+34h (426044h) 



0042602E  mov         dword ptr [a],64h 
00426035  mov         eax,dword ptr [a] 
00426038  and         eax,1 
0042603B  jne         WinMain+44h (426054h) 


Думаю пояснять ни чего не надо?!

Добавлено @ 20:03 
единственное, в чем преимущество (%), так в том, что проблем с unsigned у вас никогда не будет, поэтому (%) корректнее чем (&) 

Это медленнее, чем 

  


Все зависит от степени привыкания    

Неа, в твоем примере мы видим оптимизацию компилятора, а никак не реализацию  


З.Ы.: для танкистов:
 

Слушай, танкист! не морочь людям мозги. Посмотри на свой же код! 

против:
Что называется - почувствуйте разницу. 

ну и ты хоть взгляни, может найдешь отличия   


З.Ы.: для тех, кто еще остается в танке - вместо int подставть unsigned ...
 

Если танкист пишет только в дебаге, то мне пора на пенсию )
Вот релиз, проверка HINSTANCE на четность:



00403169  mov         edi,dword ptr [esp+10h] 
0040316D  mov         esi,edi 
0040316F  and         esi,1 
00403172  je          WinMain+1Eh (40317Eh) 
        ::MessageBox(0,0,0,0);
00403174  push        0    
00403176  push        0    
00403178  push        0    
0040317A  push        0    
0040317C  call        ebx  
    }
    if(a&1){
0040317E  test        esi,esi 
00403180  je          WinMain+2Ch (40318Ch) 
        ::MessageBox(0,0,0,0);
00403182  push        0    
00403184  push        0    
00403186  push        0    
00403188  push        0    
0040318A  call        ebx  
    }

Добавлено @ 11:27 
Глупо спорить на тему скорости с оптимизацией VS от самой Microsoft ) 

GremlinProg, а кроме VS других компилеров не существует? % есть остаток от деления и если бы компилер делал то, что ему говорят (А многие так и делают), то провёл бы деление и взял остаток. Ваш промер есть оптимизация кода конкретного компилера и для общего случая он (как пример) не годится.

Точно так же х/2 компилеры оптимизуют в х>>1. Но говорить, что в общем случае деление по скорости совпадает со сдвигом на 1 - бесмыссленно.  

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

Деление целочисленных есть ни что иное, как сдвиг вправо, а остаток от деления - правая часть результата этого сдвига. Зачем делить, если можно просто взять этот остаток Эндом? Оптимизация в любом компиляторе это должна учитывать, иначе на что она нужна, такая оптимизация?
А по поводу 
заблуждаешься: код высокого уровня для того и нужен, чтобы абстрагировать задачу от конкретной её реализации на конкретном компиляторе, поэтому, если необходимо вычислить остаток, то и нужно писать (%), а не (&), а компилятор сам знает, что он должен сделать быстрее, а что - медленнее. Может быть это и прописные истины, но почему-то многие о них забывают.  

Уровень кода тут не причём. Тем более С (о котором мы сейчас в общем-то и говорим). Например освобождение памяти прямо таки опускает на землю абстрактность любой задачи.
Вообще С тем и примечателен, что даёт делать то, что угодно (в отличии он Явы например). И если я хочу, чтобы он делил, он должен делить. 
И компилеров существует масса и никто не может со 100% увереностью сказать во что превратиться его код, если он не будет вручную навязывать это компилятору сам.

Другое дело, что оптимизатор на многих компилерах по умолчанию включен. Это с идеалогической точки зрения как раз ошибочный подход. 

где-то в этой фразе должно быть словосочетание "степень двойки"... 

ps. так и не смог уловить предмет спора. такое впечатление что "каждый о своем"...  

dumb, похоже прав: я тут говорю о "бессмертном" коде, т.е. код живет и развивается до тех пор, пока его понимают, и как бы вы не издевались над ним, как бы не ускоряли его выполнение - код умирает сразу, если хотя бы часть его становится нечитабельной. sergej.z мешает две абсолютно разные вещи: моделирование и оптимизация. Как известно, моделирование - первостепенная задача - это есть сам процесс создания программы, на этом этапе закладываются основы её функционирования. А оптимизация - второстепенная задача, которая не всегда оправдывает затраты: оптимизировать можно вечность, а результат будет скрыт от глаз пользователя за толщей интерфейсов операционной системы, и даже не важно какой. 

Предмет в том, что GremlinProg утверждаетм что х%2 и х&1 - одинаковые операции.
Я же придерживаюсь мнения, что это может быть верно, но после оптимизации на конкретном компиляторе. 

не совсем так, я пытался объяснить, почему нельзя использовать такие оптимизации в коде. И показал пример, который визуально указывает на разные действия, в данном случае модуль и умножение, а практически делает одно и то же. Объяснил, почему для разработчика так важно знать, что действительно происходит в коде, т.е. что он имел ввиду, когда писал код. Если над проектом работает один программист, то, конечно, можно положиться на его память и надеяться на то, что через пару недель, месяцев, лет он таки вспомнит свои действия. Но, если над проектом работает несколько программистов, то бишь группа, тогда с такими подходами, как у sergej.z, сработаться им будет крайне сложно.

Моя позиция такая: если хочешь оптимизировать - используй оптимизацию компилятора. Если оптимизация не устраивает - меняй компилятор и учи язык. Почти все компиляторы, которые только существуют имеют возможность работать в нескольких режимах оптимизации. Суть даже не в том, нужна оптимтзация или нет, оптимизация присутствует всегда, разница лишь в её детальности.