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