IronPeter
а boost::pool хорош?
> Расчет координаты попытайся закешировать, сохранив массив смещений. Когда мы
> работаем по строчкам, то эти смещения постоянные.
хм, скорость тогда увеличится еще раза в два, спасибо :)
keltar
> Что там такое жуткое делается, что упёрлись в скорость аллока?
как минимум три аллока, итого ~ 30мс. зачем тогда оптимизоровать код, если закрывать глаза на такие нюансы?
Можно координаты для src считать во время копирования, а не до, если использовать fixed point возможно даже будет быстрее для такой фильтрации без усреднения, думаю, что будет, но не проверял, интересно было бы увидеть числа (время). Для больших разрешений надо проверить как там с точностью будет.
Если размеры dst кратны степеням 2, то можно бесплатно сделать разворот внутреннего цикла, на 4, 8, 16, и т.д. итераций.
Дальше остается подстраиваться под отношения разрешений src и dst, делать быстрые ресайзеры частных случаев (2x2 -> 1x1), либо "компилить" оптимальный ресайзер для каждого.
Проблему аллокаций очевидно можно решить просто и грубо, заранее взять больше памяти, и написать свой примитивный и быстрый аллокатор.
Ну да, и без фильтрации не интересно.
быстрей, ещё быстрей!
системный тик 10мс
Мать-мать. Аж с перепугу проверять полез, 65535 аллоков улетело за ~200мс. Если три за 30, тогда трындец и надо стековый аллокатор, пул и прочее. Не, правда, всё так плохо? Или аллок огромного блока под текстуру совмешён с его memset(0)? (что ещё может так тормозить - не предположу)
У меня когда-то была функция для ресайза такая:
// Приведение текстуры к нужному размеру // type - количество цветовых компонент // data - старое изображение // data2 - новое изображение void CopyResize (int oldX, int oldY, int newX, int newY, int type, char *data, char *data2){ float resizeX = ( float)oldX/newX, resizeY = ( float)oldY/newY; for( int line=0; line<=newY-1; line++){ for( int seg=0; seg<=newX-1; seg++){ for ( int i=0; i<type; i++){ int offset1 = int( line*newX+seg)*type+i; int offset2 = int( line*newX*resizeX+seg*resizeY)*type+i; *( data2+offset1) = *( data+offset2); } } } }
Сейчас использую функцию iluScale(); из библиотеки DewIL.
namot
> Можно координаты для src считать во время копирования, а не до,
да, я тоже про это подумал. попробую
keltar
> Мать-мать. Аж с перепугу проверять полез, 65535 аллоков улетело за ~200мс
200мс/65535 = 0,003мс на одну аллокацию? что-то не верится. покажи код полностью как тестировал. какой размер блоков? компилятор?
#define N 65535 #define BLOCKSIZE 1024*1024 uint64_t timepad = get_time(); void *ptrs[N]; for( int i = 0; i != N; ++i) { ptrs[i] = malloc( BLOCKSIZE); } uint64_t timeresult = get_time( ) - timepad; printf( "%lld\n", timeresult);
Компилял на gcc 4.3 и sun studio 12. Внутри get_time соответственно gettimeofday.
Блоки по мегабайту; на мелких пошустрее, но не в разы. Если разбавить вычислениями/логикой - конечно будет помедленее, но не в тысячу же раз.
keltar
хм, накидал такой вот тест
http://www.everfall.com/paste/id.php?krd1zo0d9quz
к своему удивлению обнаружил, что аллок блока на 1 Мбайт составляет 0,003мс, как ты и говорил. значит в моем коде где-то сильный косяк.
PS. у тебя 65535 аллоков по 1Мбайт - это 65Гбайт. мощно :)
Особенности виртуальной памяти :-)
Я к чему говорил-то - аллок тормозит в больших количествах. Почему меня это и удивило.
А по поводу "не выделять память": конкретно в указанной ситуации - что-то мешает взять большой буфер с запасом, и в него класть любую картинку? Ну реаллочить его по мере роста, если совсем критично не_знать_максимальный_размер, скажем.
keltar
ну смотри, возьмем худший вариант, максимум 5 аллоков на полный ресайз с фильтрацией, с мипмапами и т.д.
0,003мс * 5 = 0,015мс
для моего случая это мизер. вообщем, пока аллоков мало - по данному поводу заморачиваться не буду :)
Нет ничего проще. Изменить размер изображения без потери качества на GPU. Если размер изображения слишком большой для GPU, то разрезать большое изображение на мелкие. Изменить размер на GPU до нужного размера для каждого. Снова склеить изображение.
Lamer007
wtf???
Помимо того, что ты не умеешь внимательно читать, ты еще не догадался посмотреть на дату.
Тема в архиве.
Тема закрыта.