О скорости и точности.



Posted by Аркадий Водяник (195.206.226.37) on May 28, 2001 at 05:56:29:

In Reply to: Re: Пpоцедуpа постpоения тpехмеpных гpафиков (повеpхностей) posted by Владимир Секретев on May 27, 2001 at 20:06:55:

Здравствуй, Володя!

Ты сказал:

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

Отчего же, можно.
В общем-то, правильное опасение. Но есть такое соображение:
поскольку массивы (обычные наши array, а не ассоциативные
экстрапараметры или факты) имеют время жизни такое же, как и время
выполнения файла *.rpt, то попытки накопить что-либо в массиве
за время пересчета состояния вряд ли будут иметь место. Поэтому,
либо пользователь не знает что делает, или он делает это - но
только в форме.

О формах.

В сообщении
http://hdru.com/wwwboard/messages/2223.htm
говорится о процедуре DoSimpleService. Можно
сделать вывод, что форма готова прерваться почти сразу же на
каждый простой приоритетный запрос. На каждой стотысячной команде
виртуальной машины ФБП. Но, как ты и думаешь, такие вещи, как
операторы makepng, lsolve, invertm и функция [det...] делаются за
одну команду виртуальной машины. Конечно же, те кто их применяет,
вполне могут самостоятельно оценить, сколько же это времени
потребует. Да и ты это легко оценил, поэтому и спрашиваешь :)

Конечно же, надо задумываться: "что я рисую", "надо ли мне
заполнять неправильные контуры", "надо ли мне решать уравнения,
или я могу записать явное решение в виде длинной формулы", etc.

Скажу лишь:

1) makepng работает почти всегда быстро; тем быстрее, чем меньше
тонких деталей в изображении. Это просто распространенный
алгоритм сжатия (библиотека Libpng; сейчас не ищу ссылок в Internet'e,
по этому слову можно найти быстро).

2) операторы draw... делают тривиальные вещи, а draw3dplot - это не
оператор, а просто предложенный мной фрагмент на языке ФБП; я
написал его наскоро, там много мест, которые легко оптимизировать
путем выноса общих выражений в единое место, или за цикл,
если можно и т.д. В частности, для каждого четырехугольника делается
в среднем как минимум три лишних вычисления - координаты его
соседей вычисляются заново; можно применить массив и этого
не будет.
***
Если серьезно, то считаю проблему визуализации процессов
необходимой немногим. С другой стороны, если это надо, то
надо очень.

3) что касается линейной алгебры, то наши операторы
не претендуют на высокую скорость работы и эффективность
хранения элементов матрицы и точность решения для плохо
обусловленных матриц :) - хоть я и использовал для тестов
матрицы Гильберта (i,j=1/(i+j-1)).

4) если построить профиль процедуры draw3dplot для тех
примеров, что я показал в своем сообщении, увидим, что
лидером здесь будут строки при fm = 1, то есть при закрашивании
четырехугольников, аппроксимирующих поверхность; в самом деле,
применить наш оператор fillarea здесь нельзя - из-за того,
что сквозь четырехугольник будут видны контуры более
удаленных четырехугольников, и это помешает нормальному
закрашиванию. Поэтому я применил вместо fillarea закрашивание
путем циклического заштриховывания оператором drawline.

5) хотел бы предостеречь от необдуманного использования
оператора fillarea. Он рекурсивен - когда надо закрасить
точку i,j - он проверяет, как обстоят дела с ее соседями.
И делает это углубляя стек, пока не дойдет до максимально
разрешенной глубины вложенности. Нет, он не переполнит
стек,но он покрасит большую площадь не до конца. И будет
это делать относительно долго. Попробуйте такой пример:

fillarea a,400,400, 200,200, [ch 255]
makepng a,400,400, 'c:\1.png'



Пpишедшие ответы: