Re: [AD] Faster hsv_to_rgb()

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> x86 machine language has a small number of registers so one less variable
> will make a difference, especially if the function is called from another
> function that uses lots of variables.

Not quite. Modern compilers have smart register allocators that go beyond the 
'one variable == one register' scheme. By using basic liveness analysis of 
the function, one can see that the variable "x" is dead (its value is not 
subsequently used) at the end of the sequence:

    x = v * s;
    y = x * f;
    ... = v - x + 0.5f;

so it is very likely that the register used at ... will be that of 'x', 
whatever name you give to the actual variable.

> > +      x = v * s;
> > +      y = x * f;
> > +      z = v - x + 0.5f;
>
> Considering that the above equasion has been re-arranged so much since
> what it originally was in colour.c, is it really necessary to use z as a
> separate variable now that x is no longer used?

Necessary no, but more readable yes. And, actually, this may help the 
compiler to optimize the code because 'x' has a shorter live range so the 
register allocator will likely find it easier to assign it a hard register.

> The compiler should be smart enough to realise this, but I doubt that using
> 'z' instead of 'x' will increase readability.

Compare

   x = a + b;
   y = c +d;
   z = x * y;
   t = z + v;

with

   a = a + b;
   b = c + d;
   a = a * b;
   b = a + v;

Any reasonable compiler will produce exactly the same code for both, assuming 
that only the lastest assigned variable is live after the block.

> The only way to increase readability is to include the original code in
> comments so anyone looking at it can gain a clearer picture of how the
> algorithm works.

This would document the code, not increase its readability. Readability 
doesn't depend upon external factors.

> Also, most of the Allegro functions that use floats have equivalent
> functions that use fixed-point numbers, but the RGB<->HSV functions do
> not. Should there be? The problem is that in Allegro, all functions with
> fixed and float have float-versions with _f whereas the fixed versions
> have no such postfix. If we re-name the existing RGB<->HSV functions so
> they are rgb_to_hsv_f() and hsv_to_rgb_f() and write fixed-point versions
> using the original names, it would break the API as programs would have to
> be re-written to call the _f versions instead or use fixed-point numbers.
> The alternative is to post-fix the fixed-point version with _f but then,
> it would create an inconsistency in the API which is a bad thing. Or
> perhaps the fixed point versions could be postfixed with _fixed. If it is
> decided that there should be fixed-point equivalents, I'll volonteer to
> write them.

Thanks, but I don't think they are worth your time, at least as far as 
Allegro is concerned. I suspect that rgb_to_hsv_f() and hsv_to_rgb_f() are 
very little used, so they probably don't need to be seconded by functions 
that would be even less used.

> I also have code that does RGB<->HLS colour-space conversion. HLS is
> similar to HSV except the HSV colourspace is represented by a single
> hex-cone whereas the HLS colourspace is represented by a double hex-cone.
> That is, in HSV, when V is 1 and the Saturation is 1, the colours will be
> at maximum intensity, whereas in HLS, the output will always be white if L
> is 1, and the colours will be at their most colourful when L is 0.5 and S
> is 1. Should I submit that as well?

Is this HLS color-space in widespread use in the computer game world?

-- 
Eric Botcazou




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/