<br><br><div class="gmail_quote">2010/5/8 Денис Смирнов <span dir="ltr"><<a href="mailto:mithraen@altlinux.ru" target="_blank">mithraen@altlinux.ru</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Sun, Aug 23, 2009 at 09:53:13PM +0300, Alexander Bokovoy wrote:<br>
<br>
Прошел почти год. Так что у нас будет с libjpeg? :)<br></blockquote><div><br>Нового libjpeg у нас в обозримом будущем не будет. Это очевидно чуть более чем полностью.<br><br>В свете же выпуска LTS релизов остается только очень сильно надеятся на то, что в ближайшие годы мейнстримные дистрибутивы будут раскачиваться и окончательно переключатся на новую libjpeg не так скоро. И, соответственно, до наступления end-of-life нашего LTS дистра арифметическое кодирование не станет массовым.<br>
<br>Напомню, libjpeg-6b не умеет arithmetic coding и такие джипеги просто не сможет декодировать.<br><br>В чем плюс арифметического кодирования для пользователя - он создает файлы меньшего размера. Заметно меньшего. На мой взгляд, это с лихвой перевешивает некоторое отставание в скорости новых алгоритмов. В реальной жизни мы получим более быстрое открытие файлов - уменьшение времени считывания с диска с лихвой перекрывает чуть более медленное декодирование. Про загрузку по сети я уж вообще молчу...<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
AB> Поскольку я проводил исследование на работе по переходу на libjpeg7,<br>
AB> то поделюсь результатами.<br>
AB> 1. ABI иное. Нужна пересборка.<br>
AB> 2. API отличается в месте загрузки с одновременным масштабированием. В<br>
AB> jpeg7 можно указывать более широкий диапазон коэффициентов для<br>
AB> масштабирования и это "выбивает" некоторые приложения. В частности,<br>
AB> сломался gdk pixbuf jpeg loader так, что при определенных сочетаниях<br>
AB> исходного файла и запрашиваемого разрешения получается мусор вместо<br>
AB> картинки. Чинится однострочным патчем.<br>
AB> 3. Скорость новых оптимизированных DCT и iDCT на современных<br>
AB> процессорах уступает на 10-15% "неоптимизированным" вариантам из<br>
AB> jpeg6b. Серьезную роль в этой разнице играет организация предсказания<br>
AB> переходов и использование кэшей первого-второго уровней в современных<br>
AB> процессорах. Проигрыш одинаково заметен на x86 и ARM. Математические<br>
AB> оптимизации в jpeg7, направленные на уменьшение количества умножений,<br>
AB> оказываются невыгодными для современных процессорных архитектур,<br>
AB> особенно с использованием векторных инструкций -- массовые параллелизм<br>
AB> с умножениями обходится дешевле провалов по спекулятивному<br>
AB> предсказанию переходов.<br>
AB> 4. Оба варианта jpeg6b и jpeg7 проигрывают по скорости<br>
AB> SIMD-оптимизациям jpeg6b от скромных японцев. Оптимизированный вариант<br>
AB> в среднем в 2-3 раза быстрее jpeg6b. Все они на ARM проигрывают<br>
AB> специализированым кодекам и декодерам на DSP (jpeg6b -- в среднем в<br>
AB> 4-4.5 раза). Думаю, что аналогичный проигрыш и на Cell B.E. На<br>
AB> x86/x86_64 без использования GPU явно выгодно использовать<br>
AB> векторизацию, чем новые математически оптимальные алгоритмы. С GPU не<br>
AB> все очевидно, потому что синхронизацию памяти для CPU/GPU никто не<br>
AB> отменял.<br>
AB><br>
AB> --<br>
AB> / Alexander Bokovoy<br>
AB> _______________________________________________<br>
AB> Devel mailing list<br>
AB> <a href="mailto:Devel@lists.altlinux.org" target="_blank">Devel@lists.altlinux.org</a><br>
AB> <a href="https://lists.altlinux.org/mailman/listinfo/devel" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a><br>
<div><div></div><div>--<br>
С уважением, Денис<br>
<br>
<a href="http://mithraen.ru/" target="_blank">http://mithraen.ru/</a><br>
----------------------------------------------------------------------------<br>
</div></div><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkvkjl4ACgkQPuR8c4jhFKL51QCgvLITyqUu1axN+BhnVaZkvkAy<br>
to0AmQGQAK/872JCF8+JOQkyEVi/0+F4<br>
=E4j2<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.altlinux.org" target="_blank">Devel@lists.altlinux.org</a><br>
<a href="https://lists.altlinux.org/mailman/listinfo/devel" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a><br></blockquote></div><br>