Igor, I was wondering whether you or somebody else have a real example where NativeBoost boosts performance. For instance in an often used library class... Cheers, Adrian On Apr 27, 2010, at 23:26 , Igor Stasenko wrote:
On 28 April 2010 00:14, Bryce Kampjes <bryce@kampjes.demon.co.uk> wrote:
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote:
On 26 April 2010 10:57, Lukas Renggli <renggli@gmail.com> wrote:
Igor,
Looks cool, but I really would like to know the exact difference to Exupery?
For what I understand NativeBoost is no different to Exupery's low-level code generation infrastructure.
You are free to use any code generator you want. NativeBoost plugin is really dumb and will run your code at your will. I am using AsmJit, because its small and dumb too. Mainly its just an x86/x64 instruction database with some convenience class(es) and methods to generate instructions directly. In contrast, Exupery is a full-blown compiler, but supports a very small subset of x86 instructions. Actually, i think that with some effort, an Exupery could use AsmJit as backend. Not sure, if Bryce likes this idea :)
It sounds like NativeBoost is rather similar to Exupery's lower levels. Exupery can replace individual methods with native code.
Exupery's design supports the easy removal of all native code which is necessary when saving the image if it might be loaded on a platform or by a VM which can not run x86 machine code.
NativeBoost does it a bit differently. Each piece of native code having a special marker - platform id, which is checked before entering native code. If native code platform id matching the platform id of currently running VM, then native code is allowed to run, and if not, then primitive are just failing, refusing to run it. In this way, a native code can be saved in image, but having no chances to run on a wrong target platform.
The VM hooks are rather small and the code generator is reasonably small and simple. Exploring multiple approaches may be more valuable than saving a small amount of duplicate effort.
Bryce
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project