Свежие комментарии
Title | Comment |
---|---|
а как из них цепочку составить? |
а как из них цепочку составить? |
сравнение как return (a > b) - (b > a) генерирует 2 |
сравнение как return (a > b) - (b > a) генерирует 2 команды cmove и ни одного jmp. cmove тоже, конечно, не сахар, спекулятивно исполнять процессору трудно, но лучше чем jmp. Ещё помогает htonl каакой-нить, он инлайнится в одну команду bswap на 64 битах. Короче, я за a1 = betoh64(a); |
Да может и поможет, но где реализация в stdlib? |
Да может и поможет, но где реализация в stdlib? |
Может я неправильно понял задачу: а <a href="http://en.wikip |
Может я неправильно понял задачу: а radix sort тут не поможет? |
<b>Re: простите,</b><br/> А если эти байты равны? |
Re: простите, |
Потому что это byte order, а не численный. Байты в лонгах-и |
Потому что это byte order, а не численный. Байты в лонгах-интах идут не подряд и порядок (результат) сортировки для двух способов сравнения получается разный. |
<b>простите,</b><br/> не догоняю, почему вместо if(a!=b) ret |
простите, |
Пардон, писал не проверив. Библиотечный memcmp в FreeBSD леж |
Пардон, писал не проверив. И скорее всего на длинных сравнениях он выиграет, как только цена call станет невидной. Но у меня то 8 байт. |
FreeBSD 6.4 x64 Но вы привели библиотечный memcmp, а естест |
FreeBSD 6.4 x64 Но вы привели библиотечный memcmp, а естественно gcc будет ставить builtin. В исходних ассемблерный не смотрел, но говорят там repe cmpsb (сужу по выдаче гугла) Ну а дальше оказывается, например, что loop unrolling при нонешней глубине конвейера - полезен. |
А в какой операционке ? Во FreeBSD memcmp выглядит так: do { |
А в какой операционке ? Во FreeBSD memcmp выглядит так: |
Жизнь коротка. Вот эта хрень, которая выше - это ускорение д |
Жизнь коротка. Вот эта хрень, которая выше - это ускорение двое за 5 минут, размялся и приятно. |
А в чём вопрос для такого специфического момента ручками зак |
А в чём вопрос для такого специфического момента ручками закодировать qsort? |
прости за дельтанский вопрос а не будет ли быстрее сравниват |
прости за дельтанский вопрос а не будет ли быстрее сравнивать два лонга (или четыре инта)? тоесть за сколько тактов они сравниваются на ассемблер современных процов |
Да, и конверсия просто буфера в вектор - это вдвое по памяти |
Да, и конверсия просто буфера в вектор - это вдвое по памяти, а читать кусочками - тоже никакой радости. |
В-общем, в рафинированом случае с 18млн ключей без данных - |
В-общем, в рафинированом случае с 18млн ключей без данных - std::sort быстрее на numeric раза в полтора. Но копирование - довольно существенная часть и в реальном случае, когда на 20 байт данных 8 байт ключа - примерно один хрен. |
У меня восьмерки нигде нет, естественно (зачем она, если ест |
У меня восьмерки нигде нет, естественно (зачем она, если есть 8.3) Но вот упоминание о данном синтаксисе в доке на 8.0.7 |
Мне кажется, что в этом патче нужно добавить проверку на вер |
Мне кажется, что в этом патче нужно добавить проверку на версию сервера, так как в документации упоминание префикса начинается с 8.1 версии. Посему, прошу уточнить, как оно поведет себя на 8.0 например. Проверить нет возможности... в 8.0 не нашел (http://www.postgresql.org/docs/8.0/static/sql-syntax.html#SQL-SYNTAX-STR...) первое найденное упоминание |
Гы, а никак по-нормальному :) |
Гы, а никак по-нормальному :) |
А кстати, как в std:vector сделать read() ? |
А кстати, как в std:vector сделать read() ? |
Byte order, а не numeric. С числовым порядком все несколько |
Byte order, а не numeric. С числовым порядком все несколько проще. |
Но вообще, многие сравнивают разбор RAW с печатью, а не толь |
Но вообще, многие сравнивают разбор RAW с печатью, а не только проявкой ;-) |
Идея ясна. Но она никак не противоречит второму описанному м |
Идея ясна. Но она никак не противоречит второму описанному мной подходу. |
qsort из libc ? А если std::sort и чтобы operator < у сра |
qsort из libc ? А если std::sort и чтобы operator < у сравниваемых элементов инлайнился ? |
Мешает эргономика просесса. ДопустимЮ у Вас есть 2 дубля, и |
Мешает эргономика просесса. ДопустимЮ у Вас есть 2 дубля, и надо выбрать, какой из них пойдёт в работу. Проявил оба, сравнил, выбрал, начал дорабатывать выбранный. Идея просветного стола, контролек, index print - она правильная. При конвертации raw совершается очень ограниченное количество управляемых оператором действий, и эти действия, как и в случае плёночной проявки, мало зависят от сюжета, условий освещения, и т.п. При съёмке на цифру, как и в плёночном процессе, важно лишь попасть в широту материала (а она определяется камерой и выбранным конвертором - так же, как и раньше она определялась плёнкой и проявкой). Надо снимать чисто, и не поддаваться соблазнам петлять в конверторе, бесконечно варьируя парой-тройкой параметров, которые реально влиюят на конверсию. Если конвертор raw на выходе имеет битмэп в представлении с плавающей точкой и дальнейшая обработка в редакторе ведётся с незначительными потерями точности - возвращаться к конвертору и менять параметры конвертации практически не приходится. С другой стороны, действия, выполняемые в качественном конверторе behind the scenes, очень сложно выполнить в реальном времени. При росте производительности вычислительной системы сразу же оказывается, что мы придумали, как реализовать новые, улучшенные алгоритмы и как добавить ещё буквально пару действий для снижения шума и аберраций - и опять оказываемся в положении, когда интерактива нет. Сочетание неинтерактивного конвертора с интерактивным редактором оказывается странным и маложизнеспособным гибридом. Главная задача конвертора не в том, чтобы из него напрямую можно было печатать (куда печатать? - я файлы для разных принтеров и разных форматов печати по-разному готовлю), а в том, чтобы обеспечить максимально качественный материал для дальнейшей цветокоррекции. |
В смысле, я к тому что это все 5-минутное развлечение, давше |
В смысле, я к тому что это все 5-минутное развлечение, давшее неожиданный результат (начал я с того, что переполнил int в numeric sort и у меня количество уникальных ключей не расходилось в маленьких тестах, но расходилось на миллионах - тоже, обычные такие грабли, но не каждый день бываают) |
У меня оно во входном файле лежит вместе (записями фиксирова |
У меня оно во входном файле лежит вместе (записями фиксированной длины). Ну и конечно не hot spot - тестовый файл порождается 3 минуты, сортируется 3 секунды, а вот в индексированный вид (BTree) сейчас пишется 3 часа (ну а моя задача писать в Btree еще за несколько минут, хотя не уверен в возможности, экспериментирую) |
ну тогда можно отсортировать сначала индекс, а потом по нему |
ну тогда можно отсортировать сначала индекс, а потом по нему реальный массив. ещё вместо std::vector можно использовать просто динамические массивы (вроде в boost есть). |
Да, в рафинированном (только ключи) случае std::sort(vector. |
Да, в рафинированном (только ключи) случае std::sort(vector...) быстрее. Если ключи с данными (данных - больше), то время на копирование съедает выигрыш. |
1. стандартная сортировка C++ (с функтором) может быть быстр |
1. стандартная сортировка C++ (с функтором) может быть быстрее qsort() из C. |
Кстати, ты LightZone видел? ОЧень там симпатичные идеи есть. |
Кстати, ты LightZone видел? ОЧень там симпатичные идеи есть. Особенно ZoneTool вместо кривых иногда крайне удобен. |