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

["Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>]

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

On Fri, 18 Jun 2004, rwetmore@xxxxxxxxxxxx wrote:

> <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.

This would send the developers in a wild goose chase to convert the code
to a different language, stalling development of new features, which is
what users actually care about. As a developer, I also happen to think
developing new features is more interesting than painful and fruitless
efforts of porting to a different programming language.
The fact is C does not seem to be constraining development,
so I see little sense in changing a winning combo.

> 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.

> 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.

Did you actually bother to look at the code? I did and his comparison is
totally baseless because no decent C++ programmer would code C++ that way.
It even has several nasty bugs. This test is also heavily compiler/library
implementation dependent. Other people have refactored the C++ code, used
ICC, and had different results.

You would additionally be adding a dependency that most distributions do
not carry. RedHat and most other distros does not carry the Sun JVM
because of licensing issues. So you compromise and use gcj instead. Which
comes with an incomplete Java API implementation (libgcj) and likely
produces slower code than the server JVM.

It would take a better test than this to convince me and the test would
necessarily have to be using pure OSS tools. Or else we risk losing
the Linux distros that presently bundle Freeciv.

> 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.

This is not a purge, it is a minimal effort to gain some speed. And
inline functions are a standard C feature. So why not use it...

> 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.

Adding const (what Per did) is actually a good programming practice that
makes code clearer by making it evident if that argument is modified by
the function or not. But yes, it makes things harder for people which have
patches in the queue.

> 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 ...

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa