Aerosoft CRJ preview pictures

[Alpine Scenery 1,609]

5 hours ago, cwburnett said:

Even if they do eventually both reach the market, the plane developed in modern languages will almost certainly outperform legacy code in raw FPS... V8 JS/HTML + Coherent is really performent if done right.

I'm not sure I understand this point, not disagreeing necessarily, but just thinking here.

You say the V8 JS/HTML would outperform any legacy code, which given that would be C++. Are you saying that Asobo has exposed everything in a way that there is absolutely no marshalling going on between the back-end and the front-end when it comes to JS/HTML.

However, generally speaking, C++ would always perform better of course, as long as you were not doing the draw calls on an outdated translation, or the code was not horribly written. Heck, even C++ with GDI can beat C# using DirectX in some cases, if we are talking the C++ is optimized correctly, all it takes is just a couple marshalling calls for any garbage collection type language to fall flat on its face. Of course DirectX with C++ is the only way to write a game engine though to modern standards (or c++ and any other modern graphics API). Yes, GDI is outdated, but the C++ isn't the issue, it's the GDI calls themselves. There is nothing faster than C++ (other than ASM) and some certain builds of Fortran might be faster at floating point (no idea), but C++ would still be the most modern and applicable way to interface into any game engine. Any performance issues would therefore not be based on any language constraints, but purely implementation related, as language vs. language there is simply no way for any Javascript code to beat properly written C++, regardless of how that JS is interpreted (ok there may be a few examples, but they are 'fringe' and way out there to say the least). 

Edited December 30, 2020 by Alpine Scenery

[omarsmak30 4,069]

23 minutes ago, Alpine Scenery said:

I'm not sure I understand this point, not disagreeing necessarily, but just thinking here.

You say the V8 JS/HTML would outperform any legacy code, which given that would be C++. Are you saying that Asobo has exposed everything in a way that there is absolutely no marshalling going on between the back-end and the front-end when it comes to JS/HTML.

However, generally speaking, C++ would always perform better of course, as long as you were not doing the draw calls on an outdated translation, or the code was not horribly written. Heck, even C++ with GDI can beat C# using DirectX in some cases, if we are talking the C++ is optimized correctly, all it takes is just a couple marshalling calls for any garbage collection type language to fall flat on its face. There is nothing faster than C++ (other than ASM) and some certain builds of Fortran might be faster at floating point (no idea), but C++ would still be the most modern and applicable way to interface into any game engine. 

Any performance issues would therefore not be based on any language constraints, but purely implementation related, as language vs. language there is simply no way for any Javascript code to beat properly written C++, regardless of how that JS is interpreted (ok there may be a few examples, but they are 'fringe' and way out there to say the least). 

What he means I think, you can think of it like this, in MSFS Javascript has the first class support for gauges, they use coherent GT engine which is based on Javascript v8 engine that powers Chrome and Node.js, that by itself is extremely fast, asynchronous that as result, will just use a single thread.

The WASM, provides a way to compile LLVM languages like C/C++/Rust into binary code ahead of time that is readable by the V8 engine above, sort of equivalent of the Javascript. So yeah, I think when we talk native code in the context of MSFS, you would likely refer to Javascript and Coherent GT engine.

However I don't think either approach is the most optimal, I think that would be based on what you want to achieve at the end of the day as I think both should offer comparable performance (WASM and Javascript).

Definitely if we are talking in the context of the operating system and DLLs, no doubt LLVM languages will outperform although nowdays with the optimizations that being added to go compiler and even GraalVM compiler (to run JVM languages), V8 engine .. etc, things start to get minimal in terms of performance comparison.

Edited December 30, 2020 by omarsmak30

[tweekz 2,165]

8 hours ago, marsman2020 said:

2 million potential new customers, as I'm sure Aerosoft has recognized since they are taking the leap into the "new methods".

 

7 hours ago, sd_flyer said:

Lol I have actually have done it several  times!  You gotta do what you gotta do. 

 

Look at it from that point of view:

Would it be worth rewriting thousands of lines of codes, dealing with language-specific challenges and testing over waiting a year to get a plugin that allows your proven C++ code to run.

Would rewriting the code take less time? Would it cost less?

[Alpine Scenery 1,609]

9 minutes ago, omarsmak30 said:

The WASM, provides a way to compile LLVM languages like C/C++/Rust into binary code ahead of time that is readable by the V8 engine above, sort of equivalent of the Javascript. So yeah, I think when we talk native code in the context of MSFS, you would likely refer to Javascript and Coherent GT engine.

Definitely if we are talking in the context of the operating system and DLLs, no doubt LLVM languages will outperform although nowdays with the optimizations that being added to go compiler and even GraalVM compiler (to run JVM languages), V8 engine .. etc, things start to get minimal in terms of performance comparison.

I have no idea about how MSFS does it, but they didn't do it that way for performance reasons, they did it that way for ease-of-use so more people can use javascript and not have to do C++. There is just no way to expose or interpret Javascript to be faster or nearly as fast as C++, people have been trying it for years. Unity (the game engine) has all sorts of marshalling issues to this day compared to using a more native C++ environment.  Here's the issue, it may in fact compile a certain # of things into the C++ binaries, but the translation layers or pre-compilation interpretation is very complicated to implement, and it often introduces more problems than it fixes.

The truth is regardless of latest optimizations of any GC languages will always be held back in memory intensive applications. You can get near similar performance on certain things, but not when it comes to graphics API's, no-one has nearly cracked that monster yet. It's like the difference between writing MSFS in C# and Unity compared to the MSFS (fuel) engine and DirectX.

Luckily, since gauges are not all that much rendering or interaction, they might get away with it, but it's definitely on no level faster. 

Edited December 30, 2020 by Alpine Scenery

[omarsmak30 4,069]

I have a question to @cwburnett, currently there is no native Simconnect Javascript APIs that allows you to access Simconnect APIs from Javascript instead of WASM, isn't?

[tweekz 2,165]

13 minutes ago, omarsmak30 said:

Definitely if we are talking in the context of the operating system and DLLs, no doubt LLVM languages will outperform although nowdays with the optimizations that being added to go compiler and even GraalVM compiler (to run JVM languages), V8 engine .. etc, things start to get minimal in terms of performance comparison.

I mean, if performance of interpreted languages would be a limiting issue nowadays, Google, Facebook, Netflix & Co wouldn't rely heavily on Python in server-side programming.

Indeed, its advantages of being easy to deal with and maintain far outweigh the performance deficits. Same goes for Javascript.

Edited December 30, 2020 by tweekz

[Alpine Scenery 1,609]

1 hour ago, tweekz said:

I mean, if performance of interpreted languages would be a limiting issue nowadays, Google, Facebook, Netflix & Co wouldn't rely heavily on Python in server-side programming.

It's not in data processing, but it is in the gaming world.

There is a huge difference, distributed processing can re-allocate across slower bandwidth pipes, whereas a game engine is an RTS type coding system. It's two totally different type of systems in the internal hardware architecture. 

Data processing is different in the sense it doesn't matter how long it takes to redistribute the load over a different pipe, whereas game engines are nearly "real-time systems" that need absolute lowest latency at every path. For instance, if you had 3 functions returning a value on a data processing pipe, and the end result was it took 0.5 seconds. It wouldn't matter if that 0.5 seconds was broken up like this (0.4, 0.05. 0.05), but for a game engine it needs to look more like this (0.05, 0.05, 0.05, 0.05, 0.05, etc..), all the way across the pipe. That's not the perfect example, but its the only way I can think to explain it ATM.

It is still not even close in the gaming world when talking C++ and interpreting or even pre-compiling things. There are engines where it can be fast enough, but you will be much more limited on the # of polys. Like Unity is ok after years and years of hacks, but it's also a mess at the same time. It would not be competitive to someone making a game with C++ and DirectX.

Edited December 30, 2020 by Alpine Scenery

[tweekz 2,165]

2 minutes ago, Alpine Scenery said:

Sorry guys, but it is not even close in the gaming world when talking C++ and interpreting or even pre-compiling things. There are engines where it can be fast enough, but you will be much more limited on the # of polys. Like Unity is ok after years and years of hacks, but it's also a mess at the same time. It would not be competitive to someone making a game with C++ and DirectX.

I guess we'll just have to wait and see what happens. 😉

[omarsmak30 4,069]

4 minutes ago, Alpine Scenery said:

Sorry guys, but it is not even close in the gaming world when talking C++ and interpreting or even pre-compiling things. There are engines where it can be fast enough, but you will be much more limited on the # of polys. Like Unity is ok after years and years of hacks, but it's also a mess at the same time. It would not be competitive to someone making a game with C++ and DirectX.

Here I can't really comment since I really don't have this adequate knowledge to know the performance of drawing gauges comparing to C++ graphical APIs performance. Perhaps WT folks can enlighten us here?

[Alpine Scenery 1,609]

29 minutes ago, omarsmak30 said:

Here I can't really comment since I really don't have this adequate knowledge to know the performance of drawing gauges comparing to C++ graphical APIs performance. Perhaps WT folks can enlighten us here?

MSFS is natively written in C++, so I already know the answer, but...
It's just we have so much horsepower we are getting away with it more often now, but it's never really going to be faster than doing it natively, unless the native code were making the wrong calls (but in that case you are comparing apples to oranges anyhow).

In this case we'll assume Asobo's engine does all the rendering, which is fine, but the issue is interacting with the update lag (getting data from Asobo's engine, processing it, and passing it back between the draw call times). This is why it is so hard to OPTIMIZE games. You would think everything can just be perfectly balanced across multiple cores, but "limited by the main thread" has a very distinctive reason why it has to be limited. It is an impossibility for it to run a script at the same speed as it could natively link to a C++ module, the marshalling is a requirement, the only way it can be done is by pre-compilation (converting the code to C++ or ASM before compiling, but that has not been solved yet totally in modern languages, there are issues as it's a lot of complicated compiler directives). In the future, C++ will eventually die, but it will take a while.

 

Edited December 30, 2020 by Alpine Scenery

[tweekz 2,165]

9 minutes ago, omarsmak30 said:

Here I can't really comment since I really don't have this adequate knowledge to know the performance of drawing gauges comparing to C++ graphical APIs performance. Perhaps WT folks can enlighten us here?

I mean... the default Airbus already draws quite a lot of gauges. And there I get steady 30fps on HIGH / MEDIUM on a i7 7700K and a RX480 8GB with 16GB Ram. So that seems acceptable to me.

Edited December 30, 2020 by tweekz

[Alpine Scenery 1,609]

It's fine overall, I'm not against higher-level languages, personally think all C languages were poorly structured, but just performance cannot be matched. The real problem is by the time they solve all those pre-compilation issues, well, we will have more worries about AI systems writing encrypted code behind our back and robots taking over the world. I'll be dead by then, but some younger people in here might have to worry about it 🙂

OK, I'm out of here, enjoyed the conversation even if it got a bit heated.
Good luck with the robot wars...

 

Edited December 30, 2020 by Alpine Scenery

[sd_flyer 6,119]

4 hours ago, tweekz said:

 

 

Look at it from that point of view:

Would it be worth rewriting thousands of lines of codes, dealing with language-specific challenges and testing over waiting a year to get a plugin that allows your proven C++ code to run.

Would rewriting the code take less time? Would it cost less?

We were rewriting code from legacy VB6 to C#. Yes it painful, but at least design was known.

[The Dude 113]

 

[Bigbluss 304]

4 hours ago, Alpine Scenery said:

It's fine overall, I'm not against higher-level languages, personally think all C languages were poorly structured, but just performance cannot be matched. The real problem is by the time they solve all those pre-compilation issues, well, we will have more worries about AI systems writing encrypted code behind our back and robots taking over the world. I'll be dead by then, but some younger people in here might have to worry about it 🙂

OK, I'm out of here, enjoyed the conversation even if it got a bit heated.
Good luck with the robot wars...

 

Sentient machines aren't on the horizon right now though. Or for the foreseeable. There's no evidence at all to suggest we will have anything but highly effective, specialised, but importantly unconscious and unmotivated algorithms to solve problems in the future. 

The robot wars (which would be less of a war and more of an absolute eradication should we hit singularity level intellect that doesn't want us around) just aren't coming anytime soon. Cognitive neuroscience has absolutely no idea what the root cause of consciousness is. Best guess is a byproduct of our billions of synapses firing at once. An accident of evolution and potential illusion of self control.

 

And I say this as someone extremely excited about the potential of AI to solve problems.

 

(You commented on a topic close to my heart, ML engineer with a love of neuroscience)