Re:Branch Prediction and the Performance of Interpreters – D...
by vardump on Monday August 10, 2015 @06:44AM
(#10033744)
Right, I also do work in embedded (without OS), so I'm familiar with the limitations. However, there are situations where it's tempting to write a very primitive JIT or at least glue pieces of code together in a buffer and execute it, to get good inner loop performance by making it as few instructions as possible.
So far C has been enough. Achieving low (=preferably none) defect rate using C is challenging enough.
Usually FPGAs can take care of performance critical part. They do increase total cost, though.
No, I mean rewrite the critical parts of the "interpreted" program as interpreter primitives/instructions: the best way to eliminate interpreter overhead is to merge N primitives into one.
But I realise we have a different perspective. You seem to consider interpreter VMs as off the shelf components, when I consider VMs as custom components because I'm working mainly with embedded systems. In the embedded world, JIT is often simply not an option either because they are not available for your particular target, or because the resource constrains don't allow it. But still you sometimes want to trade resources for ease of development and/or flexibility.