[devel] libjpeg7 - пора?

[Victor Forsiuk]

2010/5/8 Денис Смирнов <mithraen на altlinux.ru>

> On Sun, Aug 23, 2009 at 09:53:13PM +0300, Alexander Bokovoy wrote:
>
> Прошел почти год. Так что у нас будет с libjpeg? :)
>

Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более
чем полностью.

В свете же выпуска LTS релизов остается только очень сильно надеятся на то,
что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и
окончательно переключатся на новую libjpeg не так скоро. И, соответственно,
до наступления end-of-life нашего LTS дистра арифметическое кодирование не
станет массовым.

Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не
сможет декодировать.

В чем плюс арифметического кодирования для пользователя - он создает файлы
меньшего размера. Заметно меньшего. На мой взгляд, это с лихвой перевешивает
некоторое отставание в скорости новых алгоритмов. В реальной жизни мы
получим более быстрое открытие файлов - уменьшение времени считывания с
диска с лихвой перекрывает чуть более медленное декодирование. Про загрузку
по сети я уж вообще молчу...


>
>  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 на lists.altlinux.org
>  AB> https://lists.altlinux.org/mailman/listinfo/devel
> --
> С уважением, Денис
>
> http://mithraen.ru/
>
> ----------------------------------------------------------------------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkvkjl4ACgkQPuR8c4jhFKL51QCgvLITyqUu1axN+BhnVaZkvkAy
> to0AmQGQAK/872JCF8+JOQkyEVi/0+F4
> =E4j2
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20100705/5561486b/attachment.html>