> On  4 Dec, Sven Neumann wrote:
> > this is not true. Please stop spreading this nonsense about unsigned
> > integers being more performant than signed ones. Go and write yourself
> > a simple benchmark for the code you mentioned above and you will
> > notice that it doesn't make any difference at all.
> Heck, you clearly demonstrate that you've no idea what you're talking 
> about. unsinged types are not necessarily leading to faster code
> but they sometimes enable better optimisation possibilities for the
> compiler because every single fact the compiler knows aditionally about
> types or functions like pureness, constness or staticness (of functions)
> will lead to additionally hints the compiler notes in is internal
> representation and will lead to more optimal code for the narrowed
> purpose.
> 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

> > IMO using unsigned integers is a concept from the stone-age of
> > programming when CPUs and compilers used to be crap and the use of
> > unsigned values gave a real speed gain.
> Right, we should just use signed values and scratch all inlines, and
> consts since compilers are clever enough to figure it out anyway.
> Are you really believing what you're saying? When Marc and I where
> experimenting at Mitchs place we figured out that providing additional
> hints to gcc via non-portable attributes gave the compiler quite some
> chances to optimise better it was you who said that we might want to
> add this in macroized form to GIMP and now you're telling that compilers
> are clever enough anyway to not get any advantages from such hints?

I haven't said that and you will have noticed that we've added lots of
consts to the code recently. The main purpose was to catch bugs though.
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.

> > If you are about to optimize parts of the GIMP, the first thing you
> > should do is write a test suite and benchmarking facility for this
> > part of The GIMP.
> Bad luck, not from me.

that, I call ignorance.

> > No optimization should be allowed without such a test suite.
> I disagree, there are for sure many algorhythms which can be
> optimised complexity wise and with micro changes but flow changes
> can hardly be benched without a macro benchmark and since you 
> object to branches in CVS there's hardly any way this will ever 
> happen since once cannot do major surgery in the flow without having
> a change to do it in smaller steps.
> Anyway, since no benchmark is available and the hooks to add one
> are rather unsatisfying one will have to use indicators to optimise.
> I'm personally using gprof, gcov, gcc -save-temps and diff to tell
> whether an improvement is there. You don't want optimisation - then 
> go without it; not my problem....
> > Well, going through the code like a berserk doesn't really help here.
> Great, so this is your word to stop doing so as well?

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?!

> > A few small encapsulated areas like the paint-funcs can be optimized
> > now and if benchmarks proove that the use of unsigned variables speeds
> > things up,
> It did speed up, I just can't tell exactly how much because there is
> no benchmark.

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

> Anyway, except there show up some really technical arguments, this is
> EOT for me. 

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.

Salut, Sven
Gimp-developer mailing list

Reply via email to