Comments 16
Новый формат хорош не только тем, что он при среднем сжатии очень быстрый, но и тем, что не связан ни с какими лицензионными соглашениями/ограничениями.
Если не зажмут на этом вопросе, то почему бы и не быть новому формату?
Скорость енкодинга в большинстве случаев не очень важна. Скорость декодинга важнее. А вот здесь уже QOI не настолько быстрее. Хотя, грех жаловаться на 3 раза быстрее. ;)
Ну, короче, я прослежу за QOI.
> Скорость енкодинга в большинстве случаев не очень важна.
В большинстве случаев не важна, но всегда будут случаи, когда это узкое место. Например, в случае встроенной электроники и ограниченных ресурсов это критично.
Ну и всегда будут случаи, когда скорость копирования картинки незначительно быстрее скорости сжатия - это будет плюсом для проекта, например захват экрана для удалённого рабочего стола с минимальным оверхедом который работает даже на древнем селероне. Или в случае если графического ускорителя нет вообще, а поэтому сжимать картинки на лету - только CPU, который хорошо бы использовать для чего-то более полезного чем перекладывать пиксели.
Была же новость уже
Формат упаковки внутри png - это gzip , если gzip тупо заменить на lz4, можно тоже нехилый прирост скорости получить.
код еще может быть оптимизирован с учетом instruction-level параллелизма.
Еще например vr > -17 && vr < 16 && vg > -17 && vg < 16 &&нужно заменять на & для ускорения
а точно результат сравнения двух чисел будет содержать единицу в одном и том же месте? true - любое ненулевое значение и результат true && true и true & true в общем случае не совпадает же.
результат будет одинаков, но с & быстрее, потому что & - не ветвление, нету jmp в асм.
&& нужен чтобы отсечь дальнейшие проверки,
например obj.is_circle() && obj.get_radius() != 0 в таком случае get_radius не будет вызываться если объект не круг.
С числами лучше использовать & потому что нет множественных ветвлений и branch predictor не задействуется.
Можете сами проверить конечно же производительность.
Интересно, одни пишут что С для полного контроля над происходящим, а тут вы утверждаете, что компилятор сам сделает, что ему вздумается. Вы уж определитесь :))
&& - это жесткий уход в jmp, гарантирующий, что следующие проверки не вызовутся. && и & это серьезная разница в том какой код будет вызываться.
См мой коммент https://habr.com/ru/company/mvideo/news/t/592699/comments/#comment_23850159
конечно я допускаю что какой-нибудь навороченный компилятор на базе llvm оптимизаций может и поймет что числовые проверки можно провести без jmp для ускорения (что вряд ли, надо тестить), но библиотека позиционируется как низкоуровневая, а значит пользователи будут компилить на чем угодно для своих ембед-девайсов, так не лучше ли писать сразу оптимизированный код под самый тупой компилятор? =)
&& — это жесткий уход в jmp, гарантирующий, что следующие проверки не вызовутся. && и & это серьезная разница в том какой код будет вызываться
GCC умеет оптимизировать && в таких проверках диапазонов, как в процитированных выше:
godbolt.org/z/879cT7Pf6
И кстати переход не всегда зло. Предсказанный переход выгоднее, чем 3-4 арифметических инструкции.
твой пример не корректен. Компилятор оптимизировал результат функции исходя из данных сравнения.
Проверять надо исполняемый код, который следует после сравнения.
https://godbolt.org/z/cdW5d3fnr
4 проверки - 4 джампа. Если заменить на & то 2 джампа, хотя должен быть 1.
С & и -O0 - 1 джамп.
Предсказанный переход выгоднее, чем 3-4 арифметических инструкции.
нет, арифметика выполняется в любом случае как бы забегая вперед, и предсказанный перхеод позволяет сразу выбрать нужный результат из веток результатов, которые выполнились параллельно. Больше веток - больше нагрузки.
Главное — скорость. Новый графический формат QOI в 20−50 раз быстрее PNG