| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > Оптимизация кода |
| Автор: Alexandering 16.10.2008, 16:08 |
| Вобщем препод дал основные способы оптимизыции кода. Никак их не стал описывать, мол сами должны понимать. Вот у меня возникли некоторые вопросы. 1) По возможности заменять цикл for(i=1;i<=n;i++) на for(i=n;i>=0;i--) Кто-нить может мне обьяснить, за счет чего тут выйгрышь? К тому же, у нас реализуется МетодКрупныхЧастиц(Давыдова), т.е. там основной цикл по времени, который просто нереально заменить вышеописанным способом. 2) Вложенные циклы типа for(i=1;i<=n;i++){ for(j=1;j<=m;j++){ for(k=1;k<=F;k++){... }}} заменять на один цикл....Тока как это проворачивать???? -------------- Я понимаю, что Вы щас отошлете к литературе...тока вот читать ее некогда...нужно уже скоро сдавать....а рабочая лаба на данный момент, для двухмерного случая считает около 6 часов реального времени(вот жопа)....На проце с частотой ~3.1 MHz -------------- 3) Действия "/","-" заменять на "*","+". Только как, кпримеру, выражение A[i][j]-pMax можно переписать не используя вычетание? 4) Ну и вопрос к Вам....как еще можно ускорить выполнение расчетной части??? Куча массивов для Температур,Давлений и прочего выделял динамически.....От очень удобной structure пришлось отказаться...памяти много жрет.... -------------- Жду... |
| Автор: Alek86 16.10.2008, 16:18 | ||||
бред какой-то
зависит от того, что в теле циклов делается, но выигрыш очень вряд ли большой получится |
| Автор: mes 16.10.2008, 16:18 | ||
на циклах Вы не съэкономите столько - расход ресурсов у Вас в другом месте. |
| Автор: Alek86 16.10.2008, 16:22 | ||
препод или большой приколист или дурак главные принципы оптимизации кода - глобальный пересмотр кода а это такие мелочи, на которые внимание почти никто не обращает |
| Автор: Alexandering 16.10.2008, 16:35 | ||||||
Вот и мне не понятно...
А я почему-то всегда думал, что тормоза как раз из-за банальных повторений каких-нить не необходимых операций в циклах... Ну в принципе на выходе я имею файл со всеми мне нужными данными в размере 1,5 ГБ.(Вот из-зи этого тормоза probably???) И это пока тестовая прогонка алгоритма...Заменил все типы переменных с double на float размер выходного файла снизился до 1 ГБ. Как тут еще покряхтеть - ума не приложу....А ведь это потом надо будет визуализировать...
Ну вообще-то доктор ф.-м.н. все время в отЪездах...времени на нас нет..поэтому ниче не обЪясняет... ----------------- А от себя предложите пож-та самые простые методы борьбы с тормозами....В алгоритме уже итак убрал все процедуры...Почти ни какой "логики" не осталось. ----------------- Да, если что, компилятор - C++Builder 6.0 |
| Автор: mes 16.10.2008, 16:41 | ||||||
ага зачастую именно из за этого.
имелось ввиду на замене знака. Смотреть надо что делается внутри него.
выложите алгоритм, тогда может что нибудь видно будет ) |
| Автор: Rickert 17.10.2008, 02:32 | ||||
A[i][j] + (-pMax)
Где-то на форуме это обсуждалось, дизассемблировалось и приводились доводы. Но имхо, как уже упоминалось: это слишком нечтожные оптимизации, чтобы выиграть реальное время. От них вы получите максимум прирост в пару минут по быстроте. |
| Автор: Mayk 17.10.2008, 08:17 | ||||||||
разве что при допущении что до этого программа исполнялась где-то пару недель 
это опечатка?
минус на плюс? что за бредятина? а деление на константу компиляторы сами умеют оптимизировать.
Во-перых прогони под профайлером. во-вторых опять прогони под профайлером. valrgrind к примеру умеет показывать как часто происходят промахи мимо кеша, их тоже можно оптимизировать. |
| Автор: Lazin 17.10.2008, 08:24 | ||||
сравнение с нулем немного эффективнее чем сравнение с числом
видимо здесь имеется ввиду оптимизация самого алгоритма, что-бы вместо сложности O(n*m*F), получить меньшую сложность |
| Автор: MAKCim 17.10.2008, 08:50 | ||||||
сравни код
и
|
| Автор: Lycifer 17.10.2008, 09:42 |
| Оптимизация кода сейчас не актуально(только на real time, или где ресурсы по не сколько байт играют роль), алгоритм влияет на скорость работы, таже CLR где операции долше выполняются не сильно отстанет от С++(в не которых местах превосходит, в не сколько раз) |
| Автор: MAKCim 17.10.2008, 11:23 | ||||
вопрос был не в актуальности 
1. примеры таких мест можно? 2. так уж в несколько раз? |
| Автор: MTWizard 17.10.2008, 11:47 | ||
Вот это как раз может быть причиной медленной работы. Этот компилер генерирует отвратительно оптимизированный код, который сравним по скорости с кодом Visual C++ 2003 без оптимизации!!! Смени компилятор - Visual C++ 2008 или вообще Intel C++ последний и удивись, насколько быстрее заработал тот же алгоритм. Добавлено @ 11:50 Кстати, насчёт всех оптимизаций, приведённых преподом - нормальные компиляторы их все делают сами (Builder 6 к нормальным не относится), потому не надо уродовать код, делая за компилер его работу |
| Автор: Rickert 17.10.2008, 11:58 | ||
Убил бы за такие слова, ей богу. Вот пока будут такие программисты как вы, мы будем для каждой новой игры апгрейдить тачку. |
| Автор: Alek86 17.10.2008, 12:07 |
| Rickert, к гейм девелопменту это не относится. уж они-то обычно за каждый бит (такт) дерутся |
| Автор: Ln78 17.10.2008, 12:38 | ||||||
Внесу свои 3 копейки 
То ли никто не заметил, то ли не стали придираться, но циклы неэквиваленты: или в первом с нуля, или во втором неравенство строгое.
Думаю, что потребуется не меньше пары лет.
К сложным (в смысле именно вычислительных затрат) научным расчётам это относится в неменьшей степени. Единого метода оптимизации для таких задач не существует. В частности, нужно смотреть (можно профайлером, хотя, с некоторым опытом это несложно делать и "на глазок") те участки кода, которые либо в циклах, которые выполняются очень много раз, нет ли там одной и той же работы, выполняемой многократно, либо те, которые содержат вызовы разных функций типа синусов, думать, как можно формулы переписать по-другому, чтобы уменьшить вычислительную сложность задачи. |
| Автор: nerezus 18.10.2008, 21:18 |
| Есть отличная статья. Смысл ее такой: оптимизировать надо только узкие места. Оптимизировать все подряд - плохо. http://rsdn.ru/article/philosophy/Optimization.xml По теме: 1) Измени алгоритм(в том числе оптимизируй запросы к внешним источникам) 2) юзай профайлер для отлова узких мест 3) Замени компилятор на нормальный. |
| Автор: Alexandering 19.10.2008, 16:12 |
| Всем спасибо.... Удалось сократить время расчета до ~ 4часов... Лабу успешно сдал... Препод сказал, мол эту лабу в прошлые годы считали на старых процах за пару часов.... --------- Вывод: [Я-Ламо]. ---------------------------- nerezus 2) юзай профайлер для отлова узких мест - знать бы, что это такое...Я так понимаю это какой-то навороченный дебаггер? И для успешного его использования, надо ли фладеть Ассемблером? 3) Замени компилятор на нормальный. - нормальный, это какой?? И будет ли у меня "культурный шок" после перехода с Builder`a на него(Я так понимаю Вы о VisualStudio, или как там его,...) |
| Автор: Lazin 19.10.2008, 16:22 | ||
Вывод: существует более оптимальный алгоритм  |
| Автор: _GRIN_ 19.10.2008, 23:00 | ||||
Alexandering, в кратце: профайлер - программа, которая анализирует время исполнения (возможно ещё и выделяемые ресурсы - у меня мало опыта) твоей программы, конкретно в VTune (тулза от Intel - может подключаться к Visual Studio) можно вывести какая иструкция (выражание) в твоей проге сколько жрёт тактов (прям напротив строки исходника циферка выводится) - сразу начинаешь удалять лишние циклы  нормальный компилятор - обсуждение и разряда Holly Wars - имхо для процов интел лучше брать последний компилятор с сайта производителя (под другие процы не пробывал, так что советывать не буду). По поводу культурного шока - по идее ты скармливаешь компилятору исходник на С++ (который можешь набрать в блокноте) он создаст тебе объектник, а его линковщику - он создаст бинарник, можно настроить makefile (текстовый конфигуратор) и тогда вообще забить на IDE - мой друг (имхо настоящий гений) только так и работает, я правда пользуюсь студией Так что разок разберёшься как ему скормить исходник (компилятору) и всё - пиши исходники как раньше писал.
Не обязательно, но если владеешь - то большой плюс, так как понимаешь "механику" (другого слова не подобрал) работы создаваемой тулзы. удачи ... |
| Автор: Rickert 20.10.2008, 03:54 | ||
Ага, расскажите мне эту сказку. Проснитесь, игры теперь - это бизнес, а не развлеение или искусство: программистов засовывают в жёсткие рамки бюджетов. Посмотритен на недавнюю Spore. Какая ей нужна тачку? А теперь посмотрите что в ней реализованно? Что ЖРЁТ стоьлко ресурсов? Топорная окружающая среда? Или кривая скелетная анимация? ИЛи может ключные тени? Это сырой ширпотреб. Вот когда Кармак создал свою граф. библиотеку для первой кваки - вот где была оптимизация и мастерство, а нынче - это песочница. |
| Автор: Earnest 20.10.2008, 14:37 | ||
Можно подумать, что доктор ф-м наук не может быть дураком... Но на самом деле, скорее всего, он в последний раз сам писал программу году этак в 80 и на фортране - все его методы и советы (и код цикла, который с 1 начинается - явно оттуда). А лабу свою, которая 6 часов работает, за счет замены циклов ты не ускоришь... Разве что там какая-то явная глупость. Ну и тут оптимизация не поможет... |
| Автор: nerezus 20.10.2008, 23:19 | ||||
Нормально сделали ее, багов даже не заметил. |
| Автор: kroko 22.10.2008, 16:54 |
| для того что бы оптимизировать код надо во первых - отказаться от использования double и float и пользоватся только целочисленными переменными - за программировать свой собственные фунции синус конинус и.т далее которые работают с целыми числами - пересмотреть алгоритм могу поспорить что даже если первое и второе сделаешь то у тебя программа будет работать в несколько раз быстрее |
| Автор: Mayk 22.10.2008, 17:10 | ||
низкоуровневые оптимизации следует рассматирвать ПОСЛЕ рассматривание алгоритмов. тем более что в паре с шаблонами c++ это не так уж и сложно. |
| Автор: vinter 22.10.2008, 17:46 | ||||
я думаю будет приступ с конвульсиями, по крайней мере я не видел еще ни кого, кто перешел с билдера на студию и это прошло бесследно для его организма
в журнале C'T была статья про компиляторы, Интел почти везде лучше VS компилятора. Но Intel так же платный. Т.е нахаляву высокой оптимизации не будет, а для мелких приложений внутреннего пользования мегаоптимизации не нужна.. |
| Автор: nerezus 22.10.2008, 20:06 | ||
|
| Автор: xvr 23.10.2008, 11:56 | ||||||
Работаю и на том и на другом (причем одновременно) - никаких последствий для организма не ощущаю
|
| Автор: vinter 23.10.2008, 13:07 | ||||
есть, если интересно могу выложить в чем. Добавлено через 24 секунды
начинал с чего? |
| Автор: xvr 23.10.2008, 16:32 | ||||||||
Выложи, очень интересно
|
| Автор: Earnest 23.10.2008, 17:10 | ||
Тогда не считается. Имеются в виду те, кто изучал программирование в "визуальной" среде: мышкой компоненты к форме прибивал. А у всех, кто начинал с Доса, к визардам иммунитет.   |
| Автор: vinter 23.10.2008, 17:33 | ||
Стандарт - 12700 Проф - 17000 Академическая - 4512 Все это в рублях |
| Автор: bsa 23.10.2008, 17:46 |
| vinter, а под линукс есть еще и бесплатная версия |
| Автор: xvr 23.10.2008, 20:26 | ||||||||||||
Это не отличие в компиляторе, а отличие в наборе поставляемых библиотек. На уровень оптимизации это никак не сказывается. Кроме того, можно скачать evaluation версию, она полнофункциональна (включая библиотеки) Или перебирайтесь под Linux - там полнофункциональная некомерческая версия:
Добавлено через 12 минут и 22 секунды
Равно как и автор бестелера if (flag.Length()<=4) // check for 'true'  |
| Автор: Ln78 24.10.2008, 15:02 | ||
 Тем, кто начинал с машинных кодов и перфоратора Джуки для ввода кода, и BC 3.1 мёдом будет казаться. Насколько я помню, самому BC 3.1 всё же меньше 20, до него я пользовался TC 2.0, и ведь тоже казалось большим прогрессом, хотя самих отличий сейчас уже не помню. |
| Автор: J0ker 24.10.2008, 17:16 |
| борланд всегда грешил излишней кастомизацией языков |
| Автор: likehood 24.10.2008, 21:58 | ||
Кстати, вполне возможно. Я как-то имел дело с программой, в которой промежуточные данные хранились в множестве мелких файлов (видимо, автор не знал, как на Делфи реализовать map, и использовал для этого файловую систему). Программа обрабатывала данные за несолько часов. Когда я переписал ее по-человечески (без существенного изменения алгоритма), она стала обрабатывать те же данные за две минуты. Так что работу с файлами не стоит сбрасывать со счетов. |
