[devel] libjpeg7 - пора?

[Alexander Bokovoy]

2009/8/23 Victor Forsyuk <force at altlinux.org>:
>
> http://trac.imagemagick.org/browser/jpeg/trunk/change.log
>
> Рано или поздно перейдем. Предлагаю задуматься о том, не начать ли движение
> уже сейчас...
Поскольку я проводил исследование на работе по переходу на libjpeg7,
то поделюсь результатами.
1. ABI иное. Нужна пересборка.
2. API отличается в месте загрузки с одновременным масштабированием. В
jpeg7 можно указывать более широкий диапазон коэффициентов для
масштабирования и это "выбивает" некоторые приложения. В частности,
сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях
исходного файла и запрашиваемого разрешения получается мусор вместо
картинки. Чинится однострочным патчем.
3. Скорость новых оптимизированных DCT и iDCT на современных
процессорах уступает на 10-15% "неоптимизированным" вариантам из
jpeg6b. Серьезную роль в этой разнице играет организация предсказания
переходов и использование кэшей первого-второго уровней в современных
процессорах. Проигрыш одинаково заметен на x86 и ARM.  Математические
оптимизации в jpeg7, направленные на уменьшение количества умножений,
оказываются невыгодными для современных процессорных архитектур,
особенно с использованием векторных инструкций -- массовые параллелизм
с умножениями обходится дешевле провалов по спекулятивному
предсказанию переходов.
4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости
SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант
в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают
специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в
4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На
x86/x86_64 без использования GPU явно выгодно использовать
векторизацию, чем новые математически оптимальные алгоритмы. С GPU не
все очевидно, потому что синхронизацию памяти для CPU/GPU никто не
отменял.

-- 
/ Alexander Bokovoy