5 ms·

In practice with Lua, being dynamically typed isn't really the metric we're concerned about for power consumption. Typically Lua is used as a scripting interfac

by dottrap 11y ago

In practice with Lua, being dynamically typed isn't really the metric we're concerned about for power consumption. Typically Lua is used as a scripting interface to native APIs and hardware (via C). This is where most of your power consumption is going to live. Powering up a wi-fi antenna? That's going to cost way more than anything you can measure in Lua. Writing a video game? Your GPU is consuming most of the power. And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space. And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip. Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs. Edit: typo

sklogic 11y ago
Of course interpreter always eats up more cycles (so, more power) than a native code. Does not affect much peak consumption, but drains battery integrally. Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such). And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.