Re: Ряд более конкретных вопросов


Сайт о сжатии >> Форум #Компрессор# >> [Ответить] [Ответы]

Автор: Юрий,
01 февраля 2004 года в 05:14:21

В ответ на : Ряд более конкретных вопросов от ИмажКодер в 31 января 2004 года в 15:44:22:


Привет, Владимир, постараюсь ответить на твои вопросы.
Embedded означает «встроенный». Встроенные процессоры используются в различных устройствах, типа мобильных телефонов, DVD-плейеров и т.д. (В моем случае это граббер, или плата видеозахвата, вставляется в PCI-слот обычного PC.)
Довольно часто они (процессоры) как раз бывают достаточно «супер» - например, мы используем процессор Philips Trimedia 1300, c тактовой частотой всего 166 MHz, но по скорости вейвлет-преобразования он не уступает 1GHz Athlon.

> Потому как в статике реал-тайма нет.
> Быстродействие есть, но это ж не реал-тайм.
Мы сжимаем видео в реал-тайме с помощью вейвлетов. А статика – это частный случай видео - один кадр ;) понятно, что все намного сложней, но начинать нужно как раз со сжатия отдельного кадра.
> Мне лично кроме отдельных недостатков языка программирования (Си++ конечно,
> он все таки лидер ООП) не нравится вообще его структура.
Нет в этом мире совершенства ;)
> Так вот. Не возникает ли у тебя идея об немотивированном отсутствии
> классного языка программирования, на котором не надо было бы
> "экспериментировать", "обходить камни", "вставлять рудименты"
>и т.д, а просто программировать - быстро, красиво, читабельно и,
> главное, эффективно?
Проблема в том, что создать один язык на все типы задач нереально.
Лично мне импонирует C#, но я (пока) представить себе не могу, как на нем писать высокооптимизированный код :D Понятный и простой можно, сложный можно, но быстрый...
В настоящий момент даже универсальной процессорной архитектуры нет, и наверное, не будет – слишком много противоречивых требований, одним нужно «сырая» скорость работы с плавающей арифметикой, другим нужна низкое энергопотребление, etc.

Поэтому же, скажем, потратив столько времени на оптимизацию С++ кода для Trimedia, на PC приходится начинать все (ну, или почти все) сначала – слишком по разному они выполняют этот код.

Да, забыл добавить – в самых главных функциях от чистого C++ остается мало что, так как приходится широко использовать intrinsics – это современная замена inline-ассемблера. Это для использования всяких штук типа MMX/SSE…

> Вот ты пишешь, что сначала программируешь с позиций быстродействия,
> а потом уже причесываешь код, добавляешь структуру.
> А мне вот Страуструп, Ален и др. твердят, что преждевременная
> оптимизация чуть ли не хуже преждевременных родов.

Это хороший принцип, если начинаешь проект с чистого листа, когда нет ограничений на низком уровне. Например, если бы мне сейчас поручили написать тот же проект заново, я бы поменял почти все, начиная с железа :D. Но такой свободы не было, когда я за него взялся…
Ну и правила для того и существуют, чтобы их нарушать :D
Я так делаю далеко не всегда, но вот реальный пример.
Дано изображение некоего размера в формате YUV. Требуется преобразовать его в набор вейвлет-коэффициентов. Вопрос: какую иерархию классов выбрать?
ООП подход может привести к тому, что будет класс Wavelet, содержащий три экземпляра ColorPlane, по одному для Y, U, и V. Вроде нормально, почему бы и нет?
Теперь такой вопрос: как представлять данные в памяти?
Один вариант – есть три двумерных массива, для каждой цветовой плоскости.
Второй вариант – массив один, каждый элемент содержит значение Y,U,V для одного пиксела.
Первый вариант более приемлем с точки зрения ООП – три объекта одного класса, интерфейс один, все по правилам.
Но эксперимент показывает, что второй вариант на 30% быстрей, из-за особенностей доступа к памяти.
Приходится жертвовать гибкостью и лепить сложный объект «всё в одном», нарушая принцип low coupling. Однако интерфейс класса остается таким же, каким он был бы в первом случае, то есть для пользователя без разницы, главное, чтобы преобразование работало.
Что-то в таком духе...

> И еще, что от макросов практически всегда можно отказаться без потери
> быстродействия и с улучшением читабельности.
В общем случае да. Но - сильно зависит от компилятора. В моем случае компилятор генерировал для inline функции намного худший код, чем для макроса, а функция эта выполнялась для каждого пиксела изображения, что влекло за собой потерю 25% производительности.
Как я уже говорил, это вопрос выбора, поиск компромисса – готов ли ты заплатить эти 25% за соответствие правилам хорошего тона? Каждый разработчик решает по-своему.

> Как ты относишься к динамическому выделению памяти?
> Всегда ли разумно ее применять.
> Для классов изображений (кадров), для потоков, для стеков, очередей, матриц и т.д.
Хороший вопрос. Например, для кода работающего на Trimedia, я выделяю память только один раз, в самом начале, после того как прочитана конфигурация системы и определено, сколько ж её (памяти) надо.
Все объекты – элементы списков и т.д. – в большинстве случаев создаются заранее в достаточном количестве, только помечаются как неиспользованные (то есть память под них уже выделена), и задействуются по мере надобности, а, отработав, помечаются обратно как свободные. Другой вариант представления того же принципа – создается пул свободных объектов, из которого они берутся при «создании», и возвращаются обратно при «удалении».
Никаких утечек памяти! И время создания/удаления объектов заметно уменьшается.
Единственная проблема – если памяти под пул выделено недостаточно много :) Но это всё решаемо...
В остальном эти объекты ничем не отличаются от обычных, только сравнение указателей лучше не использовать :D

> И что такое то, "ручной луп анроллинг под размер страницы кеша"?
>Прости я в английском не силен, да и редких технологиях тоже.
Это раскрутка цикла, то есть
for(i=;i Про генерацию кода
> А вот это действительно интересно.
> На чем пишешь и зачем.

На плюсах пишу. Этот как раз довольно скучно, просто автоматизация этих самых экспериментов «на скорость»... Число параметров слишком велико (скажем, та же степень раскрутки циклов - один из них), чтобы перебрать все из них, уходит много времени, а так раз-два и готово. Потом анализируешь результаты, выбираешь наиболее быстрые варианты кода, прогоняешь через профайлер, смотришь, где тратится лишнее время, потом прогоняешь на симуляторе и т.д. Рутина... ;)

Ответы:



Ответить на это сообщение

Тема:

Имя (желательно полное):

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).

Пожалуйста, заполните все поля.
И не нажимайте по два раза на кнопку! Дождитесь ответа сервера.