Re: [boost] GIL Image Processing Library - responses and morecomments

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-18 20:09:49

> > 
> > GIL incorporates a mechanism for active reduction of code 
> bloat due to 
> > variant instantiations. I will present this approach at the LCSD 
> > workshop in the upcoming OOPSLA conference, which is in less than a
> > week: http://lcsd.cs.tamu.edu/2006/
> > 
> 
> I'd like to read this paper.

I apologize but I am not allowed to post the paper due to copyright
issues.
In a nutshell, when you invoke, say, a binary algorithm on a variant of,
say, 10 types, you get 100 algorithm instantiations. 
This is often done via double-dispatch in which case you have 10+1
switch statements with 10 cases each.

It is often the case that many of these instantiations will be identical
at assembly level. Consider, for example, copy_pixels(rgb8,rgb8) and
copy_pixels(lab8,lab8). GIL has a mechanism that identifies algorithm
instantiations that are assembly-level identical and instantiates them
only once. It also optimizes the above-mentioned double-dispatch. In
particular, it turns this into a single switch statement containing just
the appropriate set of cases (typically far fewer than 100). It results
in code that is both faster and smaller, and sometimes compiles faster
(though on average compiles a lot slower).

This optimization is disabled by default, primarily because it makes
debugging harder and it can take a toll on compile time. But it is
useful to enable it if you use variants extensively and care about code
bloat. Some compilers already can detect and reuse assembly-level
identical instantiations in which case this technique results in only
marginal improvement.

The code is inside the dynamic_image extension. The flag is
GIL_REDUCE_CODE_BLOAT

Lubomir