[an error occurred while processing this directive]
Хех, почему OPT? Как раз OTB :)
(«Телесистемы»: Конференция 'Цифровые сигнальные процессоры (DSP) и их применение')
Отправлено
Dr.Alex
15 декабря 2004 г. 13:37
В ответ на:
Да-да... И я об том-же. И кто "сделал" 6416-го, смотрим только на "OPT" версии?
отправлено SM 15 декабря 2004 г. 13:24
Составить ответ
|||
Конференция
|||
Архив
Ответы
Так не компилеры же сравниваются, а процессоры :)
—
SM
(15.12.2004 13:38,
пустое
)
должно насторожить разработчика - когда С и оптимизированный АСМ раз в 30 отличаются по производительности
—
yes
(15.12.2004 15:35, 178 байт)
Ну порядок отличия OTB от OPT у всех похож, плюс минус в два раза различия. И что это - из-за этого настроживаться?
—
SM
(15.12.2004 15:43,
пустое
)
хватит ли ловкости рук, чтоб на АСМе все соптимизировать, ну и сколько времени на это нужно
—
yes
(15.12.2004 15:49, 93 байт)
Да забить на полную победу ассемблера - взять только OPT на C...
—
SM
(15.12.2004 15:50,
пустое
)
ну там (например ОПТ С 62хх) тоже надо извратится, то есть понять архитектуру, всякие заморочки, попрактиковаться
—
yes
(15.12.2004 16:06, 168 байт)
Да для любого процессора есть свои нюансы (+)
—
SM
(15.12.2004 16:14, 504 байт)
я кстати ни в коей мере не считаю 6ххх или 55хх неудачными и негодными - просто они неудобные
—
yes
(15.12.2004 16:59,
пустое
)
Ну да - типа как (+)
—
SM
(15.12.2004 17:08, 229 байт)
да, на РС вместо МАТЛАБа (для не реалтаймовых вычислений) используется С++
—
yes
(15.12.2004 16:23, 249 байт)
Кстати для совсем ленивых в матлабе "embedded target"ы есть... Типа сразу модель прям в проц. Только что-то не думается об эффективности такого подхода.
—
SM
(15.12.2004 16:31,
пустое
)
И почему-то нету ни для PPC, ни для MIPS :)
—
SM
(15.12.2004 16:31,
пустое
)
чего-то есть у меня смутные подозрения, что есть PPC-target
—
yes
(15.12.2004 16:42, 146 байт)
Да, действительно, погорячился :) Для xPC есть.
—
SM
(15.12.2004 16:46,
пустое
)
"Как сделать" (+)
—
SM
(15.12.2004 16:27, 131 байт)
вот посмотрел info gcc :)
—
yes
(15.12.2004 16:39, 759 байт)
Не, эт я и сам читал, а как его заставить (+)
—
SM
(15.12.2004 16:43, 151 байт)
cat file1.c file2.c file3.c > big_file.c :)))
—
yes
(15.12.2004 16:48, 140 байт)
Этот cat для static ф-ций плохо кончится :) :) (+)
—
SM
(15.12.2004 16:51, 197 байт)
да хоть 10-call из 10 циклов - единственно можно сэкономить - не сохранять link регистр (как в АРМе)
—
yes
(15.12.2004 16:57, 238 байт)
Я не про то. (+)
—
SM
(15.12.2004 17:01, 355 байт)
не понял причем call-ret к циклу? там условный переход - у него признак (выставляется компилером) - свершится он или нет
—
yes
(15.12.2004 17:05, 100 байт)
Вот причем (+)
—
SM
(15.12.2004 17:11, 281 байт)
да вроде не должно. пайплайн-то чистить не надо
—
yes
(15.12.2004 17:18, 257 байт)
С линк-регистром понятно (+)
—
SM
(15.12.2004 17:22, 252 байт)
Кому что :) А насчёт асмо-оптимизированных бенчмарков yes и не спорил, я полагаю..
—
Dr.Alex
(15.12.2004 13:44,
пустое
)
Ну не знаю, по крайней мере я спорил именно про процессоры и архитектуры, а не про компиляторы.
—
SM
(15.12.2004 13:51,
пустое
)
Ну а если исходное условие - писать на С сторого (а это подразумевалось, кажется), то сравнение архитектур автоматически превращается в сравнение компиляторов..
—
Dr.Alex
(15.12.2004 14:02,
пустое
)
Я не знаю кем что подразумевалось (+)
—
SM
(15.12.2004 14:08, 316 байт)
вроде есть там (раньше видел для ОРТ С 64хх) - проигрывает слегка ОРТ С РРС7х, но hi-end не 7х, а 9х (true 64bit :-)
—
yes
(15.12.2004 15:31, 210 байт)
Да-да, сорри, есть там С-версия оптимизированная. И показатели у нее (+)
—
SM
(15.12.2004 15:40, 93 байт)
А кстати, для PPC имеется в С (+)
—
SM
(15.12.2004 15:36, 148 байт)
вроде нет. простой вопрос, а не знаю
—
yes
(15.12.2004 15:45, 539 байт)
И еще (+)
—
SM
(15.12.2004 15:56, 100 байт)
подальше надо держаться от таких компиляторов :)
—
yes
(15.12.2004 15:59,
пустое
)
Это еще почему? Мне же не интересно, сколько CALLов будет в коде, мне интересно чтоб работало :)
—
SM
(15.12.2004 16:04,
пустое
)
Не - там сам С-компилер (+)
—
SM
(15.12.2004 15:47, 144 байт)
вообще-то еще библиотеки бывают... а такую оптимизацию можно и через препроцессор сделать
—
yes
(15.12.2004 15:56,
пустое
)
Библиотеки тоже в исходниках поставляются - так что ноу проблемз.
—
SM
(15.12.2004 15:57,
пустое
)
ран-тайм, дсплиб всякие... О проприетарщине конечно речи нет - линкуй и все тут
—
SM
(15.12.2004 15:58,
пустое
)
А ликер - да он не сможет (+)
—
SM
(15.12.2004 15:49, 108 байт)
теоретически - нет проблем, стек не заполняется, параметры через регистры - call для 6xxx затратная операция
—
yes
(15.12.2004 16:02, 34 байт)
Проблемы в другом (+)
—
SM
(15.12.2004 16:05, 141 байт)
ну а если конвеер работает независимо от исполнительного юнита и у него есть предиктор перехода (РРС)?
—
yes
(15.12.2004 16:12, 370 байт)
Насчет Бабаяна не знаю, а у ТИ вроде очень даже неплохо получается (+)
—
SM
(15.12.2004 16:18, 324 байт)
это хорошо :). хотя если начинать с "все плохо", то для улучшений много возможностей :)
—
yes
(15.12.2004 16:33, 347 байт)
Ну нельзя же сразу же взять да выпустить сложный компилер, это вполне естественно (+)
—
SM
(15.12.2004 16:48, 56 байт)
ну может не для этой конфы - для 51-го сколько прошло времени, пока появился компилер, а для AVR ?
—
yes
(15.12.2004 16:52, 148 байт)
Зато если наоборот (+)
—
SM
(15.12.2004 16:58, 458 байт)
но я рад, что пока мне 51 на С программировать не надо :) тьфу-тьфу-тьфу
—
yes
(15.12.2004 17:01,
пустое
)
И это правильно (+)
—
SM
(15.12.2004 17:04, 211 байт)
А выход из этого один единственный (+)
—
SM
(15.12.2004 17:13, 165 байт)
Отправка ответа
Имя (обязательно):
Пароль:
E-mail:
Тема (обязательно):
Сообщение:
Ссылка на URL:
Название ссылки:
URL изображения:
Перейти к списку ответов
|||
Конференция
|||
Архив
|||
Главная страница
|||
Содержание
|||
Без кадра
E-mail:
info@telesys.ru