Вобщем препод дал основные способы оптимизыции кода. Никак их не стал описывать, мол сами должны понимать. Вот у меня возникли некоторые вопросы.
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 пришлось отказаться...памяти много жрет....
--------------
Жду...

бред какой-то



зависит от того, что в теле циклов делается, но выигрыш очень вряд ли большой получится

на циклах Вы не съэкономите столько - расход ресурсов у Вас в другом месте.

препод или большой приколист или дурак
главные принципы оптимизации кода - глобальный пересмотр кода
а это такие мелочи, на которые внимание почти никто не обращает

Вот и мне не понятно...



А я почему-то всегда думал, что тормоза как раз из-за банальных повторений каких-нить не необходимых операций в циклах...
Ну в принципе на выходе я имею файл со всеми мне нужными данными в размере 1,5 ГБ.(Вот из-зи этого тормоза probably???) И это пока тестовая прогонка алгоритма...Заменил все типы переменных с double на float размер выходного файла снизился до 1 ГБ. Как тут еще покряхтеть - ума не приложу....А ведь это потом надо будет визуализировать...


Ну вообще-то доктор ф.-м.н. все время в отЪездах...времени на нас нет..поэтому ниче не обЪясняет...
-----------------
А от себя предложите пож-та самые простые методы борьбы с тормозами....В алгоритме уже итак убрал все процедуры...Почти ни какой "логики" не осталось.
-----------------
Да, если что, компилятор - C++Builder 6.0

ага зачастую именно из за этого.

имелось ввиду на замене знака. Смотреть надо что делается внутри него.


выложите алгоритм, тогда может что нибудь видно будет )

A[i][j] + (-pMax)


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

разве что при допущении что до этого программа исполнялась где-то пару недель   


это опечатка?


минус на плюс? что за бредятина? а деление на константу компиляторы сами умеют оптимизировать.


Во-перых прогони под профайлером. 
во-вторых опять прогони под профайлером. 
valrgrind к примеру умеет показывать как часто происходят промахи мимо кеша, их тоже можно оптимизировать.

сравнение с нулем немного эффективнее чем сравнение с числом


видимо здесь имеется ввиду оптимизация самого алгоритма, что-бы вместо сложности O(n*m*F), получить меньшую сложность

сравни код

и

Оптимизация кода сейчас не актуально(только на real time, или где ресурсы по не сколько байт играют роль), алгоритм влияет на скорость работы, таже CLR где операции долше выполняются не сильно отстанет от С++(в не которых местах превосходит, в не сколько раз)

вопрос был не в актуальности   



1. примеры таких мест можно?
2. так уж в несколько раз?   

Вот это как раз может быть причиной медленной работы. Этот компилер генерирует отвратительно оптимизированный код, который сравним по скорости с кодом Visual C++ 2003 без оптимизации!!!
Смени компилятор - Visual C++ 2008 или вообще Intel C++ последний и удивись, насколько быстрее заработал тот же алгоритм.

Добавлено @ 11:50
Кстати, насчёт всех оптимизаций, приведённых преподом - нормальные компиляторы их все делают сами (Builder 6 к нормальным не относится), потому не надо уродовать код, делая за компилер его работу

Это сообщение отредактировал(а) MTWizard - 17.10.2008, 11:50

Убил бы за такие слова, ей богу.
Вот пока будут такие программисты как вы, мы будем для каждой новой игры апгрейдить тачку.

Rickert, к гейм девелопменту это не относится. уж они-то обычно за каждый бит (такт) дерутся


Это сообщение отредактировал(а) Alek86 - 17.10.2008, 12:08

Внесу свои 3 копейки  

То ли никто не заметил, то ли не стали придираться, но циклы неэквиваленты: или в первом с нуля, или во втором неравенство строгое.

Думаю, что потребуется не меньше пары лет. 

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

Есть отличная статья.
Смысл ее такой: оптимизировать надо только узкие места.
Оптимизировать все подряд - плохо.

http://rsdn.ru/article/philosophy/Optimization.xml

По теме: 
1) Измени алгоритм(в том числе оптимизируй запросы к внешним источникам)
2) юзай профайлер для отлова узких мест
3) Замени компилятор на нормальный.

Всем спасибо....
Удалось сократить время расчета до ~ 4часов...
Лабу успешно сдал...
Препод сказал, мол эту лабу в прошлые годы считали на старых процах за пару часов....
---------
Вывод: [Я-Ламо].

----------------------------
nerezus
2) юзай профайлер для отлова узких мест
 - знать бы, что это такое...Я так понимаю это какой-то навороченный дебаггер? И для успешного его использования, надо ли фладеть Ассемблером?
3) Замени компилятор на нормальный.
 - нормальный, это какой?? И будет ли у меня "культурный шок" после перехода с Builder`a на него(Я так понимаю Вы о VisualStudio, или как там его,...)

Это сообщение отредактировал(а) Alexandering - 19.10.2008, 16:17

Вывод: существует более оптимальный алгоритм  

Alexandering, в кратце:
профайлер - программа, которая анализирует время исполнения (возможно ещё и выделяемые ресурсы - у меня мало опыта) твоей программы, конкретно в VTune (тулза от Intel - может подключаться к Visual Studio) можно вывести какая иструкция (выражание) в твоей проге сколько жрёт тактов (прям напротив строки исходника циферка выводится) - сразу начинаешь удалять лишние циклы 

нормальный компилятор - обсуждение и разряда Holly Wars - имхо для процов интел лучше брать последний компилятор с сайта производителя (под другие процы не пробывал, так что советывать не буду). По поводу культурного шока - по идее ты скармливаешь компилятору исходник на С++ (который можешь набрать в блокноте) он создаст тебе объектник, а его линковщику - он создаст бинарник, можно настроить makefile (текстовый конфигуратор) и тогда вообще забить на IDE - мой друг (имхо настоящий гений) только так и работает, я правда пользуюсь студией 
Так что разок разберёшься как ему скормить исходник (компилятору) и всё - пиши исходники как раньше писал.



Не обязательно, но если владеешь - то большой плюс, так как понимаешь "механику" (другого слова не подобрал) работы создаваемой тулзы.

удачи ... 

Это сообщение отредактировал(а) _GRIN_ - 19.10.2008, 23:04

Ага, расскажите мне эту сказку. Проснитесь, игры теперь - это бизнес, а не развлеение или искусство: программистов засовывают в жёсткие рамки бюджетов. Посмотритен на недавнюю Spore.
Какая ей нужна тачку? А теперь посмотрите что в ней реализованно? Что ЖРЁТ стоьлко ресурсов? Топорная окружающая среда? Или кривая скелетная анимация? ИЛи может ключные тени? Это сырой ширпотреб. Вот когда Кармак создал свою граф. библиотеку для первой кваки - вот где была оптимизация и мастерство, а нынче - это песочница.

Можно подумать, что доктор ф-м наук не может быть дураком... Но на самом деле, скорее всего, он в последний раз сам писал программу году этак в 80 и на фортране - все его методы и советы (и код цикла, который с 1 начинается - явно оттуда). 
А лабу свою, которая 6 часов работает, за счет замены циклов ты не ускоришь... Разве что там какая-то явная глупость. Ну и тут оптимизация не поможет...

 На вопросы "Что такое ***" лучше всего ответит гугл. Это аксиома.

 Летает на максималках на далеко не топовой машинке.
Нормально сделали ее, багов даже не заметил.

для того что бы оптимизировать код надо во первых

-  отказаться от использования double и float и пользоватся только целочисленными переменными 

- за программировать свой собственные фунции синус конинус и.т далее  которые работают с целыми числами 

- пересмотреть алгоритм   

могу поспорить что даже если первое и второе сделаешь то у тебя программа будет работать в несколько раз быстрее   

 низкоуровневые оптимизации следует рассматирвать ПОСЛЕ рассматривание алгоритмов.
тем более что в паре с шаблонами c++ это не так уж и сложно.

я думаю будет приступ с конвульсиями, по крайней мере я не видел еще ни кого, кто перешел с билдера на студию и это прошло бесследно для его организма 


в журнале C'T была статья про компиляторы, Интел почти везде лучше VS компилятора. Но Intel так же платный. Т.е нахаляву высокой оптимизации не будет, а для мелких приложений внутреннего пользования мегаоптимизации не нужна..

 И вообще отказаться от переменных, а сразу писать константу. Пример идеальной программы: 21

Работаю и на том и на другом (причем одновременно) - никаких последствий для организма не ощущаю   

На сайте Intel'а бесплатно раздается студенческая некомерческая версия их компиляторов. Отличий в уровне оптимизации вроде нет.

есть, если интересно могу выложить в чем.

Добавлено через 24 секунды

начинал с чего?

Выложи, очень интересно

С BC 3.1 (лет так 20 назад)

Тогда не считается. 
Имеются в виду те, кто изучал программирование в "визуальной" среде: мышкой компоненты к форме прибивал.
А у всех, кто начинал с Доса, к визардам иммунитет.
    

Стандарт - 12700
Проф - 17000
Академическая - 4512
Все это в рублях

vinter, а под линукс есть еще и бесплатная версия   

Это не отличие в компиляторе, а отличие в наборе поставляемых библиотек. На уровень оптимизации это никак не сказывается. Кроме того, можно скачать evaluation версию, она полнофункциональна (включая библиотеки)
Или перебирайтесь под Linux - там полнофункциональная некомерческая версия:


Добавлено через 12 минут и 22 секунды

  

А если они умеют ТОЛЬКО 'мышкой компоненты к форме прибивать' или искренне считают, что Builder или Delphy их не пустят дальше своих форм (с прибитыми мышкой компонентами), то они програмистами не являются (IMHO).

Равно как и автор бестелера if (flag.Length()<=4) // check for 'true'   

  Тем, кто начинал с машинных кодов и перфоратора Джуки для ввода кода, и BC 3.1 мёдом будет казаться. Насколько я помню, самому BC 3.1 всё же меньше 20, до него я пользовался TC 2.0, и ведь тоже казалось большим прогрессом, хотя самих отличий сейчас уже не помню.

борланд всегда грешил излишней кастомизацией языков

Кстати, вполне возможно. Я как-то имел дело с программой, в которой промежуточные данные хранились в множестве мелких файлов (видимо, автор не знал, как на Делфи реализовать map, и использовал для этого файловую систему). Программа обрабатывала данные за несолько часов. Когда я переписал ее по-человечески (без существенного изменения алгоритма), она стала обрабатывать те же данные за две минуты. Так что работу с файлами не стоит сбрасывать со счетов.