small and easy speed improvements

Discuss the future of Warzone 2100 with us.
User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: small and easy speed improvements

Post by kage » 11 Dec 2006, 09:24

Watermelon wrote: If the 60 frames/sec is true,there must be something horribly wrong within the code,the original 1.1x wz runs alot faster(cpu-wise,not graphics-wise,since the renderer has changed alot) with 1000 ticks/sec...
i thought it was pretty well excepted that there was something horribly wrong with the code, even before this came up

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: small and easy speed improvements

Post by DevUrandom » 11 Dec 2006, 20:06

I don't think you can get the current code to run at 1000fps or anything near that...
I didn't try to disable the graphics and check the raw ticks for reasons you might guess...
And yes, I think the renderer is hurting performance a lot...

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: small and easy speed improvements

Post by kage » 11 Dec 2006, 23:57

DevUrandom wrote: I don't think you can get the current code to run at 1000fps or anything near that...
I didn't try to disable the graphics and check the raw ticks for reasons you might guess...
And yes, I think the renderer is hurting performance a lot...
it was well known that back in the closed source days that a player with the fastest computer was more likely to win in any given, otherwise evenly-matched, tank on tank battle during multiplayer. it was equally well known and had been proven that a player with the fastest computer researched, built, and produced the fastest (and presumably could fire lassats slightly more often). later it was said that this was fixed after we got the source. now at that time (while the game was still closed source), this pointed out two seemingly obvious things:
  • warzone multiplayer didn't really work on via the "single authoritative host" philosophy, but in a equally-shared-authority manner among all players: each player managed all their own units and sent "my tank #7 just hit your tank #3... deal with it".
  • the engine did not use scheduling (and still does not) to measure time, and that, at that time, each comp tried to process as many ticks per second as possible, and those comps which were pushed along the progress of their vehicle's reloading that much faster than the slow comps, as well as completing just a little bit more of the research: anything that took a length of time, right down to vehicle movement happened faster, even if slightly, on fast comps. when the effect was multiplied in a battle between 30 units, that would give an obvious advantage to a slow comp with a force of equal size, or after 40 minutes of continuous research, the faster comps may have been able to get an extra topic or two researched compared to the slower comps.
correct me if i'm wrong, as i certainly don't wan't to discredit any person's contribution, but i'm pretty sure we didn't fix the problem... when sdl support was added, and the cap was set to 60 frames per second, which quite possibly forces only 60 ticks per second (as evidenced by the renderer being in the same gameloop and thread as everything else), then the maximum number of ticks per second was simply brought down to a more managable level, and if someone wanted to get that advantage again, all they'd have to do recompile with a higher SDL_setFramerate.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: small and easy speed improvements

Post by DevUrandom » 12 Dec 2006, 01:12

Actually the framerate limitation happened much later, when someone (karma?) requested to limit the ressource usage and Per found some code (those two SDL_ files in framework) in the SDL_gfx project to limit the framerate, which I then included into Warzone.

I don't really know how it works that you can finish your research earlier than you should. I thought WZ uses some kind of timing mechanism... The only problem that might occur is when the client doesn't manage to keep up with the load and thus falls behind, slowing down it's research/production/whatever...

But I don't have no clue about playing Warzone and I never played it "in the old days", so just ignore me if I'm talking nonsense. ;)

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: small and easy speed improvements

Post by kage » 12 Dec 2006, 01:49

DevUrandom wrote: I don't really know how it works that you can finish your research earlier than you should. I thought WZ uses some kind of timing mechanism... The only problem that might occur is when the client doesn't manage to keep up with the load and thus falls behind, slowing down it's research/production/whatever...
that's exactly how it would work: since there was a hard maximum of 1000 ticks per second, and there was literally no concept of checking with the system clock and scaling all actions during a tick based on the achieved ticks per second, even though the difference between a fast machine and a slow one was only noticable after 30 minutes (though using a stopwatch showed that doing stuff like building a factory from scratch to level 3 took 5 or so less seconds on a ghz range comp compared to a low mhz range one).

now, we can try to fix this problem, and sync everything between clients, but there's really no point: if we seperate out the code to where we can have a pure client/server setup, and the ability to build a command-line dedicated server, then it's a moot point, since no matter what, there'd only be one authority, and everything the client sees would come from the dedicated server -- the maximum amount of time a research or build order would be out of sync would be around a second or two at the max, but that would be per-action in this case, as opposed to the current situation where there's a cumulative rising gap between fast and slow clients.
DevUrandom wrote: But I don't have no clue about playing Warzone and I never played it "in the old days", so just ignore me if I'm talking nonsense. ;)
i haven't ignored you yet: you must be making some kind of sense.

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3773
Joined: 03 Aug 2006, 19:39

Re: small and easy speed improvements

Post by Per » 12 Dec 2006, 16:48

kage wrote: not everyone has a good compiler.
1985 called and wants its compiler back.

Seriously, early variable *declarations* has nothing to do with speed. Too early *initialization* does. Readability of code is more important, though, and moving variable declarations to the smallest scope is good for readability (and speed if this moves initialization), while sprinkling them throughout code as C++ allows, is just bad. And as karma said, the most important thing is getting the algorithms right. Getting algorithms right is easier in easily readable code :-)
"Make a man a fire, you keep him warm for a day. Set a man on fire, you keep him warm for the rest of his life."

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: small and easy speed improvements

Post by DevUrandom » 12 Dec 2006, 20:49

So late initialization is better??
I think I was teached by my book that I should initialize as soon as possible, because the compiler/CPU/PC/whatever can then immediately create the variable with it's contents and doesn't need to do this in 2 steps...

Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3773
Joined: 03 Aug 2006, 19:39

Re: small and easy speed improvements

Post by Per » 12 Dec 2006, 21:31

DevUrandom wrote: So late initialization is better??
I think I was teached by my book that I should initialize as soon as possible, because the compiler/CPU/PC/whatever can then immediately create the variable with it's contents and doesn't need to do this in 2 steps...
Whether there is anything at all to be gained from early initialization because of a compiler's stupidity depends on the compiler. I am pretty confident gcc4 will not fall for it. Doing tricks like that to outsmart the compiler is generally not a good idea. Early initialization often is not a good idea for speed, such as in cases like this:

Code: Select all

int value = expensive_function_call();

if (something) return 0;

return value * something_else;
where any supposed tiny gain because you did initialization and declaration at the same time is eaten up hundredfold by an expensive function call you might not have needed.
Last edited by Per on 12 Dec 2006, 21:38, edited 1 time in total.
"Make a man a fire, you keep him warm for a day. Set a man on fire, you keep him warm for the rest of his life."

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: small and easy speed improvements

Post by kage » 12 Dec 2006, 22:59

Per wrote: Seriously, early variable *declarations* has nothing to do with speed. Too early *initialization* does. Readability of code is more important, though, and moving variable declarations to the smallest scope is good for readability (and speed if this moves initialization), while sprinkling them throughout code as C++ allows, is just bad. And as karma said, the most important thing is getting the algorithms right. Getting algorithms right is easier in easily readable code :-)
c and c++ are low level languages by design (if you do anything, it's because you want it done, and right then): afaik, with all compiler optimizations off, variable declaration always implicitly mallocs, even when you're declaring pointers.
DevUrandom wrote: So late initialization is better??
I think I was teached by my book that I should initialize as soon as possible, because the compiler/CPU/PC/whatever can then immediately create the variable with it's contents and doesn't need to do this in 2 steps...
not so much "as soon as possible" as specifically initializing the variable in the very same statement as declaration, right? even then, if i'm right above, a completely non-optimizing compiler would generate assembly that was equivalent to declaring the variable on one line, then setting it on the next, wheras a somewhat optimized compiler would generate assembly that would retain the variable's memory address in a register so that it wouldn't have to do a symbol lookup again before setting the variable.

a very optimized compiler would find a variable declaration, and implicitly relocate and merge it with the initialization statement (unless initialization started within a loop). however, there are times when it is beneficial not to have this optimization: for example, if you have an extremely time-critical operation where you can't miss a cpu cycle, you might want declaration of all needed variables to occur at a time before the program is counted on for speed (during program initialization, for example); since such programs are fairly rare, it is usually ignored, and most or all optimizations are always preferred, but that doesn't mean they are always desired (something like a digital bomb diffusing program might be an example of a program that needs to save every proc instruction it can once the task begins).
Per wrote: Whether there is anything at all to be gained from early initialization because of a compiler's stupidity depends on the compiler. I am pretty confident gcc4 will not fall for it. Doing tricks like that to outsmart the compiler is generally not a good idea. Early initialization often is not a good idea for speed, such as in cases like this:
i don't think i've heard of anyone who wants to "outsmart" their compiler -- if the same effect is achieved, it's usually by being unfamiliar with the way the compiler works, or worse off, because programmers are taught to adhere to ediquette (all variable declarations at the top, all includes at the very top), even when it is a really really bad thing to do (such as in your example below).
Per wrote:

Code: Select all

int value = expensive_function_call();

if (something) return 0;

return value * something_else;
where any supposed tiny gain because you did initialization and declaration at the same time is eaten up hundredfold by an expensive function call you might not have needed.
agreed. and that kind of example is the very reason for this post.

Chojun
Regular
Regular
Posts: 518
Joined: 25 Nov 2006, 17:49
Contact:

Re: small and easy speed improvements

Post by Chojun » 13 Dec 2006, 05:42

As I have never downloaded and ran anything developed in warzone post source-release, I'm oblivious.

Is the game really hurting that bad to consider small tweaks?  Or is this more of a discussion in "lets squeeze every last drop" ?

Declaring variables and not using them is not going to hurt performance.  The program has to grow the stack no matter what, and moving the stack pointer down a bit more (or even a lot more) than one would like is not going to hurt performance at all, so I think efforts in optimization could be spent elsewhere.

If you really want to increase performance, try unrolling some tight, high computational loops, especially those that utilize arrays.  Getting as many cache hits as possible can substantially increase performance.  I got a 4-5 fold performance increase in code that rotates an image by 90 degrees simply by unrolling the loops.

Also, as my algorithms instructor would say, a Bubble-sort, no matter how highly optimized, is still a bubble sort.  Consideration might need to be given toward making some fundamental changes to Warzone's program stucture if you're looking for a serious speed boost.
The best thing to do when your philosophies don't stand up to debate is to lock the thread and claim victory.

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: small and easy speed improvements

Post by kage » 13 Dec 2006, 10:42

Chojun wrote: Is the game really hurting that bad to consider small tweaks?  Or is this more of a discussion in "lets squeeze every last drop" ?
despite the topic title, i really meant it to be an "if you're adding new code" type tip.
Chojun wrote: Declaring variables and not using them is not going to hurt performance.  The program has to grow the stack no matter what, and moving the stack pointer down a bit more (or even a lot more) than one would like is not going to hurt performance at all, so I think efforts in optimization could be spent elsewhere.
increasing stack size doesn't hurt performance, since it's usually only done once, but allocating memory for a variable does occur much more frequently, and does require processor ops -- while in and of itself not noticable in terms of performance, putting them after parameter checks and other conditions that determine if a function should immediately return does not readily decrease the readability or rate at which you write new code, and in all cases (not counting compiler optimizations) does allow the processor to do less work.

in other words, "a small and easy speed improvement" when writing new code: whether or not the speed improvement would even be noticable on a 133mhz machine, it is an improvement that takes zero added programmer effort, and thus there's not any good reason to not utilize it when writing new code.
Chojun wrote: Also, as my algorithms instructor would say, a Bubble-sort, no matter how highly optimized, is still a bubble sort.  Consideration might need to be given toward making some fundamental changes to Warzone's program stucture if you're looking for a serious speed boost.
that's pretty much what i'm thinking about...

Post Reply