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

E-Mail:

URL:

Город:

Страна:

Вежливый и подробный комментарий:
(Форматируйте его, пожалуйста, как почту - короткими строками
Еnter в конце строки, пустая строка между параграфами).
> Привет, Владимир, постараюсь ответить на твои вопросы. > 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 Про генерацию кода > > А вот это действительно интересно. > > На чем пишешь и зачем. > На плюсах пишу. Этот как раз довольно скучно, просто автоматизация этих самых экспериментов «на скорость»... Число параметров слишком велико (скажем, та же степень раскрутки циклов - один из них), чтобы перебрать все из них, уходит много времени, а так раз-два и готово. Потом анализируешь результаты, выбираешь наиболее быстрые варианты кода, прогоняешь через профайлер, смотришь, где тратится лишнее время, потом прогоняешь на симуляторе и т.д. Рутина... ;)

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