On  4 Dec, Sven Neumann wrote:

>> Check the code if you don't believe it. 
> Sorry, but that's exactly what I did before I posted the reply and I'm
> asking you to do that too. A simple benchmark prooves that the example
> you gave is wrong since the use of unsigned variables doesn't make any
> difference.

But you also do read my mails, do you? And I said clearly that it might 
make a difference in larger functions not that it necessarily betters 

Example? Ok, here you go, I subsituted an gint which is used for
a clearly positive range (1; length) by an guint. This is an arbitrary
example and doesn't give to much of a benefit though the function is
still simple.

--- paint-funcs.c.orig  Thu Nov 29 14:17:47 2001
+++ paint-funcs.c       Tue Dec  4 21:53:49 2001
@@ -343,7 +343,8 @@
   gdouble  sigma2;
   gdouble  l;
   gint     temp;
-  gint     i, n;
+  guint    i;
+  gint     n;
   sigma2 = 2 * sigma * sigma;
   l = sqrt (-sigma2 * log (1.0 / 255.0));

will lead to that difference in PPC assembly:

--- paint-funcs.backup.s        Tue Dec  4 21:52:45 2001
+++ paint-funcs.s       Tue Dec  4 21:53:57 2001
@@ -2298,7 +2298,7 @@
        .align 3
        .long 0x43300000
-       .long 0x80000000
+       .long 0x0
        .section        ".text"
        .align 2
        .type    make_curve,@function
@@ -2361,7 +2361,6 @@
        mullw 0,30,30
        neg 0,0
-       xoris 0,0,0x8000
        stw 0,12(1)
        stw 26,8(1)
        lfd 1,8(1)

This is just to prove you that it can make a difference.

> I haven't said that and you will have noticed that we've added lots of
> consts to the code recently.

And this is a good thing. It might break stuff exactly like the
"unsigned" case but it will lead to better code and is much cleaner.

> I didn't say optimization is a bad thing. I just doubt that the use of
> unsigned variables is worth the risk of introducing bugs it certainly
> bears. There are exceptions, but definitely not in the UI part of the 
> code you've changed recently.

I wouldn't have touched the UI code if it was more seperate from the

>> Bad luck, not from me.
> that, I call ignorance.

That I'd call lack of time and interest.

> No, since we announced that cleaning up the code is the major goal for
> 1.4. The way we target this is (in this order):
>  1. Move files into subdirectories that define subsystems and reduce 
>     the dependencies between these subsystems.
>  2. Clean up the code so it uses a common coding-style.
>  3. Make the code bug-free (this should involve writing test suites 
>     for the various subsystems).
>  4. Profile it.
>  5. Optimize it.
> Since we aren't even done with parts 1 and 2; can't you understand
> that we'd prefer not to start with 5 yet?!

Sure, but the changes were also part of your point 2, and it's never
to early to work on cleanliness.

> I didn't object to any of your modifications in the paint-funcs.

Great, but still I'm rather unhappy about the recent happenings and
that all of it happened in the public; you don't even respond to
private email.

> I'd say it's up to you at this point to proove your arguments. I've
> done my homework and benchmarked the use of unsigned vs. signed.

Don't even try to catch a difference using a synthetic microbenchmark;
do it on real code and you will see that it makes a difference.

Just to notice another thing before people start complaining, the
example above was done on PPC with gcc-2.95.4, any other architecture
or compiler might have different results but it's important to add
that any detoriation is a bug in the compiler so if done properly there
are only advantages to be had from it.


Gimp-developer mailing list

Reply via email to