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
anything.
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
.LC5:
.long 0x43300000
- .long 0x80000000
+ .long 0x0
.section ".text"
.align 2
.type make_curve,@function
@@ -2361,7 +2361,6 @@
.L1202:
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
rest.
>> 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.
--
Servus,
Daniel
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
