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

сравнение как

return (a > b) - (b > a)

генерирует 2 команды cmove и ни одного jmp. cmove тоже, конечно, не сахар, спекулятивно исполнять процессору трудно, но лучше чем jmp.

Ещё помогает htonl каакой-нить, он инлайнится в одну команду bswap на 64 битах.

Короче, я за

a1 = betoh64(a);
b1 = betoh64(b);
return (a1 > b1) - (a1 < b1);

Может я неправильно понял задачу: а radix sort тут не поможет?

Потому что это byte order, а не численный.

Байты в лонгах-интах идут не подряд и порядок (результат) сортировки для двух способов сравнения получается разный.

Пардон, писал не проверив.
Библиотечный memcmp в FreeBSD лежит в {amd64,i386}/string/memcmp.S а вовсе не в string/memcmp.c (последний вариант - для совместимости и в реальной жизни никуда не попадет).

И скорее всего на длинных сравнениях он выиграет, как только цена call станет невидной. Но у меня то 8 байт.

А в какой операционке ? Во FreeBSD memcmp выглядит так:
do {
if (*p1++ != *p2++) return (*--p1 - *--p2);
} while(--n != 0);
Что есть обощенный вариант вашего решения.

А в чём вопрос для такого специфического момента ручками закодировать qsort?

Да, и конверсия просто буфера в вектор - это вдвое по памяти, а читать кусочками - тоже никакой радости.

У меня восьмерки нигде нет, естественно (зачем она, если есть 8.3)

Но вот упоминание о данном синтаксисе в доке на 8.0.7
http://www.commandprompt.com/community/pgdocs8/runtime-config-compatible (первое, что гугл нашел)

Гы, а никак по-нормальному :)

Byte order, а не numeric. С числовым порядком все несколько проще.

Идея ясна. Но она никак не противоречит второму описанному мной подходу.

Мешает эргономика просесса. ДопустимЮ у Вас есть 2 дубля, и надо выбрать, какой из них пойдёт в работу. Проявил оба, сравнил, выбрал, начал дорабатывать выбранный. Идея просветного стола, контролек, index print - она правильная.

При конвертации raw совершается очень ограниченное количество управляемых оператором действий, и эти действия, как и в случае плёночной проявки, мало зависят от сюжета, условий освещения, и т.п. При съёмке на цифру, как и в плёночном процессе, важно лишь попасть в широту материала (а она определяется камерой и выбранным конвертором - так же, как и раньше она определялась плёнкой и проявкой). Надо снимать чисто, и не поддаваться соблазнам петлять в конверторе, бесконечно варьируя парой-тройкой параметров, которые реально влиюят на конверсию. Если конвертор raw на выходе имеет битмэп в представлении с плавающей точкой и дальнейшая обработка в редакторе ведётся с незначительными потерями точности - возвращаться к конвертору и менять параметры конвертации практически не приходится.

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

Главная задача конвертора не в том, чтобы из него напрямую можно было печатать (куда печатать? - я файлы для разных принтеров и разных форматов печати по-разному готовлю), а в том, чтобы обеспечить максимально качественный материал для дальнейшей цветокоррекции.

У меня оно во входном файле лежит вместе (записями фиксированной длины).

Ну и конечно не hot spot - тестовый файл порождается 3 минуты, сортируется 3 секунды, а вот в индексированный вид (BTree) сейчас пишется 3 часа (ну а моя задача писать в Btree еще за несколько минут, хотя не уверен в возможности, экспериментирую)

Да, в рафинированном (только ключи) случае std::sort(vector...) быстрее.

Если ключи с данными (данных - больше), то время на копирование съедает выигрыш.