От AMX
К DVK
Дата 12.10.2005 13:47:59
Рубрики Танки;

Re: Продолжим список...

>во-вторых, в исходники не лазил, но боюсь, довольно проблематично с помощью предложенных алгоритмов обсчитывать картинку в реальном времени, при полете ракеты.

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

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

Только боюсь с электроникой в стране у нас не очень сейчас, хотя буду рад ошибиться.

От DVK
К AMX (12.10.2005 13:47:59)
Дата 12.10.2005 15:01:34

Re: Продолжим список...

Здравствуйте!

По поводу алгоритмов хочу привести один пример из своей жизни.
Разбирался я немного с OpenJpeg биболиотекой по кодированию файлов в формате Jpeg2000 (в нем применено вейвлет-преобразование вместо DCT, поэтому при больших степенях сжатия - раз в 100 - качество гораздо лучше чем у обычного Jpeg).

там был такой кусок кода:
for (i = 0; i < sizeof(t1_flags) / sizeof(int); i++)
((int *) t1_flags)[i] = 0;
- каждый раз чистился массив размером в 1мегабайт, из-за чего все жутко тормозило. после очистки массива только нужной размерности все заработало быстрее.
вот такая простая оптимизация.

помимо техники, есть еще и программист. и многое зависит от того как составить алгоритм.

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

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


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


С уважением, Дмитрий

От Elliot
К DVK (12.10.2005 15:01:34)
Дата 13.10.2005 11:42:10

Re: Продолжим список...

>там был такой кусок кода:
> for (i = 0; i < sizeof(t1_flags) / sizeof(int); i++)
> ((int *) t1_flags)[i] = 0;
> - каждый раз чистился массив размером в 1мегабайт, из-за чего все жутко тормозило. после очистки массива только нужной размерности все заработало быстрее.
>вот такая простая оптимизация.

Мда... Программист, однако совсем дятлом был, коли memset не поюзал :-).

От DVK
К Elliot (13.10.2005 11:42:10)
Дата 13.10.2005 14:18:20

Re: Продолжим список...

Здравствуйте!

>Мда... Программист, однако совсем дятлом был, коли memset не поюзал :-).

кстати, memset тут не поможет :)
теоретически, хороший компилятор не даст почувствовать разницу :)

вот что они мне написали в ответ на мое замечание, так что они не _совсем_ "дятлы" :)

Hello Dmitry,

Thanks for helping us optimizing the OpenJPEG code.
Indeed, the erasing algorithm in t1_encode_cblk and t1_decode_cblk is
very slow.

To speed things up, we decided to use the "memset" function to erase the
memory used by t1_flags and t1_data.

The coding and decoding now only takes 2/3 of the time it used to!!!

Thanks a lot for you help,

François

С уважением, Дмитрий

З.Ы. кстати, эта библиотека, ИМХО, лучшее что есть в сети про Jpeg2000 на языке С.