__forceinline int64 FastMul( int64 a, int64 b ) {
    return (int64)FastMul( (uint64)a, (uint64)b );
}


На Core2Duo/Merom тест

for( int i = 0; i < 1000000000; i++ ) {
#ifdef FAST_MUL
    result = FastMul( result, mult );
#else
    result *= mult;
#endif
}

выполняется за 4.2 секунды с FAST_MUL и за 7.7 секунд без него.

Замечу, что на архитектуре Intel64 (aka x86-64) для умножения 64-битных чисел используется отдельная команда процессора, так что такой проблемы там нет.

Чтобы окончательно разобраться, придётся заглянуть в Стандарт Unicode. По стандарту, character это некий абстрактный символ, например "маленькая кириллическая буква а" или "римская цифра Ⅰ". Каждому character'у приписан некий номер — code point (для "маленькой кириллической буквы а" это число 0x430). Code point это число в диапазоне от 0 до 0x1FFFFF, однако большинству таких чисел не соответствует никакого character'а. Способ хранить эти code point'ы в памяти называется кодировкой, самые популярные кодировки для Unicode code point'ов — UTF-32, UTF-16 и UTF-8.

UTF-32 наиболее проста: каждый code point записывается как 32-битное число. Упомянутая "римская цифра Ⅰ" (не путать с "большой латинской буквой I") с code point 0x2160 будет записана как DWORD 0x00002160. Т.к. DWORD'ы записываются по-разному на Big Endian и Little Endian системах, вместо одной кодировки UTF-32 получаются уже две: UTF-32-BE (Big Endian) и UTF-32-LE (Little Endian). wchar_t в GCC/Linux представляет собой code point как раз в UTF-32 кодировке.

Более популярная кодировка UTF-16 использует для записи code point'а одно или два 16-битных слова. В первых версиях стандартах Unicode не было code point'ов больших, чем 0xFFFF. Программисты, заметив это, обрадовались, и решили, что раз любой code point влезает в 16 бит, то пусть отныне и во веки веков sizeof(wchar_t) = 2. Назвали эту кодировку UTF-16. Наша "римская цифра Ⅰ" записывалась в ней как 0x2160, и все были довольны. Но радоваться предстояло недолго: в скором времени оказалось, что за свою историю человечество придумало больше, чем 65536 символов, так что 16 бит явно не хватает. Тогда первые 65536 code point'ов назвали Basic Multingual Plane, а для новых character'ов добавили ещё 16 таких же plane'ов. Чтобы старые программы было легче адаптировать к этим нововведениям, придумали записывать code point'ы из новых 16 plane'ов так: если code point больше, чем 0xFFFF, то из него вычитается 0x10000 и в результате получается 20-битное число в диапазоне от 0 до 0xFFFFF. Это число разбивается на две половинки по 10 бит каждая. Затем старшая половинка этого числа дополняется слева последовательностью бит 0b110110, а младшая — 0b110111. Два получившихся 16-битных слова называются суррогатной парой, и представляют собой запись нужного code point в кодировке UTF-16. Например, "готическая буква манна" имеет code point 0x1033C. После вычитания 0x10000 остаётся число 0x33C = 0b00000000001100111100. Разбиваем на две половинки: 0b0000000000 и 0b1100111100. Дополняем старшую половинку последовательностью 0b110110, а младшую последовательностью 0b110111; получается 0b1101100000000000 = 0xD800 и 0b1101111100111100 = 0xDF3C. Таким образом, "готическая буква манна" представляется в кодировке UTF-16 суррогатной парой 0xD800 0xDF3C.

Определить, является ли слово в кодировке UTF-16 само по себе code point'ом или частью суррогатной пары можно по первым его битам: если слово начинается с последовательности 0x11011, то оно часть суррогатной пары, иначе — целый code point. При редактировании UTF-16 строки нужно учитавать, что сначала всегда должен идти High Surrogate (включающий старшие разряды 20-битного числа), а затем Low Surrogate (с младшими 10-ю разрядами). Если пренебречь этим правилом, можно получить очень интересные, но редко проявляющиеся баги. К сожалению, такие баги есть не только в пользовательском ПО, но встречаются и в системных библиотеках. Так, функция _wcsrev из msvcrt меняет местами нижний и верхний суррогаты в суррогатной паре. Но это уже совсем другая история.