> With your scientific background you should know better than > cherry-picking that statistic. Those on the forum are a self-selected > minority of our users. (...) > No I'm most definitely not. What I'm saying is that by "optimising" for a > subset of users, you run the risk of sub-optimising for the rest.
*sigh* Did you read what I tried to tell you in my last mail? Without optimization, the code would run in single digit framerates. So it has to be optimized, it's not a question of if, just of how. The only system for which I can do this is my own, because I don't have data for any other system. If I get good solid data from your side, I can include that into the optimization. But please remember - we're talking optimizing the last 5% or so here. In brute force mode, it would never ever run fast enough. Generating clouds on a one per frame basis for instance is not an option - it's way too slow. Doing all administrative tasks every frame is not an option - this generates way too much load. > I think Advanced Weather is good. I'd like the opportunity to exploit my > (fairly - it's getting a bit long in the tooth now) high end system to > enjoy it - not have to put up with an experience that is not as good overall > as > basic weather. And I'd like to support that. So what I need is data how your system responds to certain things, then I can understand what causes the problems, then I can hopefully fix them. What I don't need at this point is your theory what is wrong unless you understand sufficiently well why things are coded the way they are. I have a certain advantage here - I know very well what the individual loops do and how and where they burn performance. > Unfortunately, Advanced Weather can and does crash Fg here. I haven't > looked into it properly - but there's no obvious reason atm. Never happened to me. Also, I found it very difficult to crash Flightgear from Nasal in general - in all my time coding in Nasal, I have just discovered a single way of causing a segfault. So, I have to leave it to you to figure out the why, I can't reproduce it, and I have logged hundreds of flight hours with Advanced Weather on. > For a start we can try to make the Nasal better, I think that might help > a > bit. I spent an hour or so picking over your code. So far I've found: > > 88 declared but unused variables > 47 declarations of the same or similar variables > 427 instances of "else if" instead of "elsif" > 100 instances of I = I + 1 instead of i+=1 > Numerous examples of variables declared inside for loops, and some of > those > are inside other for loops > Variables declared inside condition statements. Nasal isn't C++ and variable declaration isn't the same thing for instance. If you want to speed up code, you have to go where performance is burnt. And that happens wherever you call add-cloud() or geodinfo() or setprop() or getprop(), i.e. the hard-coded stuff - that needs to be carefully distributed across frames for a smooth experience. What you do Nasal-internally is subleading and usually I couldn't ever measure a performance impact. As I said, I am currently going over the code and throwing out stuff which the transition to Stuart's cloud system has made obsolete and which are currently just de-activated by if-statements. That allows to streamline some other processes, because some situation can't occur any more, and that should take some load off the main loops and definitely reduce load for the GC if this is anywhere sensitive to code size. I would expect much more from that than from semantic details (I don't even know whether else if or elseif would be faster in Nasal - has that been tested? ). In the mean time, can we do the following: There are two issues: 1) framerate impact while a weather tile is built (that happens a lot initially as up to 9 tiles are built, and later depends on the speed of your aircraft - the Concorde triggers a new tile every 16 seconds, the C-172 takes a few minutes. 2) framerate impact and smoothness while no tile is built For the time being, I'd like to focus on 2) (because optimizing tile building is *really* tough and I don't even have an idea for a better algorithm which doesn't break in some situations) so you may have to live with stutter/framerate drop caused by tile-building for a while longer. Without tile-building, I'd like to aim at a worst frame duration of <33 ms, so we can have a smooth 30 fps at least (currently we can apparently have 50 ms). If more comes out, the better. To gauge the impact of various measures, I'd like to see framerate and worst frame duration readings without tile building going on. So you have to wait after starting Advanced Weather for about a minute till 9 tiles are built and the visibility has reached its target value and all terrain is loaded, then take the readings. If the log option in the GUI is on, the tile building info is written to the console, so you can see when it's over. Also, ideally just remain static to avoid triggering terrain loading or any other framerate-fluctuation triggering effec (at least for me, this reliable generates a very stable framerate and worst frame duration reading, which is not the case when I fly around). After the readings are taken, I'd like for comparison the readings after pressing clear/end, i.e. after all weather is disabled. I will write a standard weather situation into the 'test' weather tile slot, so we all have about the same cloud count to be generated. Till I have this ready (a first revised code should be ready next week), also the relative information is meaningful. In particular, framerate and worst frame duration for all the loops successively disabled is interesting. I believe with this data, I can improve matters somewhat. Cheers, * Thorsten ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
