Given how Udon 2 wouldn’t have needed to use externs for nearly as much Udon 1 does, the increase in the performance penalty increase must have been pretty substantial to outweigh that and a JIT.
What code was this impacting, yet still needed to be fast(er)?
I wonder if reimplementing some of the more standalone Unity functions in WASM (and then redirecting calls to the WASM version) would be able to mitigate this.
The vector and matrix functions come to mind, if those where left as externs (given they are from UnityEngine) then the cost of marshalling would be significant relative to the size of the function called.
What is the extern cost with Soba, and how does it compare to Udon 1?
In the more detailed Soba graph posted in the Dev update thread (Developer Update - 25 November 2024 - #42 by Merlin), it was shown that code was run on Mono JIT in editor, and on Soba in VRC.
Based on the above quote, is that incorrect or outdated? is the Editor expected to also use Soba (as is the case with Udon 1 and its VM)?
Also, would it have not been possible to run WASM in editor? or was there something preventing that approach?
It was stated before that one of the reason WASM was dropped was because of Apples restrictions against using a JIT. I note, however, that same reason is not restated here.
Was that restriction a reason for not looking into other alternatives using JIT (Mono/CoreCLR, or a different language ran on a JIT compiler)?
Would it be possible for Soba to get a JIT in future?
I understand writing one is a pretty complex task, made morose with the need to support two architectures.
I’ll admit, I wasn’t super sold on the WASM approach, but I’m also unconvinced of the reasons given to drop it for your own interpreter.
One of the points shown on Hai’s graph was the ability to bundle 3rd party .Net libs. Given that, based on the chart I linked earlier, Soba (indirectly?) runs CIL, would is be possible to do this with Soba?