[Freeciv-Dev] Re: (PR#8982) City.c cleanup

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8982 >

Something that probably will be useful in deciding what Freeciv 2.0 might
look like. But the issues with C++ and migration from C for whatever partial
rationales is also something that deserves consideration given the newer O-O
languages and their performance relative to the older ones with their
associated problems.

Hopefully the mandate for Freeciv developers is sill to develop gaming
code and not engage in Computer science projects like overhauling code to
satisfy C/C++ religious mantras. The time for overhaul is at major version
startup, with appropriate considerations of how things will be stabilized
over the next release cycle - not by backdoor efforts to subvert release 
rules after they have been laid down.

Cheers,
RossW
=====

Java vs C++ "Shootout" Revisited
by Jeremy Geelan

(June 17, 2004) - "I was sick of hearing people say Java was slow," says 
Keith Lea, "so I took the benchmark code for C++ and Java from the now 
outdated Great Computer Language Shootout (Fall 2001) and ran the tests 
myself." Lea's results three years on? Java, he finds, is significantly 
faster than optimized C++ in many cases. Lea used G++ (GCC) 3.3.1 20030930 
(with glibc 2.3.2-98) for the C++, with the -O2 flag (for both i386 and 
i686). He compiled the Java code normally with the Sun Java 1.4.2_01 
compiler, and ran it with the Sun 1.4.2_01 JVM. He ran the tests on Red Hat 
Linux 9 / Fedora Test1 with the 2.4.20-20.9 kernel on a T30 laptop. The 
laptop "has a Pentium 4 mobile chip, 512MB of memory, a sort of slow disk," 
he notes.

The results he got were that Java is significantly faster than optimized C++ 
in many cases.

Jason Short wrote:

> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8982 >
> 
> rwetmore@xxxxxxxxxxxx wrote:
> 
>>>>I'm not sure that changing arbitrary static functions to inline is a
>>>>good idea.
>>
>>Changing things to inline was discussed, shown to be a bad thing with no 
>>real redeeming features beyond performance degradation and has thus been 
>>preferentially adopted as usual :-).
> 
> We're not talking about changing macros to inline.  We're talking about 
> changing non-inline functions to inline.

No, clearly This is talking about introducing inline functions - overruling 
the longstanding forbidden rule in Freeciv that has become the latest target 
for mass revision of the source. With no redeeming features this just wastes 
development time that could be better put to use improving both features, 
robustness/maintainability and performance instead of further degrading it 
as has become the practice with these now endemic source code
purges.

However, it does obsolete lots of waiting patches that reduces the amount of 
feature change in the source from NIH contributions and load on maintainers 
to actually review and complete others hard work.

>>>Now, why does freeciv run slower with my patch? No, it does not have
>>>anything to do with inline, since it runs even slower without it... Does
>>>const give slower code??
>>
>>Changing things to function calls adds enormous performance degradation, 
>>only partially and occasionally recovered by inlining since this is now an 
>>optional compiler element. If you want performance (no longer true it 
>>appears), then you need to use real "C" elements like macros that give 
>>guaranteed results. You also need to understand when some constructs are 
>>being treated as static or const and what the difference is in the code 
>>optimization context that you are destroying in ways similar to inlining.
> 
> 
> Per didn't change anything to a function call.  He merely added "const" 
> modifiers to parameters of existing functions.  Evidently this does slow 
> down execution, under his compiler anyway.  You'd probably have to look 
> at a disassembler to find out why.

Are you sure ... did *you* look at what the optimized state was provided it 
is even possible to get a realistic handle on it since optimization is 
"optional" and not hardcoded as would be the case if these "functions" were 
provided as trivial macros not functions to be turned into inline by the two 
step backdoor process.

Do you understand the const vs the inline optimizer code sections in gcc, in 
any other compiler environment? What is the Windows degradation in pure MS, 
cygwin or MKS cross-compile environments? that on Sun, HP, IBM or Intel 
compilers in their various Unix environments? Not to mention what a lot of 
people developing in specializes niches like CE/QNX/realtime/microdevice 
where standard code would give them a great game to add to a distribution or 
just fool around with themselves and publish.

Do you have *any^ idea what you are doing to Freeciv code apart from adding 
useless restrictions while no longer spending time developing useful 
features and extensions for gaming playability ...

> jason