[devel] libjpeg7 - пора?

[Денис Смирнов]

On Sun, Aug 23, 2009 at 09:53:13PM +0300, Alexander Bokovoy wrote:

Прошел почти год. Так что у нас будет с libjpeg? :)

 AB> Поскольку я проводил исследование на работе по переходу на libjpeg7,
 AB> то поделюсь результатами.
 AB> 1. ABI иное. Нужна пересборка.
 AB> 2. API отличается в месте загрузки с одновременным масштабированием. В
 AB> jpeg7 можно указывать более широкий диапазон коэффициентов для
 AB> масштабирования и это "выбивает" некоторые приложения. В частности,
 AB> сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях
 AB> исходного файла и запрашиваемого разрешения получается мусор вместо
 AB> картинки. Чинится однострочным патчем.
 AB> 3. Скорость новых оптимизированных DCT и iDCT на современных
 AB> процессорах уступает на 10-15% "неоптимизированным" вариантам из
 AB> jpeg6b. Серьезную роль в этой разнице играет организация предсказания
 AB> переходов и использование кэшей первого-второго уровней в современных
 AB> процессорах. Проигрыш одинаково заметен на x86 и ARM.  Математические
 AB> оптимизации в jpeg7, направленные на уменьшение количества умножений,
 AB> оказываются невыгодными для современных процессорных архитектур,
 AB> особенно с использованием векторных инструкций -- массовые параллелизм
 AB> с умножениями обходится дешевле провалов по спекулятивному
 AB> предсказанию переходов.
 AB> 4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости
 AB> SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант
 AB> в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают
 AB> специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в
 AB> 4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На
 AB> x86/x86_64 без использования GPU явно выгодно использовать
 AB> векторизацию, чем новые математически оптимальные алгоритмы. С GPU не
 AB> все очевидно, потому что синхронизацию памяти для CPU/GPU никто не
 AB> отменял.
 AB> 
 AB> -- 
 AB> / Alexander Bokovoy
 AB> _______________________________________________
 AB> Devel mailing list
 AB> Devel at lists.altlinux.org
 AB> https://lists.altlinux.org/mailman/listinfo/devel
-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20100508/6e930864/attachment.bin>