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

Jump to navigation Jump to search
m
→‎Impact of Nasal scripts: unfortunately, this is very much ON topic ... so no need to make this "offtopic", like i4dnf and I have stated, there definitely are Nasal issues involved here, and most aircraft developers have no clue about this ...
No edit summary
m (→‎Impact of Nasal scripts: unfortunately, this is very much ON topic ... so no need to make this "offtopic", like i4dnf and I have stated, there definitely are Nasal issues involved here, and most aircraft developers have no clue about this ...)
Line 85: Line 85:




==[OT: Impact of Nasal scripts]==
== Impact of Nasal scripts ==
:::: 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.  
:::: 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)
:::: 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)

Navigation menu