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 <[email protected]> wrote: >> On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: >>> On 26 April 2010 10:57, Lukas Renggli <[email protected]> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
