Этот пост - "разбор полетов" прошлогоднего конкурса Intel - Acceler8 2011, выполненный одним из членов жюри. Он прокомментировал ключевые конкурсные моменты, а также дал банальные и очевидные, но до сих пор актуальные советы по участию в подобных соревнованиях и по ведению проектов.

Итак, поехали!

Первое, с чем столкнулись организаторы — это искренний интерес участников, живое общение в блогах и форумах. Скажу честно, решения участников, которые много «наследили» в форуме, мы рассматривали с особым пристрастием. У каждого члена жюри были свои любимчики, но на конечный результат соревнования это никак не повлияло, так как у тестовой машины не было предпочтений.

Задача конкурса

Ох, каких только нелестных эпитетов выслушали организаторы конкурса по поводу поставленной задачи. Методом проб и ошибок она была приведена к более-менее приемлемому виду. Но после получения первых решений, мы осознали насколько она была богата на различные оптимизации. Основной упор участники (ожидаемо) сделали на вычисление «периодических» матриц и параллелизацию. Но некоторые конкурсанты также сделали теоретические исследования алгоритма, оптимизации выделения памяти и хранения матриц, их заполнения, способов их обхода. В глазах жюри конкурса такой подход к решению задачи прибавлял минимум +100 к карме участника.

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

Качество кода

Тут организаторы конкурса прочувствовали истинность народной китайской поговорки «не важно какого цвета кошка, если она ловит мышей». Каких только витиеватых конструкций и выражений не было в коде. Организаторы вспомнили свою юность, когда писали почти так же. Приведу TOP-5 «неловких» мест в проектах:

5 место (хитрая инициализация указателя в конструкторе): m_memory_pointer((char*)this + 1024)
4 место (инициализация переменной): static const int min_int = -2147483648;
3 место: сравнение структуры с указателем. Как это вообще скомпилировалось под Linux?
2 место: main.c файл на 1900 строк. Парни, серьёзно, как вы в нём ориентируетесь?
1 место (почти десяток претендентов): несоблюдение формата ввода-вывода.

Иногда мозг просто взрывался, пытаясь понять, что имели ввиду участники. Отсутствие комментариев только усугубляло общую картину (хотя вру, в паре файлов код терялся среди комментариев). Но что самое поразительное - иногда эти сложные нечитаемые конструкции работали, работали правильно, работали быстрее всех.

Проблема, с которой могут столкнуться разработчики, если будут писать проекты в таком стиле, — это поддержка и сопровождение кода. Порой, проекты длятся годами, и если в момент завершения проекта разработчики помнят, что они написали, то уже через месяц могут и не разобрать. На наш взгляд, основной причиной невысокого качества кода стала нехватка времени. И даже после того, как организаторы продлили временные рамки конкурса. Рискну предположить, что почти все участники сидели безвылазно за своими компами в выходные перед завершением конкурса.

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

Качество алгоритмов

Признаюсь, моим фаворитом в прошедшем конкурсе была команда KomsomolskDV. Чувствуется, что парни имеют достаточно богатый опыт участия в подобных соревнованиях. Они подошли к исследованию алгоритма до такой степени педантично, что даже вычислили теоретическое время работы алгоритма в тактах. Если бы все участники провели подобные исследования, то нам бы не пришлось запускать приложения. Достаточно бы было сравнить теоретические времена вычислений.
Также некоторые участники описали в своих сопроводительных документах ход их мыслей, с чего они начинали, как развивалась их мысль.
Если представить ход мыслей участников в виде графика (хм, интересно, возможен ли такой график?), то до каких-то базовых улучшений додумались почти все участники. С ростом хитрости и сложности какой-то идеи количество справившихся участников резко падало.

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

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

В заключение хочу сказать, что участники конкурса доставили много весёлых минут организаторам.
Почти совет: Относитесь к программированию, как серьёзной игре. С одной стороны, всё должно работать, с другой — процесс разработки должен приносить радость.

Например, почему бы не оставить в комментариях «послание» будущим поколениям?

cross-post from habrahabr.ru

1988 год – H.261

Итак, 1988 год. H.261 стал первым полноценным форматом видеосжатия, получившим широкое распространение. Это был «классический» стандарт, работающий в цветовом пространстве YCbCr, базирующийся на дискретном косинусном преобразовании блоков и сжатии Хаффмана. Поднимите руку те, кто слышал о нём? А ведь именно в этом стандарте впервые появились такие понятия, как макро-блок, целопиксельный вектор движения и де-блокинг (или пост-процессинг). А еще именно тогда, 23 года назад, появилась концепция опорных кадров. H.261 предусматривал кадры 2х типов: I(ntra) – полностью независмый кадр, и P(redicted) – кадр, зависимый от предыдущего. Максимальное разрешение CIF (пример приведён слева), поддерживаемое H.261, сейчас не впечатлит даже любителей смотреть видео на телефоне. И тем не менее, для своего времени это был очень прогрессивный, весьма «продвинутый» стандарт. Все последующие стандарты видеосжатия базируются на идеях, берущих свое начало в H.261, и де-факто являются результатом его эволюционного развития.

1993 год – MPEG1

В 1993 появился MPEG1. Революционным нововведением в формате MPEG1 стали B(ipredicted) кадры. Т.е. кадры могли теперь предсказываться не только от предшествующего опорного кадра, но и последующего. Появились полупиксельные вектора движения, что позволило поднять точность предсказания и тем самым повысить качество. Было введено понятие «слайс» (Slice) – часть кадра (группа макроблоков), которая кодируется независимо от других слайсов. Стало возможным сжимать разные части кадра с разными параметрами, но, самое главное, в MPEG1 появилась поддержка очень больших разрешений, вплоть до 4К на 4К.
По непонятной причине, комитет MPEG выкинул из стандарта этап де-блокинга. Комитет даже не убедило существенное повышение качества, достигнутое при использовании де-блокинга в стандарте H.261. Скорее всего, решение было основано на данных о типичной производительности микропроцессоров того времени. В отличие от H.261, стандарт MPEG1 состоял из нескольких частей, описывающих всё необходимое для полноценного цифрового видео: аудио сжатие, видео сжатие, хранение и синхронизация аудио-видео данных, средства тестирования совместимости и референсный декодер для отладки.

В начале девяностых годов в компании Intel, да и вообще в компьютерной индустрии, вряд ли существовало полное понимание того, какое влияние в будущем окажет видеокодирование на архитектуру процессоров. Это много позже сжатие и разжатие цифрового видео стало коньком компании. А пока, в марте 1993, начал свою долгую жизнь один из самых известных процессоров компании Intel – Pentium. В нем не было ничего особенного для ускорения видео-обработки, разве что одинокая инструкция bsr (bit scan reverse). Эта инструкция осталась еще со времён 386го процессора и могла быть использована для ускорения декодирования Хаффмана. Производительности Pentium’а хватало, чтобы тихонько декодировать H261 формат. Но без звука . Надеюсь, некоторые читатели еще помнят, как икал winamp, если пошевелить мышкой.

1996 год – MPEG2

1996 год. Опубликован стандарт MPEG2. Совсем скоро разойдутся по планете миллионными тиражами DVD диски, которые сделают MPEG2 первым широко распространенным форматом на многие годы. MPEG2 практически не принёс ничего нового в процесс сжатия, за исключением черезстрочного видео, поддержки нескольких форматов аудио-сжатия и дополнительных цветовых разрешений. MPEG2 не был оптимизирован для использования на маленьких (меньше 1мбит) потоках. Зато на бОльших потоках MPEG2 уверенно превосходил MPEG1, а сам стандарт разросся до 11 частей.

В начале 1997 года Intel начала продавать процессоры, которые уже были способны декодировать видео с приемлемой скорость. Нет, про HDTV разрешения ещё никто не мечтал, но маленькое QCIF видео процессор уже способен был проигрывать без тормозов. «Виновница» этого – технология MMX. Врядли выход стандарта MPEG2 и технологии MMX с такой маленькой разницей во времени было чистым совпадением. С большой вероятность это был, как сейчас принято говорить, продукт синэргии.

Технология MMX состояла из набора дополнительных 57 инструкций и 8 новых 8ми-байтных регистров. Существенное ускорение (до 3х-4х раз) достигалось за счёт одновременной обработки инструкцией нескольких данных. В этом плане цифровое видео стало идеальным полем для внедрения новой технологии. На MMX возлагали большие надежды, и даже поместили на официальное лого процессора.
Чуть позже в этом же году вышел процессор Pentium II, который за счёт своей суперскалярности, большого кэша, шустрой шины и нового типа памяти сделал доступным просмотр DVD на персональном компьютере.

1998 год – MPEG4

MPEG4, появившийся в 1998 году, достаточно быстро завоевал себе славу «пиратского» формата. Кодек DivX, использующий MPEG4 формат, произвёл настоящий фурор. DivX позволял с приемлемой потерей качества сжимать MPEG2 DVD диск в файл размером с CD диск. Я помню, как многие мои друзья кинулись пережимать DVD фильмы (откуда они их брали???) и делать свою личную коллекцию DivX фильмов.
Успех формата MPEG4 состоял из нескольких слагаемых: вектора движения стали четверть-пиксельными, что позволило поднять точность предсказания, макроблок мог содержать уже до 4 векторов движения, что было полезно на границе движущихся объектов, и (фанфары!) вернулся незаслуженно уволенный пять лет назад де-блокинг.
Разработчики стандарта добавили в MPEG4 ещё одну интересную вещь: intra-предсказание. Теперь макроблоки в I-кадрах могли «предсказываться» от соседних макроблоков, что существенно снижало размер intra макроблоков в кадрах со сложной, но повторяющейся структурой.
К сожалению, сам стандарт сжатия, а вернее его чрезмерные способности, не нашли горячего отклика в лице производителей кодеков. Многие прогрессивные фишки MPEG4, такие как 3D видео текстуры, несколько видеоплоскостей в кадре и прочее, остались невостребованными.

С другой стороны, многократно возросшая сложность декодирования опять отбросила пользователей в область маленьких разрешений. Однако, не прошло и года, как в продаже появился Pentium III, «ускоряющий Интернет». К слову, Pentium III отлично справлялся с задачами ускорения всего, не только интернета. В то время были популярными эксперименты запуска игры Quake 3 Arena на новом процессоре, который после патча системы обеспечивал значительное приращение FPS. С точки зрения видеокодирования, процессор принёс возможности программного опережающего чтения (prefetch) данных в кэш и расширял набор MMX несколькими крайне полезными инструкциями. И хотя ускорение декодирования видео было всего 20-30% по сравнению с Pentium II, этого было достаточно для комфортного просмотра MPEG4 фильмов.

Приверженцы продукции Intel встречали 2000й год с особыми нетерпением. Именно на этот год был назначен выпуск нового процессора Intel Pentium 4. Это была великая интрига и великая загадка – компания готовилась полностью сменить архитектуру процессора. Архитектура NetBurst шла на смену казавшейся устаревшей архитектуры P6. И хотя общая производительность процессора слегка разочаровала фанатов, с точки зрения обработки цифрового видео процессор был на высоте. Новые инструкции и новые 16ти-байтные регистры SSE2, хитрые режимы аппаратного предсказания, большие буффера чтения/записи, новая организация кэша, а чуть позже – технология HyperThreading. Всё это вдохнуло новую жизнь в процесс оптимизации видеокодеков. Прирост производительности колебался от 10 до 35%. Процессор Pentium 4 был раздольем для экспериментов. Например, 2 инструкции, переставленные местами, могли равновероятно принести как 5% увеличения скорости работы кодека, так и 5% замедления. Процессора вполне хватало на декодирование и видео, и аудио, и еще оставалось немножко производительности на спец-эффекты. Вкладка эффектов DivX росла и ширилась, и счастливые обладатели топовых версий Pentium 4 расставляли все галочки, в надежде получить картинку «как в кинотеатре». А раз уж речь зашла о кинотеатре, то энтузиасты начали всерьез посматривать в сторону HD разрешений.

Новейшая история, год 2003 – H.264

Год 2003 можно смело назвать эпохальным годом в истории развития форматов видеосжатия: появилась альфа и омега сегодняшнего цифрового видео — стандарт H.264. Новый стандарт был полностью целочисленным, т.е. все этапы декодирования видео выполнялись в целых числах, благодаря чему была достигнута побитовая идентичность видео при декодировании декодерами разных производителей.
От предков H.264й отличался продвинутым intra-предсказанием макроблоков, различным разбиением макроблоков при компенсации движения (от 4x4 до 16x16), 6ти точечным фильтром компенсации движения, продвинутым арифметическим сжатием энтропии, наличием долго-хранящихся опорных кадров, гибким управлением опорными кадрами, 16 векторами на макроблок, всеми доступными цветовыми разрешениями, 8мью и более битами на компонент цвета и множеством других волшебных фишек. Стандарт не только оставил далеко позади всех конкурентов, но и установил новые требования к производительности процессора. Теперь, чтобы проигрывать видео в формате HD, одного процессора (даже с технологией HyperThreading) уже недостаточно.

Период 2003-2005 годов был тяжёлым для пользователей, которым не хватало производительности, но золотым временем для оптимизаторов ПО. Их услуги были на расхват! Производительность ЦПУ явно была в дефиците, и с этим надо было что-то делать. В мае 2005 решение пришло – впервые со времён процессора Pentium III многоядерность вернулась в пользовательские машины. Процессор Pentium 4 с кодовым названием Smithfield гордо нёс свои 2 ядра в массы. На самом деле, компания Intel слукавила – это были 2 «почти» обычных процессора Pentium 4, расположенные на одной подложке. Процессоры могли общаться друг с другом исключительно через шину FSB, не могли «подглядывать» соседу в кэш. Тем не менее, производительности Smithfield’а было достаточно, чтобы на лицах пользователей снова засветилась улыбка. Покупайте попкорн, занимайте места в «зрительном» зале. Только благодаря многоядерности в многолетней битве между процессорами и форматами цифрового видео наметился перелом: процессоры стали способны декодировать цифровое видео в любом формате, в любом разрешении с комфортной для зрителя скоростью. Но это был лишь выигранный бой, но не сражение.
Как мы знаем, цифровое видео можно (и нужно) не только ДЕкодировать, но и в первую очередь кодировать. А вот с этим всё было не так радужно, как того бы хотелось. Для полноценного, быстрого и качественного сжатия видео современных процессоров хватало разве что на стандартное разрешение формата MPEG2/MPEG4, не более.

Городок Конро на юго-востоке штата Техас был практически неизвестен до лета 2006 года, когда на прилавках магазинов стали поставляться новые процессоры компании Intel с одноимённым ядром, вернее ядрами. Дальний потомок процессора Pentium III Intel Core 2 был призван заменить процессоры на базе технологии NetBurst, и закрепить успехи видео(де)кодирования. Процессор обладал полноценными высокопроизводительными ядрами, которые могли достаточно эффективно лазить друг другу в большой кэш, и новыми инструкциями SSSE3 (3 буквы S). Среди новых инструкций было несколько ориентированных специально на кодирование видео. И хотя новые процессоры потеряли поддержку HyperThreading, они всё равно обладали такой внушительной производительностью, что сжатие HD видео в реальном времени уже не выглядело совсем непосильной задачей.

Однако, как уже было замечено, появление многоядерности принесло победу в бою, но не в сражении. Осенью 2007 года объединённая группа комитетов наносит ответный удар в виде нового профиля масштабируемого сжатия к стандарту H264 Scalable Video Coding (SVC). Сложность кодирования и декодирования возрастает в разы. Это был не полноценный стандарт, а всего лишь настройка над существующим, основная задумка которого – существенное повышение качества видео, передаваемого по сетям с потерями. Теперь в видео потоке один и тот же фильм мог храниться в разных разрешениях, и более высокие разрешения использовали более низкие в качестве опорных. У такого решения был ещё один дополнительный плюс: теперь устройства, которые не нуждалось в HD качестве фильма, могли декодировать только часть потока с необходимым разрешением.

Но ничто уже не могло поменять ситуацию в обратную сторону. Компания Intel в начале 2008 закрепляет свой успех выходом процессора на ядре Penryn с новыми инструкциями SSE4.1. Как скажут позже – это было самое большое SIMD расширение со времён процессора Pentium III. Тут были и абсолютно новые инструкции, заточенные на кодирование цифрового видео, и новые расширения для уже существующих SIMD инструкций. Кодирование HD видео в формате H264 уже уверенно движется в реальном времени с приемлемым качеством.
Вышедший в ноябре 2009 новый профиль для кодирования видео снятого с нескольких точек для формата H264 Miltiview video coding (MVC) не мог ничего изменить. Новый профиль не добавлял ничего нового, просто описывал правила и способы организации битового потока для сжатия видео снятого с нескольких камер. Не смотря на то, что производительности процессоров 2009 года не хватало, чтобы сжимать подобное видео в реальном времени, это был вопрос одного, максимум двух поколений процессоров.

Так и произошло. На рынок вышел процессор с кодовым именем Nehalem, снова подаривший нам радость использования технологии HyperThreading. Среди прочих достоинств процессор нёс на себе контроллер памяти и кольцевую шину, которая более подходила для связи между большим количеством быстрых ядер, чем морально-устаревшая FSB. Процесс сжатия HD фильма в отличном качестве, который раньше занимал всю ночь, теперь пролетает за «считанные» часы. В воздухе витал дух победы. Однако, компания Intel была бы не компания Intel, если бы не поставила красивый заключительный аккорд в этой борьбе.

И он прозвучал: в январе 2011 было объявлено о начале продаж процессора на ядре SandyBridge. Кто вертел фирменную синюю коробочку упаковки процессора, наверняка заметили слова Intel Quick Sync среди списка features процессора. Именно так называется технология аппаратного сжатия видео, которая доступна каждому пользователю через Intel media SDK. За этими тремя простыми английскими словами скрывается труд десятков инженеров и программистов компании, в том числе и мой.

В 2002 году я разговаривал с одним своим коллегой насчёт оптимизации и мультимедиа-ориентированности современных процессоров (как вы помните, время господства технологии SSE2). И на какой-то мой довод коллега ответил, что процессоры станут мультимедиа-ориентированными только тогда, когда там появится инструкция idct. Могли ли мы предположить в далёком 2002, что спустя всего 9 лет жизнь оправдает гораздо более смелые планы и ожидания?

Теперь сжатие видео для любимого iPad – не проблема. HD сериал из 24 серий по 20 минут кодируется за 20 минут. Фильм на 1.5 часа кодируется за 5 минут. Больше не надо тратить своё время и оставлять компьютер включенным на ночь. Достаточно просто сходить и налить чай. Процессоры победили.

PS: На этом я хотел бы закончить своё повествование, но это было бы лукавством. В воздухе опять пахнет бурей. Дело в том, что объединенная группа комитетов разрабатывает следующий стандарт сжатия цифрового видео – High Efficiency Video Coding (HEVC). HEVC будет нести в себе лучшие качества H264 формата, но при этом будет обладать огромным количеством новых особенностей и возможностей, которые предъявят повышенные требования к ЦПУ. И борьба между стандартами видеосжатия и процессорами может выйти на новый виток. И так до бесконечности.

Upd. Я уверен, что со временем программные средства развивались, и некоторые негативные эффекты, описанные в статье, со временем прошли. Например, winamp перестал «икать» на медленных процессорах.

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

Когда нам поставили задачу эффективно использовать 2 ядра, декодер содержал только последовательный код. Чтобы сделать декодер многопоточным предстояло полностью переписать его внутреннее устройсто.
Мы пошли по пути наименьшего сопротивления. Т.к. процесс декодирования видео стандарта H264 состоит из нескольких независимых этапов, самого декодирования и процесса исправление ошибок квантизации - «деблокинга», первое решение было сделать так, чтобы эти этапы выполнялись в разных потоках. От нас практически не потребовалось вносить в декодер какие-либо значительные изменения. Этот способ параллелизации дал декодеру существенное ускорение при использовании второго процессора, однако до заветных 2х было ещё далеко. К тому же, нагрузка на ядра процессора, при использовании этого способа параллелизации, сильно зависела от настроек кодирования видеопотока, использования особенностей стандарта и варьировалась в широких пределах.

Следующий шаг, который был нами предпринят, - параллелизация по слайсам (анг. slice). Слайс – часть сжатого кадра, которая не зависит от остальных слайсов (частей) этого кадра. Это были идеальные предпосылки для внедрения параллелизации. И хотя внутренняя структура декодера была переработана более существенным образом, чем в первом случае, параллелизация по слайсам принесла более впечатляющие результаты. Теперь декодер демонстрировал почти двукратное прибавление в производительности при использовании второго рабочего потока, по сравнению с однопоточной версией. Впрочем, этот способ имел один очень существенный недостаток: не все видеопотоки содержат кадры, состоящие из нескольких слайсов. Соответственно, параллелизация по слайсам была абсолютно бесполезна при декодировании видеопотоков, которые состоят из кадров содержащих только один слайс.

На следующем этапе параллелизации нам пришлось провести декомпозицию процесса декодирования по данным. Это потребовало практически полной переписки декодера, но мы рассчитывали получить впечатляющие результаты. Теперь рабочий поток получал для обработки не целиком слайс, а только одну строчку макроблоков из него. К тому же, поток выполнял не полное декодирование переданной ему строчки, а только часть: декомпрессию данных макроблоков или реконструирование макроблоков, используя ранее декомпрессированые данные. Данные макроблоков декомпрессировались в специальные временные буфера, откуда позже использовались для реконструирования. Процесс деблокинга также был подвергнут процессу декомпозиции по данным. Теперь оба рабочих потока могли выбирать на исполнение любую их 3х задач (декомпрессию, реконструкцию, деблокинг), в зависимости от текущей стадии декодирования кадра. И хотя этот способ оказался непременим при декодировании некоторых видеопотоков, сжатых с использованием особенности slice group стандарта H264, в целом он продемонстрировал отличную производительность. Теперь декодер легко показывал двукратное ускорение при декодировании любых видеопотоков.

На самом деле, я немного слукавил, описывая первые три этапа параллелизации, когда говорил «любые видеопотоки». Я имел ввиду потоки большого разрешения. Больше, чем стандартное телевизионное (SD, 720x576) разрешение. Когда мы попытались протестировать декодер на видеопотоках с маленьким разрешением, мы наткнулись на неприятный сюрприз: не было никаких признаков двукратного роста производительности при использовании второго потока. Максимум, что показывал декодер – было 30ти процентное ускорение, что было полностью неприемлимо для нас. Дальнейшее расследование выявило несколько проблем, которые полностью отсутствовали при декодировании видеопотоков с большим (HD, 1920x1080, 1280x720) разрешением. Решение этих проблем стало залогом к блестяще работающей параллелизации.
Сначала мы избавились от лишних обновлений кэша ядер процессоров. Дело в том, что выполняя реконструирование макроблоков, рабочие потоки использовали временные буфера для хранения промежуточных данных, что вызывало лишние принудительные обновления кэша у второго ядра. Мы переписали функции, выполняющие реконструирование, чтобы они не «портили» данные во временном буфере, а использовали стэк для хранения промежуточных данных. Принудительные обновления кэша ядер исчезли, что положительно сказалось на общей производительности, но конечная скорость работы декодера по-прежнему была неприемлима.

Оказалось, что виновницей низкой производительности декодера была не вполне корректная схема параллелизации. Мы использовали схему, когда синхронизация главного и дополнительного потоков осуществлялась на каждый вызов метода декодера для декодирования очередного кадра (DoDecode). Среди параметров к вызову DoDecode был указатель на сжатый кадр, который «регистрировался» главным потоком внутри декодера. После этого главный поток подавал сигнал внутреннему потоку, что «можно начинать работать», выполнял свою часть декодирования кадра и ждал, пока внутренний поток выполнит свою часть работы, выставит сигнал «внутренний поток закончил свою часть работы» и «заснёт», после чего главный поток выходил из метода DoDecode, возвращая разжатый кадр вызывающему приложению.

Первоначальная схема синхронизации

Конечная схема синхронизации

Зависимая декомпрессия опорных кадров