glen/dyna3
1
0
Fork 0
Code Issues 14 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

Add details about linear algebra

Vectornaut 2024-08-05 22:09:03 +00:00
parent 1af37a9fc6
commit ed2af6714f
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Coding-environment.md

@ -69,7 +69,7 @@ The gist of the most significant argument for the upper version is that one read
* (I think targeting the JVM invalidates this? Or is there now a decent build process to WASM? Is Scala sufficiently more active/bigger community/more mainstream than Nim to make it worth looking into this more?) * (I think targeting the JVM invalidates this? Or is there now a decent build process to WASM? Is Scala sufficiently more active/bigger community/more mainstream than Nim to make it worth looking into this more?)
- Actually, there is Scala.js that compiles to JavaScript, that seems quite mature. There does not currently seem to be a way to compile to WASM, but it appears to be pretty close as an optional backend in Scala.js (see https://github.com/scala-js/scala-js/issues/4928). One can use existing JavaScript frameworks via Scala.js -> JavaScript; there also exist Scala frameworks/servers like [Xitrum](https://xitrum-framework.github.io/) but not sure what that does as far as client-side computation. So it seems as though trying to go with Scala would at least at first mean sticking within JavaScript per se, so there is a potential trap if in fact WASM ends up being needed for performance reasons (assuming that a language well-compiled to WASM will be faster than basically equivalent JavaScript). On the other hand, the ongoing work for the [WASM backend](https://dev.virtuslab.com/p/scala-to-webassembly-how-and-why) could provide a way out of that trap, although some commenters online say that the WASM backend will not likely be any faster than the pure-JavaScript backend because it will not be able to get close enough to the underlying WASM architecture to take advantage of its possible speedups. So there is some risk here; not sure how to evaluate whether it's worth looking deeper? - Actually, there is Scala.js that compiles to JavaScript, that seems quite mature. There does not currently seem to be a way to compile to WASM, but it appears to be pretty close as an optional backend in Scala.js (see https://github.com/scala-js/scala-js/issues/4928). One can use existing JavaScript frameworks via Scala.js -> JavaScript; there also exist Scala frameworks/servers like [Xitrum](https://xitrum-framework.github.io/) but not sure what that does as far as client-side computation. So it seems as though trying to go with Scala would at least at first mean sticking within JavaScript per se, so there is a potential trap if in fact WASM ends up being needed for performance reasons (assuming that a language well-compiled to WASM will be faster than basically equivalent JavaScript). On the other hand, the ongoing work for the [WASM backend](https://dev.virtuslab.com/p/scala-to-webassembly-how-and-why) could provide a way out of that trap, although some commenters online say that the WASM backend will not likely be any faster than the pure-JavaScript backend because it will not be able to get close enough to the underlying WASM architecture to take advantage of its possible speedups. So there is some risk here; not sure how to evaluate whether it's worth looking deeper?
- Nevertheless, being the statically-typed significant-indentation language with the highest SO score is suggestive that we should put a bit of effort into seeing what using it would be like. - Nevertheless, being the statically-typed significant-indentation language with the highest SO score is suggestive that we should put a bit of effort into seeing what using it would be like.
- The main numerical linear algebra package I found on a quick web search was [Breeze](https://github.com/scalanlp/breeze). - Scala has [a bunch](https://statr.me/2015/09/an-overview-of-linear-algebra-libraries-in-scala-java/) of numerical linear algebra packages. Some of them have been [benchmarked](http://lessthanoptimal.github.io/Java-Matrix-Benchmark/runtime/2013_10_Corei7v2600/) against each other. The [EJML](http://ejml.org/wiki/index.php) seems to dominate the benchmarks for matrices smaller than 100×100. The benchmarks don't include [Breeze](https://github.com/scalanlp/breeze), though.
- I think the musings/reservations I discuss above really just come down to the question of whether adopting a language originally tied to the JVM, and for the moment for our purposes tied to the JavaScript engines in browsers, will ultimately hobble the **performance** of Dyna3, which will surely have compute-intensive aspects. One way we could get at this is do the hello, world app in Scala (which should be trivial via Scala.js, as it will end up 100% JavaScript when compiled), and then do the same "Linear algebra hello world" in Scala as in other systems under consideration in which the linear algebra will be compiled to WASM, and make sure the linear algebra task being performed is a noticeable compute-time consumer, and then just benchmark the identical task in Scala and the other candidates. - I think the musings/reservations I discuss above really just come down to the question of whether adopting a language originally tied to the JVM, and for the moment for our purposes tied to the JavaScript engines in browsers, will ultimately hobble the **performance** of Dyna3, which will surely have compute-intensive aspects. One way we could get at this is do the hello, world app in Scala (which should be trivial via Scala.js, as it will end up 100% JavaScript when compiled), and then do the same "Linear algebra hello world" in Scala as in other systems under consideration in which the linear algebra will be compiled to WASM, and make sure the linear algebra task being performed is a noticeable compute-time consumer, and then just benchmark the identical task in Scala and the other candidates.
### C++ with our own civet-like syntax unmangler (SO 18.3/53.1) ### C++ with our own civet-like syntax unmangler (SO 18.3/53.1)