Talk:North American P-51 Mustang: Difference between revisions

:: We've had several discussions regarding extra500 performance, and like you say, some things -like the 3D model- seem to have almost negligible impact on performance, while Nasal code is certainly one of the main culprits involved - but even the way the two Canvas textures are updated is fairly expensive. So it's not just due to Nasal itself. Fairly efficient/fast Nasal code can be written, to see for yourself, look at any code written by TheTom, AndersG or Philosopher. As far as I know, the extra500/[[Avidyne Entegra R9]] developers have already adopted some optimizations, and they even looked at some [[NavDisplay]] and [[MapStructure]] techniques to make things faster.  

:: But overall, there's quite a bit of slow code remaining - and the whole instrument could definitely be faster by adopting the corresponding frameworks and augmenting slow code with C++ extensions, which is something we've been working towards. We've also posted patches that make it possible to identify "slow" callbacks (timers/listeners) by hooking into FGNasalSys. I think it's fairly safe to say that the extra500 developers are interested in improving performance, but it's not just Nasal that's involved here, the main issue is a structural one, i.e. code organization. To see for yourself, use the "fps_debug" branch and disable all 3D models and even the IFDs. In general, it would help to add our patches to FG and allow aircraft developers to look under the hood and better understand where resources are spent, including stuff in scripting space (especially the GC, but also all callbacks). Just saying "it's due to Nasal" is as unhelpful and non-helpful as it can get: We've also seen the property rules subsystem consuming plenty of CPU cycles. So "bugs" can be introduced in several places, and that alone doesn't make the technology bad per se. Thus, no matter if it's the 777, the P51, the 747, the 787 or the extra500, what people really need is some way to see where all the horsepower is going instead of uninformed musings that lack data to back up such claims.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 18:06, 11 August 2014 (UTC)

:::So, what of my mention earlier that the extra500 issues are not caused by the model, or by 'older' hw, but by the nasal code was not true? Nevermind the fact that this isn't about the extra500 or about nasal. And yeah, I have no clue on how to test stuff, I just pull figures and results out of thin air... (hint: the cube remark should have already shown you that I've tested the extra500 in various scenarios to reach my conclusion, although the cube was a bit superfluous as setting the draw masks already proved that the 3d-model had nothing to do with the performance issues). And, as clueless and trollish as I am I never bothered to check deeper what was going on, and I never saw that '''mark''' and '''reap''' are the two most frequent calls (followed by various naGC stuff)... wonder to which subsystem those belong to? Right, all, together, repeat after me: '''N A S A L'''. Oh, btw, you can get your nasal golden-boy into trouble just by using the scroll wheel to zoom in and out, and ignoring the evidence you stand here declaring that it's the next best thing since sliced bread... Is the GC part of nasal or isn't it (it is), will you run into GC issues sooner or later (you are), so keep it as "glue" between stuff, but please stop doing overly complex stuff in it, like reimplementing half of a FDM in it,  and please stop claiming that it doesn't cause performance issues, as it does, and is one of the prime reasons FG has such poor performance (along with raw number of objects (drawables) in scene).

:::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 00:37, 12 August 2014 (UTC)

::::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)''

::::and how much is the impact on RAM? I remember that random buildings at their beginning had been very dense and framerate had been really good- but RAM usage was horrible.  

::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 14:30, 11 August 2014 (UTC)

:::::With only trees and buildings (no "grass") RAM usage tops in the 2.3-2.4GB range (with --prop:/sim/tile-cache/enable=false, in very detailed areas of EU). But the changes I was talking about are not a 'refactoring' of the code, just enabling some options/flags on the generated geometry, so the code is the same as the current one. The old random buildings were a completely different approach.

:::::The example was to illustrate that the underlying technology FG is using is old and can be handled by that "antiquated" hardware just fine, and the "modern" hardware only (partly) masks un(der)optimized stuff.

::::: [[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 15:00, 11 August 2014 (UTC)