Re: [help-GIFT] patch-fu

[risc]

Jonas:
Yes, not doing a calloc() every time through improves performance by arround 5%.

David,

it is my intention to expand the image size handling of the feature extractor 
as soon as i'm done with performance hacks, however, the curent code wont 
properly process an image larger than 256x256. therefore, i think allocating
the array automatically, to the MAX_WIDTH and MAX_HEIGHT is appropriate.

On Thu, Aug 17, 2006 at 12:09:05PM +0200, Jonas Lindqvist wrote:
> Julia:
> Is the "double conv[65536]" related stuff really needed for the  
> performance improvements?
> 
> David:
> The feature-extractor is obviously capable (at least before these  
> patches) of dealing with images of sizes other than 256 by 256.
> If I were to alter gift-add-collection.pl to resize the images to  
> something other than 256x256, how would that affect the results of a  
> query to the giftserver?
> 
> /Jonas
> 
> 
> 
> 17 aug 2006 kl. 11:13 skrev David Squire:
> 
> >Jonas Lindqvist wrote:
> >>Hi!
> >>
> >>I feel an urge to ask some questions... (Perhaps silly, but  
> >>anyway... I know I could probably find the answers by digging in  
> >>the code a bit deeper, but I admit I'm lazy...)
> >>
> >>* The function gabor_filter, in gabor.c, now uses a fixed array of  
> >>65536 doubles, instead of callocing the size indicated by the  
> >>width and height that are passed as parameters to gabor_filter 
> >>(...). Very well...
> >>Are the width and height always 256, or can they be 128*512 or  
> >>2*32768 or whatever?
> >
> >That is not a change I would approve. The width and height are  
> >presently
> >always 256x256, but this was always intended to be a temporary  
> >measure.
> >Code that does not need this assumption should not make it. The code
> >should be kept as open for extension and generalization as possible.
> >
> >>
> >>* I guess that most modern CPUs have some kind of SSE2-ish  
> >>features that gcc could use, but what would the effect of the  
> >>patch be for an architecture that lacks it? (Something seriously  
> >>old, pre MMX, or something else that perhaps one would not use for  
> >>this application anyway...)
> >>
> >>* Wouldn't memset be faster than looping and setting to zero?:
> >>    for (i = 0; i < width*height; i++)
> >>      {
> >>        conv[i]= 0;   /* needs to be zeroed */
> >>    }
> >
> >calloc should handle this.
> >
> >>and isn't width*height always 65536?
> >>
> >
> >See my comment above.
> >
> >I've just got back from a few weeks away from the internet. Much  
> >catching up to do...
> >
> >Regards,
> >
> >David
> >
> >
> >
> >-- 
> >Dr David McG. Squire, Senior Lecturer, on sabbatical in 2006
> >Caulfield School of Information Technology, Monash University,  
> >Australia
> >CRICOS Provider No. 00008C        http://www.csse.monash.edu.au/ 
> >~davids/
> >
> >
> >
> >
> >_______________________________________________
> >help-GIFT mailing list
> >address@hidden
> >http://lists.gnu.org/mailman/listinfo/help-gift
> 
> 
> 
> _______________________________________________
> help-GIFT mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gift