3 ms·
Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engine
by xuejie 8y ago
Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines.
Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.
- ricardobeat 8y ago“Very slow compared to” is still as fast, or faster than, many other dynamic language runtimes. In my case I saw a 2x-10x difference between V8 and Duktape, which is acceptable given the trade-offs.
- xuejie 8y agoAgreed, and I'm not saying duktape doesn't have a use case, I'm merely saying having a standalone ignition interpreter might enable different use cases.
- Leszek 8y agoIgnition is very tightly coupled to the rest of V8, starting with that fact that it uses inline caches and the object model to maintain performance, and finishing with it itself being written in "CSA", which is an assembler DSL that is passed through the TurboFan (optimizing compiler) backend to generate the machine code for the bytecode handlers (this has the interesting side-effect that porting V8 to a new platform requires porting the optimizing compiler). There's not really much that can be split off.
- xuejie 8y agoThanks for the explanation! One follow-up question is: how can we still call ignition an interpreter with this flow where TurboFan is still used to generate machine code? Doesn't that defunct the idea of an interpreter in v8, which is to be used in platforms w/o write access to executable memory, such as iOS or PS4?
- schuay 8y agoWhile bytecode handlers (and other builtins) are generated by TurboFan, this happens at V8-compile-time, not at runtime. Their generated code is shipped embedded into the binary as embedded builtins.
- c256 8y agoThis suggests that a specialized app (such as a set-top box, smart TV, or game console) could push more code through the pre-JIT process to further close the performance gap. (This is interesting to me, because I haven’t seen much interest in pre-JIT compilation since the early days of Java, HotSpot, etc.)
- bpye 8y agoI quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.
- CamperBob2 8y agoI'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers? The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in complexity since then and no longer appears suitable for lightweight applications, meaning anything smaller than a full-fledged Web browser. I need to upgrade that interpreter at some point, so I'm definitely in the market for something comparable to what V8 used to be. Kind of unfortunate, but I'm hardly the user the V8 team has in mind.
- jjnoakes 8y agoGoogle duktape, not duct tape.
- bpye 8y agoFor anyone that is interested, duktape ( https://www.duktape.org/ https://www.duktape.org/ ). The API docs are at https://www.duktape.org/api.html https://www.duktape.org/api.html , it's a C API and it's pretty easy to work with and bind native code. I kinda wish that more JIT compiled languages had an API as nice as LuaJIT.
- CamperBob2 8y agoThanks, that was the trick I was missing. Will have a look.