FFI in 1.1
Locked
12
12
 
|
Probably.
There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us. Stef On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: > > > On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: > > > > yes communication with C library. so this is just a tool too. > > > > > > > > Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. > > Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to call and write code in smalltalk > as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. > Look at lua... why lua is cool because he can be embeded seamlessly in C and call C. So if we do not put pressure > on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. > This is why having FFI in pharo-dev is important. We should be able to call mac native menu. > Of course we should pay attention that we rely too much on C library but the world is getting more complex and writing > everything in smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already > an important step. > Am I clear? > > > Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. > But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. > Anyway...forget this little discussion. > > In summary, should I add FFI when I start to build PharoDev 1.1 ? > > Cheers > > Mariano > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stef,
I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, April 25, 2010 3:05 PM To: [hidden email] Subject: Re: [Pharo-project] FFI in 1.1 Probably. There were some discussions that alien will be integrated / working also for the windows vm. So we will see which one I will let people with more experience telling that to us. Stef On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: > > > On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: > > > > yes communication with C library. so this is just a tool too. > > > > > > > > Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. > > Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to > call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. > Look at lua... why lua is cool because he can be embeded seamlessly in > C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. > This is why having FFI in pharo-dev is important. We should be able to call mac native menu. > Of course we should pay attention that we rely too much on C library > but the world is getting more complex and writing everything in > smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. > Am I clear? > > > Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. > But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. > Anyway...forget this little discussion. > > In summary, should I add FFI when I start to build PharoDev 1.1 ? > > Cheers > > Mariano > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: > Stef, > > I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. there are no such alien maintainers. There are us. > > Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse > Sent: Sunday, April 25, 2010 3:05 PM > To: [hidden email] > Subject: Re: [Pharo-project] FFI in 1.1 > > Probably. > There were some discussions that alien will be integrated / working also for the windows vm. > So we will see which one I will let people with more experience telling that to us. > > Stef > > On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: > >> >> >> On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: >>> >>> yes communication with C library. so this is just a tool too. >>> >>> >>> >>> Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. >> >> Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to >> call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. >> Look at lua... why lua is cool because he can be embeded seamlessly in >> C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. >> This is why having FFI in pharo-dev is important. We should be able to call mac native menu. >> Of course we should pay attention that we rely too much on C library >> but the world is getting more complex and writing everything in >> smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. >> Am I clear? >> >> >> Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. >> But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. >> Anyway...forget this little discussion. >> >> In summary, should I add FFI when I start to build PharoDev 1.1 ? >> >> Cheers >> >> Mariano >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 26 April 2010 08:41, Stéphane Ducasse <[hidden email]> wrote:
> > On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. > > there are no such alien maintainers. There are us. >> Innndeeeddd :) Besides, i plan to support callbacks in NativeBoost, so, you'll be able to handle callback without entering the interpreter & language-side (as well as entering - at your will ;). Handling a callbacks natively is waaay much faster than go all the way through calling interpret(), especially, when you need to do something very simple, like count bunnies :) So, Alien could use a NativeBoost as extension to do things faster, smoother & nicer :) >> Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. >> >> Bill >> >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse >> Sent: Sunday, April 25, 2010 3:05 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] FFI in 1.1 >> >> Probably. >> There were some discussions that alien will be integrated / working also for the windows vm. >> So we will see which one I will let people with more experience telling that to us. >> >> Stef >> >> On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: >>>> >>>> yes communication with C library. so this is just a tool too. >>>> >>>> >>>> >>>> Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. >>> >>> Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to >>> call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. >>> Look at lua... why lua is cool because he can be embeded seamlessly in >>> C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. >>> This is why having FFI in pharo-dev is important. We should be able to call mac native menu. >>> Of course we should pay attention that we rely too much on C library >>> but the world is getting more complex and writing everything in >>> smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. >>> Am I clear? >>> >>> >>> Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. >>> But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. >>> Anyway...forget this little discussion. >>> >>> In summary, should I add FFI when I start to build PharoDev 1.1 ? >>> >>> Cheers >>> >>> Mariano >>> >>> Stef >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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. Check out the Exupery documentation: <http://goran.krampe.se/exuperyDesign.pdf>. Some more questions about NativeBoost: - How do I send a message? - How do I evaluate a block passed as argument? - How do I access the VM state? Lukas On 26 April 2010 09:38, Igor Stasenko <[hidden email]> wrote: > On 26 April 2010 08:41, Stéphane Ducasse <[hidden email]> wrote: >> >> On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. >> >> there are no such alien maintainers. There are us. >>> > Innndeeeddd :) > > Besides, i plan to support callbacks in NativeBoost, > so, you'll be able to handle callback without entering the interpreter > & language-side (as well as entering - at your will ;). > Handling a callbacks natively is waaay much faster than go all the way > through calling interpret(), > especially, when you need to do something very simple, like count bunnies :) > So, Alien could use a NativeBoost as extension to do things faster, > smoother & nicer :) > >>> Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. >>> >>> Bill >>> >>> >>> >>> -----Original Message----- >>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse >>> Sent: Sunday, April 25, 2010 3:05 PM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] FFI in 1.1 >>> >>> Probably. >>> There were some discussions that alien will be integrated / working also for the windows vm. >>> So we will see which one I will let people with more experience telling that to us. >>> >>> Stef >>> >>> On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: >>> >>>> >>>> >>>> On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: >>>>> >>>>> yes communication with C library. so this is just a tool too. >>>>> >>>>> >>>>> >>>>> Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. >>>> >>>> Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to >>>> call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. >>>> Look at lua... why lua is cool because he can be embeded seamlessly in >>>> C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. >>>> This is why having FFI in pharo-dev is important. We should be able to call mac native menu. >>>> Of course we should pay attention that we rely too much on C library >>>> but the world is getting more complex and writing everything in >>>> smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. >>>> Am I clear? >>>> >>>> >>>> Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. >>>> But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. >>>> Anyway...forget this little discussion. >>>> >>>> In summary, should I add FFI when I start to build PharoDev 1.1 ? >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 26 April 2010 10:57, Lukas Renggli <[hidden email]> 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 :) > Check out the Exupery > documentation: <http://goran.krampe.se/exuperyDesign.pdf>. > Thanks, i read it before. I know many things about Exupery. I even contributed to Exupery codebase once upon a time. > Some more questions about NativeBoost: > > - How do I send a message? > You don't. Think of a native code as a primitive. > - How do I evaluate a block passed as argument? > Same as above. > - How do I access the VM state? > Through interpreterProxy functions. In same way as any plugin does. Exupery having a good extension (which i contributed to it btw), which allows you to retrieve any VM symbol address, so then you can call any VM function or access any of its global state directly. But currently i'm trying to stay away from changing VM, because i want my plugin to work on usual VMs. > Lukas > > On 26 April 2010 09:38, Igor Stasenko <[hidden email]> wrote: >> On 26 April 2010 08:41, Stéphane Ducasse <[hidden email]> wrote: >>> >>> On Apr 26, 2010, at 12:06 AM, Schwab,Wilhelm K wrote: >>> >>>> Stef, >>>> >>>> I have read that Alien is not very good at calling functions - I have *no* idea whether that is fair, but we should check before adopting it. If it is indeed poor at them, I recommend using FFI until we or its maintainers can fix Alien. >>> >>> there are no such alien maintainers. There are us. >>>> >> Innndeeeddd :) >> >> Besides, i plan to support callbacks in NativeBoost, >> so, you'll be able to handle callback without entering the interpreter >> & language-side (as well as entering - at your will ;). >> Handling a callbacks natively is waaay much faster than go all the way >> through calling interpret(), >> especially, when you need to do something very simple, like count bunnies :) >> So, Alien could use a NativeBoost as extension to do things faster, >> smoother & nicer :) >> >>>> Also, whatever we include should work on windows, mac and Linux. Alien seems to be getting close to read on Linux, but Laurent reported ugly crashes when trying to actually run it. That would not be good for a supported platform. >>>> >>>> Bill >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse >>>> Sent: Sunday, April 25, 2010 3:05 PM >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] FFI in 1.1 >>>> >>>> Probably. >>>> There were some discussions that alien will be integrated / working also for the windows vm. >>>> So we will see which one I will let people with more experience telling that to us. >>>> >>>> Stef >>>> >>>> On Apr 25, 2010, at 9:26 PM, Mariano Martinez Peck wrote: >>>> >>>>> >>>>> >>>>> On Sun, Apr 25, 2010 at 6:12 PM, Stéphane Ducasse <[hidden email]> wrote: >>>>>> >>>>>> yes communication with C library. so this is just a tool too. >>>>>> >>>>>> >>>>>> >>>>>> Exactly. It is a tool. Not a dev tool in my opinion.In such way, SqueakDBX is also a tool. A tool to persist in a relational database. >>>>> >>>>> Mariano FFI/ALIEN is ***REALLY*** important to get the possibility to >>>>> call and write code in smalltalk as mentioned by john so this is more central (closer to core) than openDBX or refactoring browser. >>>>> Look at lua... why lua is cool because he can be embeded seamlessly in >>>>> C and call C. So if we do not put pressure on FFI to support callback well or ALIEN then we will stay this language that has problem to interact with the outside world. >>>>> This is why having FFI in pharo-dev is important. We should be able to call mac native menu. >>>>> Of course we should pay attention that we rely too much on C library >>>>> but the world is getting more complex and writing everything in >>>>> smalltalk is also costly. Not FFI/ALIEN can reduce our dependency to C compilation and C-writing so this is already an important step. >>>>> Am I clear? >>>>> >>>>> >>>>> Yes, and I agree. However, that was not the discussion. I agree FFI is important. I don't care to add it to PharoDev 1.1 if you agree with that. >>>>> But I STILL think and that's what I was discussing in the last mail, is that FFI is NOT A DEV TOOL for me. >>>>> Anyway...forget this little discussion. >>>>> >>>>> In summary, should I add FFI when I start to build PharoDev 1.1 ? >>>>> >>>>> Cheers >>>>> >>>>> Mariano >>>>> >>>>> Stef >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote:
> On 26 April 2010 10:57, Lukas Renggli <[hidden email]> 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. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 28 April 2010 00:14, Bryce Kampjes <[hidden email]> wrote:
> On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: >> On 26 April 2010 10:57, Lukas Renggli <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> wrote: >> On Mon, 2010-04-26 at 11:24 +0300, Igor Stasenko wrote: >>> On 26 April 2010 10:57, Lukas Renggli <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 28 April 2010 10:24, Adrian Lienhard <[hidden email]> wrote:
> 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... > It depends. I provided comparisons before. But if you have any real-world example in mind, i will happily implement it and give you the numbers. Apparently there is nothing else, which can run faster than native code. I'm giving you control to implement own primitives using native code. As for FFI interface you will have a full control on how to coerce types between C and Smalltalk worlds and so, it will run as fast as you made it. :) For example, here the FFI plugin code which coercing a smalltalk object to integer value for pushing it on stack: ffiIntegerValueOf: oop "Support for generic callout. Return an integer value that is coerced as C would do." | oopClass | self inline: true. (interpreterProxy isIntegerObject: oop) ifTrue:[^interpreterProxy integerValueOf: oop]. oop == interpreterProxy nilObject ifTrue:[^0]. "@@: should we really allow this????" oop == interpreterProxy falseObject ifTrue:[^0]. oop == interpreterProxy trueObject ifTrue:[^1]. oopClass := interpreterProxy fetchClassOf: oop. oopClass == interpreterProxy classFloat ifTrue:[^(interpreterProxy floatValueOf: oop) asInteger]. oopClass == interpreterProxy classCharacter ifTrue:[^interpreterProxy fetchInteger: 0 ofObject: oop]. oopClass == interpreterProxy classLargePositiveInteger ifTrue:[^interpreterProxy positive32BitValueOf: oop]. ^interpreterProxy signed32BitValueOf: oop "<- will fail if not integer". See , how generic it is? It tries to accept every possible combination which could be translated to native integer value. Now, suppose, that you know _exactly_ that your function will be called only with smallintegers as arguments, and want to fail primitive if it get called with wrong argument. This is what you can do with NativeBoost, but you can't with FFI, because it is C code, compiled and made in stone. > Cheers, > Adrian > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |