Свежие комментарии

> Отгадка оказалась довольно тривиальной

Я думал, что на современных архитектурах, типа x86_64, чтение одного байта по скорости равно чтению 8 байт.

Я теории не знаю, спою как чукча: чисто визуально, если делаю кривую и ставлю режим смешивания Lightness, то падает насыщенность. В Lab при манипуляции с L-каналом - нет.

С чего ему быть невыровненым, если malloc возвращает aligned на 16 (а в данном тесте вообще адрес буфера кончается на d00000)?

Потом я туда read прямо из файла, где 8-байтовые штуки лежат вплотную. Получается, всегда выровнено на 8 байт, ровнее не бывает.

(вот кстати реальные данные, а не просто ключи - 20-байтные + 8 байт ключа, интересно, будет ли быстрее, если подровнять).

Ну, мне скорее интересно, откуда таки взялось cmov. Ибо для всех 64-битных архитектур gcc43 делает совершенно одинаковый код с -O2/O3 (для меньшей оптимизации начинаются всякие фокусы, -O0 - просто чудо природы).

А так - конечно пофигу.

Да, bswap - правильно.

Но даже с gcc43 -O3 -mtune=core2 -march=core2 получается (все в регистрах)
cmpq
seta
cmpq
setb
movzbl
subl
ret

Может я каких ключей недодал? Хотя код вполне разумный на самом деле....

И, кстати, интересная мысля - посчитать частоты исполнения кусочков первого варианта. Тоже сделаю....

Чисто интуитивно, при cmove у процессора только непонятки со значением регистра, а при jmp -- с тканью судьбы.

Если сгенерировался хороший код исходного варианта (mov; cmp; jmp; mov; cmp; jmp; ...), то получается 24 команды, в которых mov и cmp prefetch-ится, но толком не параллелятся, будем считать, что в среднем исполняется 12 штук. А если сгенерировался хороший код (mov; bswap; mov; bswap; cmp; cmovl; cmova; sub), то 5 команд, т.к. 1 и 3, 2 и 4, 6 и 7 могут параллелиться.

Когда первые байты сильно различаются, то на тысячной итерации всё предсказано и получаются 3 команды, что, конечно, бъёт наповал.

Только мне кажется, что оба варианта говённо скомпилировались и дело в волшебных пузырьках.
Ждём постинга с дизассемблированным кодом.

А пока я не полез профайлить, почему ты считаешь что для *современного* интела cmove лучше чем jmp (не indirect, конечно)? Мне представляется что это одно и то же, и оба спекулятивно исполняются.

Тьфу, пропасть, как же скормить "меньше" комментариям? Третья попытка

А я проверил, мне не жалко.

18млн ключей (никаких других данных нет)

2300 msec (округляю до 100ms) - мой вариант
3900 msec - твой вариант.

Возможное объяснение в том, что пространство ключей большое, распределены они случайно (ибо это хэши fnv64), поэтому первое же сравнение дает разницу в 255 из 256 случаев.

При этом, сама схема с cmove - хорошая, для numeric sort:
(a>b)-(a < b) - 3500 msec
а мой тупой вариант
(a>b)?1:((a < b)?-1:0)) - 3800 msec.

Ну и std::sort для numeric - 2300 ms - включая инициализацию std::vector,
а если ее не считать - то 1800ms - инлайнинг и алгоритм считается получше чем qsort.

это я перепутал, лень было грепать /usr/include/machine

вообще-то всё зависит от задачи. Грубо можно так, наверное
unsigned int64 *p1 = (unsigned int64 *)d1;
unsigned int64 *p2 = (unsigned int64 *)d2;
return p1[0]-p2[0];

А эти betoh64 - оно где так называется?

А то на FreeBSD оно be64toh. и естественно bswap64 на интеле и ничего на "мотороле" (в смысле - Сане)

Re: простите,
будет 0. не вижу пока проблемы.

см. выше, это не правильно.