i thought it was pretty well excepted that there was something horribly wrong with the code, even before this came upWatermelon 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...
small and easy speed improvements
Re: small and easy speed improvements
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: small and easy speed improvements
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...
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...
Re: small and easy speed improvements
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: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...
- 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.
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: small and easy speed improvements
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.
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.
Re: small and easy speed improvements
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).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...
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.
i haven't ignored you yet: you must be making some kind of sense.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.
Re: small and easy speed improvements
1985 called and wants its compiler back.kage wrote: not everyone has a good compiler.
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."
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: small and easy speed improvements
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...
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...
Re: small and easy speed improvements
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: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...
Code: Select all
int value = expensive_function_call();
if (something) return 0;
return value * something_else;
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."
Re: small and easy speed improvements
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.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
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.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...
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).
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: 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:
agreed. and that kind of example is the very reason for this post.Per wrote: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.Code: Select all
int value = expensive_function_call(); if (something) return 0; return value * something_else;
Re: small and easy speed improvements
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.
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.
Re: small and easy speed improvements
despite the topic title, i really meant it to be an "if you're adding new code" type tip.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" ?
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.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.
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.
that's pretty much what i'm thinking about...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.