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.
> yes, but it is not nice to remove it while Kelly was working on this
> part of the code.
Yes, that wasn't nice, apologies to Kelly..... though I can imagine
better forms of debugging code than commented out printf's....
> the side effects of unsigned integers are not what people are used to
> think about when designing an algorithm. You are changing the
> mathematical base in an unneeded and hardly foreseeable way. Code that
> looks correct and used to work fine, suddenly starts to behave
> wrong. I doubt that you've checked each and every usage of the
> variables you changed lately.
I was about to check in another followup patch which would have
cleared some of the maybe-problems this might have created though
you can scratch this idea now.
> 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?
> what are you aiming for, GIMP-embedded?
Actually yes.
> You are speaking about ~1.3 KB
> of object size reduction. This is ridiculous and there are certainly
> other parts of The GIMP that can be made much slimmer with a less
> error-prone approach. I also doubt that the code size reduction or
> speed improvement originates in the use of unsigned variables.
This was part of a general cleanup to better understand where the flow
can be optimised, it wasn't meant to be the huge-improvement-for-free
change but I also had cleaness and optimisation in mind when doing so.
> It would surprise me very much if it would make any difference for the
> compiler.
It surprises me that you're surprised instead of checking the situation
in real life.
> Signed and unsigned variables are treated the same in almost
> all situations.
I'd restrict that to "many situations".
> 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.
> 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?
> First, it is way too early to start optimizing the code in a whole.
I disagree, for microscopic changes out of nowhere - yes, but I
had some bigger plans in mind.
> Then, only code that is finished, working and stable should be
> optimized to make it possible to catch errors introduced by the
> optimizations.
> Last, only code that showed up in a profile is worth to be optimized.
You're telling me that? Surprising, I remember it was you who asked
me how to profile code, right?
> What needs to be done at the moment is to give the GIMP core a
> well-defined structure, to document and to debug it.
I have a smallish patch to document the functions and structures
I've been modifying, but since cleaness doesn't seem to be a valid
point except when it comes to GObjects - so be it.
> 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.
> then use them there for god's sake. But please, stop going over other
> peoples code
I have a hard time understanding what you're trying to tell me, though
I can easily judge that most of the code you're touching isn't yours
either. That's free software development, be welcommed.
> that you don't understand
I don't think you can tell whether I do understand the code I've
modified or not.
> and stop applying your so called optimizations to it. Thank you.
I guess I have no choice here. It's hard to apply anything without
having permission to do so, so there's no point to pseudo-kindly ask
me not to do it.
Anyway, except there show up some really technical arguments, this is
EOT for me. YOU asked me not to touch GIMP 1.2 and HEAD anymore and I
will stick to that; your wish is my command and thanks for the fish
Happy developping.
--
Servus,
Daniel
