Решил не плодить кучу меких тем и написать все в одной
1) При динамической линковке производительность меньше чем при статической?
Как я понимаю да при статической все нужное от динам. либы войдет в бинарник.
2) Как собрать х64 приложение, есть Ubuntu 10.10 x64, только я не уверен (не знаю как проверить) что прога именно 64-х битная.

qmake /"мой путь"/cv.pro -r -spec linux-g++-64

Какие есть ключи для оптимизации, и есть ли они вообще. Где глянуть, пока кроме -static ничего не нашел.
3) Какие еще есть методы увеличения производительности. Важна каждая миллисекунда.
4) Читал на тему того, что даже разные версии gcc влияют на производительность.
Заранее спасибо.

компилятор icc (Intel) - производительность в полтора-два раза быстрее на любом(!) процессоре в любой системе. однозначно. даже по сравнению с gcc. для линюкса есть полная бесплатная версия icc. отличная вещь.
статическая линковка на современных системах никак не влияет на скорость доступа (каждый процесс крутится в своём пространстве и если линки не отложенные (LAZY), то линковка всех входов-выходов происходит один раз, при старте программы, дальше всё происходит стандартно, как при вызове любых других функций из адресного пространства процесса).
лучшеее ускорение - отказ от виртуальных функций всех видов. вызовы через таблицы виртуальных методов тормозят работу. отказ от ввода-вывода любого плана (самое медленное в системах всех видов) и вынос ввода-вывода в отдельные малоприоритетные потоки, применение скоростных таймеров и системно-зависимых методов синхронизации. собственно, при использовании QT оптимизация может быть лишь относительной. у QT нет такой задачи. это кроссплатформенная библиотека и некоторые моменты могут быть вовсе не оптимальны. хотя на уровне миллисекунд может и проканает. это довольно медленное выполнение. только под вендой нужно юзать мультимедийные таймеры, если нужны тайминги и нельзя юзать стандартный Sleep - там очень большие интервалы (около 15 мс).

да вот не всегда это возможно. Это надо очень хорошую причину иметь (программа под контроллер, например, или некий драйвер).

Я вот книжку умную прочел, так там пишут что "хорошее знание предметной области" зачастую лучшая оптимизация.
Уровни оптимизации существуют различные. Начиная от проектирования, выбора языка, кодирования .возможно критичные участки кода на acm и проч и проч. и так далее к выбору компилятора изучения его уровней оптимизации, может под него кое-где и код придется переписать.

А ещё, нет смысла особо оптимизировать всё подряд в программе, если имеется хотя бы одно узкое по времени место Вот если это место удасться заоптимизировать до сравнимых с другими частями программы скоростей, тогда и

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

RazrFalcon,
ты собираешься вопросы задавать про оптимизацию в Qt?
по-моему тему нужно перенести из Раздела Qt.Общие вопросы

ну, тут не поспоришь. но иногда найти это узкое место иногда довольно сложно.

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

Это ты про что ??? и к чему ?

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

но иногда босс говорит - НАДО ))


а ты про что ?

да? спасибо, не знал.

не верю. это тоже уровень оптимизации.
Если собираешь чужую программу то соглашусь с тобой. Но если ты разработчик и пишешь и собираешься оптимизировать свою то нет.

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

а интеловский компилятор можно подружить с Qt для компилирования под armvi4 ?

Всем спасибо. Прилично постов прибавилось со вчера, я то рассчитывал на пару тройку, а тут уже 2-е страницы.
В раздел QT занес, потому что пока прога использует QT библиотеки (ну и в креаторе пишу ее), но как вариант рассматриваю и чистый с++, так как код в принципе кросплатформенный пока, ну и должен им оставаться в общем.
На счет icc совсем не подумал, хотя сами либы поддерживают его (openCV). Надо будет с этим разобраться.
Почитал на тему статеек, нашел интересный факт что ассемблирование не есть хорошо обычно, так как приводились доводы на тему того что, как уже писали выше, нормальный компилятор может получить только ~20% отставание от чистого асм. А писать на асме - ужос. Опыт небольшой есть, так что я не собираюсь это делать, разве что некоторые расчеты циклические. К слову еще читал на счет горячих точек, и отлова их с помощью VTune. Хотя для моего AMD это бесполезно.
Я конечно еще не супер программист=) но когда проги пофункциональней, работают без тормозов на 1ГГц армках КПК/КМК - это заставляет задуматься. (это на тему того что написал ufna)
Ну а в действительности имеем AMD Turion 2x1.9GHz, и от сюда надо плясать. Много от сюда не выжмешь, хотя легким вариантом использование CUDA тоже не назовешь. Это я к примеру, так как нету карточки такой, и не только у меня, дык еще нужно код переписывать под нее. Ну и теряется системо-независимость. То есть в идеале прога должна работать на всем включая кпк. Это так - цель!
Хотя целью еще можно назвать "основы и продвинутая оптимизация"

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

я немного опечатался, речь про armv4i. А в основном - можно ли на нем собрать Qt для WinCE Т.к. производительность очень критична, прирост даже на 5% был бы очень крутым, а если уж в полтора-два раза, то я крепко задумался о шаманизме.

видишь ли, собрать можно всё, что угодно, при условии, что компилятор поддерживает процессор, который в твоей штуковине сидит.
ну и с make-файлами для сборки нужно возиться. у icc свои опции, не всегда одинаковые с gcc.

а так, помнится, под icc 8 умельцы даже ядро собирали. летало, как на стероидах

icc даёт прирост производительности даже не на интеловских процах. он напичкан хитрожопыми алгоритами и у него много опций самой разнообразной оптимизации.
вообще, в Intel не дураки сидят. одна из самых уважаемых мною лично компаний в области IT и электроники. никакого бардака, всё продумано и стабильно работает, в отличие от некоторых (не будем показывать пальцем ).

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

ну я посмотрел, у них было для WinCE версия, но в 2008ом они продали ее Marvell, с концами. Потому я не особо понимаю как обычный icc заставить скомпилить под armv4i, под x86 то легко, а тут ((

с "украсть" то пофиг - если результат даст, я бы купил, мне это ОЧЕНЬ много значит такой прирост скорости.