Re:MapSCII – Braille and ASCII map renderer for the console
by udp on Wednesday May 03, 2017 @12:59PM
(#14257677)
Not as fast as a compiled language, because JavaScript is too dynamic to apply the same kind of aggressive JITing that things like the JVM or CLR can. It is, however, "fast enough"(tm).
[ Parent
| on HN ]
Re:MapSCII – Braille and ASCII map renderer for the console
by gnode on Wednesday May 03, 2017 @01:32PM
(#14258061)
You say that, but in some ways it has the potential to be faster. JIT compilers can recompile code at runtime making use of a profiler, optimising specifically to both the host and the use case.
Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
Re:MapSCII – Braille and ASCII map renderer for the console
by sedachv on Wednesday May 03, 2017 @04:00PM
(#14259466)
Benchmarks or GTFO. Tracing JITs are hard to implement, use up a lot of memory, and cannot efficiently implement many kinds of control flow[1]. AFAIK TraceMonkey was the only JavaScript tracing JIT and it was not that great.[2]
[1] https://news.ycombinator.com/item?id=13774326 [2] https://en.wikipedia.org/wiki/SpiderMonkey
Re:MapSCII – Braille and ASCII map renderer for the console
by monocasa on Thursday May 04, 2017 @10:51AM
(#14265220)
> Modern JavaScript VMs like V8 will often optimise functions treating types as static, then "deoptimise" in the rare case their type assumptions are broken.
And that logic that's needed to test invariants is exactly the overhead we're talking about.