winXP 1.1.4 slow as hell
Moderator: Forum Moderators
Forum rules
Before reporting issues in this section, you must read the following topic:
Before reporting issues in this section, you must read the following topic:
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
No. premature optimization is optimizing before it is the right time to optimize. If you are optimizing code before you have it working and this optimization will result in more complicated code that will be harder to debug, then that is premature. There are other examples, this is merely meant to demonstrate that your definition is inadequate.Prometheus wrote:Premature optimization is when code is optimized without knowing whether it is a performance bottleneck or not. Obviously there are performance issues in 1.1.4, so premature optimization is not the issue.
No. read this slowly if you have to in order to understand what we are saying. Development releases are for DEVELOPMENT. The developers are not going to put performance as the most important value during the development cycle. For Stable releases, performance issues are a high priority. For development releases they may or may not be depending on the circumstances of that particular release. Taking working code and finding where to optimize is much easier than trying to get buggy optimized code to work.When performance issues appear, they should be dealt with immediately, otherwise you will have to go back and rewrite who knows how much code, which might prove effectively impossible.
As for the slow down, yeah I see it on my overpowered machine and it clearly is not acceptable for the long haul. If you wish to contribute, try identifying what in the code causes the slow down to occur. Merely pretending that you are important by spouting off what others must do for you without any compensation is a waste of bits.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...
-
- Posts: 117
- Joined: March 15th, 2006, 10:50 am
So, before any Linux developer checks in any code, they should run a benchmark analysis on Windows XP? Seems unlikely.
And, as for setting other people's priorities, it doesn't work very well here. Sorry, Prometheus, you have a valid point but you are not being realistic. As I said, the developers are working on these performance issues, and personally, I thank them for giving it their attention.
And, as for setting other people's priorities, it doesn't work very well here. Sorry, Prometheus, you have a valid point but you are not being realistic. As I said, the developers are working on these performance issues, and personally, I thank them for giving it their attention.
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Are you serious?ivanovic wrote:Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...
Even as the fingers of the two hands are equal, so are human beings equal to one another. No one has any right, nor any preference to claim over another. You are brothers. - Muhammed
No, it wouldn't be cross-platform. Think of all the complaining if they dropped Windows versions altogether.Anyar wrote:Are you serious?ivanovic wrote:Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...
Hope springs eternal.
Wesnoth acronym guide.
Wesnoth acronym guide.
Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.scott wrote:No, it wouldn't be cross-platform. Think of all the complaining if they dropped Windows versions altogether.Anyar wrote: Are you serious?
Even as the fingers of the two hands are equal, so are human beings equal to one another. No one has any right, nor any preference to claim over another. You are brothers. - Muhammed
-
- Posts: 837
- Joined: April 14th, 2005, 4:17 am
Are you sure this won't result in problems due to different operating systems?ivanovic wrote:Since there are such massive speed problems we just came to a decission on how to fix this in our irc channel. It is simple and we should have had this idea before:
We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
If you do not hear anything from a dev anymore that may be due to heavy work on rewriting wesnoth. And don't start to ask something like "Daddy, is it already completed? When will the assembler version be ready? Oh Daddy, I want it now...". We will as Devs hope to accomplish this task in less than one year, but it will take it's time. Until this has happend you should go on testing 1.1.4...
Right, he forgot to put that in a [sarcasm][/sarcasm] tagILikeProgramming wrote: Are you sure this won't result in problems due to different operating systems?
http://www.wesnoth.org/wiki/User:Sapient... "Looks like your skills saved us again. Uh, well at least, they saved Soarin's apple pie."
Users should be forbidden to make demanding or impolite requests.Anyar wrote:Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
So, to sum it up into something that would be very beneficial to apply to many users on this forum, both dev and user: people should be forbidden to behave like asses.torangan wrote:Users should be forbidden to make demanding or impolite requests.Anyar wrote:Phew... I wasn't sure whether or not that was for real. Devs should be forbidden from using sarcasm around the general population.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
There's the rub. You seem to think that developers are experts in all part of the code and for all OS. This is generally false. Developers are generally experts in whatever features that they have added or modified. They also don't generally add features when they notice that there is a performance hit on whichever OS and computer they are working on. They also generally react quickly to slow downs that are obvious enough that they are quickly identified by others when they update their version of the code shortly after the feature is added. Thus performance hits that make it into the repository are usually the result of interactions between features committed by different developers. In order to track these down generally requires that someone with a system where the slow down is noticable takes the time to do a binary search on the revisions to figure out where there specific slow down becomes noticable (hopefully it occurs noticably in a small range of commits and not as a result of several small incremental performance hits). To add complexity to the situation, sometime slowdowns occur as a result of interactions between the code and the configuration files and so only occurs when certain WML tags are active.Prometheus wrote:When I say deal with performance issues immediately, I mean before adding new features, not before debugging.
And I am not asking anyone to do anything for me. If anything, I am asking people NOT to do things. Specifically, do not add new features before performance issues are solved.
So, with all that, why would a developer stop his work on his feature set to hunt down slow downs probably caused by some other features that he knows nothing about? Answer, he won't during the normal development cycle. When a slow down can be isolated to code that is in his area of expertise, he likely will attack it. Also when preparing for a STABLE release, there will be a greater effort to identify where performance hits are coming from. It would be great if we had a developer devoted to tracking the game performance to identify what commits resulted in slow-downs across a multitude of platforms, but this is not a very interesting job and requires multiple OSs to work on, so instead it is generally left to the ad-hoc searches for particular problems when they are noticed. If you are interested in spending time identifying the sources of performance hits, then please do. Pointing out that there is a slow down can be helpful. Announcing that others must drop everything and hunt for it is counter-productive. If on the otherhand, you wish to pay me or one of the other developers who are currently donating our free-time to work on wesnoth full-time, then we might listen to such a request. Until then recognize that if performance is a priority for YOU, then YOU need to do something about it, not expect others to.
"you can already do that with WML"
Fight Creeeping Biggerism!
http://www.wesnoth.org/forum/viewtopic. ... 760#131760
http://www.wesnoth.org/forum/viewtopic. ... 1358#11358
Do you think we can use macros to generate code on separate processor types using one code base or will that slow things down too much.ivanovic wrote: We will completely rewrite the game. This time we won't use C++ since it obviously is too slow for wesnoth. We want to get the best optimisation possible so we will directly write machine code aka assembler. Since this is not such a trival task expect the next Wesnoth release in nothing less than six months to one year, we will need our time.
What processors do you think are worth supporting?
We will probably need to write custom video card drivers as well.
I think this is likely to take more than a year.
I'd say we should in general support plain i686 compatible CPUs plus G4 compatible CPUs. This should be enough for most users. maybe we might even need two years but since it is better to have a very performant release for everyone than only adding one or two new features most users will understand this. i Think using macros for porting would not be this good since we could end in having the same bottlenecks we have now. Rewriting the graohic cards drivers might be a really good idea. Maybe this way we could optimise the drivers for complete rewrites of the screen...
So overall we will need two branches, one for i686, one for G4 (ppc compatible). Though we will really have to limit the supported graphic cards due to incompatible specs.
So the simple question is:
Arte users willing to wait for such a highly optimised version that will only work on <50% of the available hardware or are you willing to wait for a stable version that might be working nicely?
Users having speed problems could also compile theirself with heavy optimisations for their CPU. We can't deliver such a build since only some users could use it.
The best thing would be if those having speed problems would give some more details like the exact situations when the speed goes down. Also testing various revisions in the svn and telling where the speed did drop will be really helpfull. So instead of only complaining and wanting "the devs" to do something, try to help the devs. If you only claim to get changes nothing will change. So better try to help us a little and speed might improve. Taking our time in discussions that do not make any sense won't help anyone.
So overall we will need two branches, one for i686, one for G4 (ppc compatible). Though we will really have to limit the supported graphic cards due to incompatible specs.
So the simple question is:
Arte users willing to wait for such a highly optimised version that will only work on <50% of the available hardware or are you willing to wait for a stable version that might be working nicely?
Users having speed problems could also compile theirself with heavy optimisations for their CPU. We can't deliver such a build since only some users could use it.
The best thing would be if those having speed problems would give some more details like the exact situations when the speed goes down. Also testing various revisions in the svn and telling where the speed did drop will be really helpfull. So instead of only complaining and wanting "the devs" to do something, try to help the devs. If you only claim to get changes nothing will change. So better try to help us a little and speed might improve. Taking our time in discussions that do not make any sense won't help anyone.