Re: [devel] libjpeg7 - пора?

[Alexander Bokovoy <ab@altlinux.org>]

Hi,

2010/7/5 Victor Forsiuk <force@altlinux.org>
>
>
> 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 и такие джипеги просто не сможет декодировать.
>
> В чем плюс арифметического кодирования для пользователя - он создает файлы меньшего размера. Заметно меньшего. На мой взгляд, это с лихвой перевешивает некоторое отставание в скорости новых алгоритмов. В реальной жизни мы получим более быстрое открытие файлов - уменьшение времени считывания с диска с лихвой перекрывает чуть более медленное декодирование. Про загрузку по сети я уж вообще молчу...
>
Основная проблема с libjpeg7 -- состояние разработки в апстриме.
Фактически, имеющаяся модель разработки (периодически выкладываем срез
внутреннего состояния без доступной истории и внятного роадмапа,
отсутствие внятной дискуссии между пользователями и разработчиками,
отсутствие оптимизаций для современных процессоров, ...) привела к
тому, что существует по меньшей мере 4-5 форков libjpeg, реализующих
оптимизации кода для разных архитектур. Jpeg-turbo, например,
базируется на коде от японца Миясаки Масару, который сам не принимает
участие в разработке jpeg-turbo. На его коде построены и оптимизации
для ARM NEON в N900 руками Сергея Семашко. Есть также оптимизации от
Интела, Квалкома (они недавно вошли в Андроид) и ряда других компаний.

Редхат, руками Адама Ткаца, занялся jpeg-turbo. Создатели libjpeg в
рамках v8 (v8b вышел 16 мая 2010) активно эксплуатируют тему
масштабирования при декодировании, что с математической стороны сильно
ускоряет загрузку уменьшенных версий изображений, но очень плохо
укладывается на модель обработки данных на SIMD-архитектурах. В
результате, v8 проигрывает по скорости всему, перечисленному в
предыдущем абзаце до 15% -- при том, что в среднем проигрыш предыдущей
версии был в два-три раза. Но математический перфекционизм авторов
оригинального libjpeg в данном случае слабо коррелирует с реальностью
процессоров, на которых их код должен исполняться: многочисленные
ветвления, позволяющие сэкономить вычисления, приводят в реальности к
проигрышам из-за провала предсказания переходов. Порой просто лучше
масштабно пройтись "квадратно-гнездовым", чем терять десятки циклов на
провалах предсказаний. Например, в NEON можно загрузить за один раз
весь блок 8х8 и обработать его iDCT/DCT без обращения к памяти, не
теряя время.

Главный вопрос, который сейчас стоит -- это кто же будет на самом деле
апстримом для свободной реализации libjpeg? оригинальный, но не
работающий в том направлении, которое нужно реальным потребителям,
libjpeg v8 или TigerVNC, для которого jpeg-turbo пусть и необходимый,
но все же побочный продукт?


--
/ Alexander Bokovoy