<br><br><div class="gmail_quote">2009/8/23 Alexander Bokovoy <span dir="ltr"><<a href="mailto:ab@altlinux.org">ab@altlinux.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/8/23 Victor Forsyuk <<a href="mailto:force@altlinux.org">force@altlinux.org</a>>:<br>
<div class="im">><br>
> <a href="http://trac.imagemagick.org/browser/jpeg/trunk/change.log" target="_blank">http://trac.imagemagick.org/browser/jpeg/trunk/change.log</a><br>
><br>
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение<br>
> уже сейчас...<br>
</div>Поскольку я проводил исследование на работе по переходу на libjpeg7,<br>
то поделюсь результатами.<br>
1. ABI иное. Нужна пересборка.<br>
2. API отличается в месте загрузки с одновременным масштабированием. В<br>
jpeg7 можно указывать более широкий диапазон коэффициентов для<br>
масштабирования и это "выбивает" некоторые приложения. В частности,<br>
сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях<br>
исходного файла и запрашиваемого разрешения получается мусор вместо<br>
картинки. Чинится однострочным патчем.<br>
3. Скорость новых оптимизированных DCT и iDCT на современных<br>
процессорах уступает на 10-15% "неоптимизированным" вариантам из<br>
jpeg6b. Серьезную роль в этой разнице играет организация предсказания<br>
переходов и использование кэшей первого-второго уровней в современных<br>
процессорах. Проигрыш одинаково заметен на x86 и ARM. Математические<br>
оптимизации в jpeg7, направленные на уменьшение количества умножений,<br>
оказываются невыгодными для современных процессорных архитектур,<br>
особенно с использованием векторных инструкций -- массовые параллелизм<br>
с умножениями обходится дешевле провалов по спекулятивному<br>
предсказанию переходов.<br>
4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости<br>
SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант<br>
в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают<br>
специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в<br>
4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На<br>
x86/x86_64 без использования GPU явно выгодно использовать<br>
векторизацию, чем новые математически оптимальные алгоритмы. С GPU не<br>
все очевидно, потому что синхронизацию памяти для CPU/GPU никто не<br>
отменял.<br>
<br></blockquote></div><br>Однако идти в ногу с прогрессом нам придется, отсидеться в окопах с libjpeg6 не получится - из-за этой вот строчки в ченжлоге:<br><i>Support arithmetic entropy encoding and decoding.</i><br><br>
<br>