[Pharo-project] NativeBoost and Cog. A working protype.
Hello, just wanna tell you that i adopted NativeBoost under Cog and have a first running prototype. It still lacks callbacks support, but its already can be used for callouts and to run native code. NativeBoost-CogPlugin does not requires patched for platform-specific code. Just load it into Cog VMMaker image, generate & build vm and you done! Thanks Eliot for providing necessary bits for controlling memory execution protection. The NativeBoost-CogPlugin will have some additional functionality, comparing to its Squeak VM cousin. - it using a primitive failure codes, so when primitive fails , you can determine why and where your native call fails. The primitive error codes still not handled/used by language side, so its a work to do: - a marchalling code can use error codes to report that primitive fails due to coercion error, and it even will tell which exactly argument failed to coerce. - of course, you will be able to add own custom error codes, and handle them as you like to. By default, a plugin could report following problems: "execution of native code is not enabled by plugin" ErrNotEnabled "failed to find a native code for primitive method" ErrNoNativeCodeInMethod "native code generated for different platform" ErrInvalidPlatformId I wanna say thanks to Eliot for providing primitive fail codes in VM. A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code. -- Best regards, Igor Stasenko AKA sig.
Sig, "A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code." Well said!!!! Still working on that grant proposal; I'll be glad when it's submitted. Do you have any sense of when callbacks will be available? Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them. One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } } That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :) Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, September 29, 2010 6:31 PM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] NativeBoost and Cog. A working protype. Hello, just wanna tell you that i adopted NativeBoost under Cog and have a first running prototype. It still lacks callbacks support, but its already can be used for callouts and to run native code. NativeBoost-CogPlugin does not requires patched for platform-specific code. Just load it into Cog VMMaker image, generate & build vm and you done! Thanks Eliot for providing necessary bits for controlling memory execution protection. The NativeBoost-CogPlugin will have some additional functionality, comparing to its Squeak VM cousin. - it using a primitive failure codes, so when primitive fails , you can determine why and where your native call fails. The primitive error codes still not handled/used by language side, so its a work to do: - a marchalling code can use error codes to report that primitive fails due to coercion error, and it even will tell which exactly argument failed to coerce. - of course, you will be able to add own custom error codes, and handle them as you like to. By default, a plugin could report following problems: "execution of native code is not enabled by plugin" ErrNotEnabled "failed to find a native code for primitive method" ErrNoNativeCodeInMethod "native code generated for different platform" ErrInvalidPlatformId I wanna say thanks to Eliot for providing primitive fail codes in VM. A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code. -- 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
On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
"A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code."
Well said!!!! Â Still working on that grant proposal; I'll be glad when it's submitted. Â Do you have any sense of when callbacks will be available? Â Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them.
I'd like to see someone, like you to start using it. And during it, i can start receiving feedback and so, NB could improve in quality and feature set :) See, i did most stuff , what i would need , but apparently i could miss something which may be userfull as well.
One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Â Â Â Â Add one and take log10() over the buffer; in-place transformation! */ { Â Â Â Â for(unsigned long i=0; i<size; i++){ Â Â Â Â data[i] = log10(data[i]+1); Â Â Â Â } }
That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Bill
-- Best regards, Igor Stasenko AKA sig.
On 9/30/10 5:41 AM, Igor Stasenko wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K<bschwab@anest.ufl.edu> wrote:
Sig,
"A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code."
Well said!!!! Still working on that grant proposal; I'll be glad when it's submitted. Do you have any sense of when callbacks will be available? Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them.
I'd like to see someone, like you to start using it. And during it, i can start receiving feedback and so, NB could improve in quality and feature set :) See, i did most stuff , what i would need , but apparently i could miss something which may be userfull as well.
I would be happy to try it, but I find the creation of the VM a bit difficult. Could you provide a cog VM with NativeBoost for linux? That would be awesome ;) Alberto
On 30 September 2010 11:18, Alberto Bacchelli <alberto.bacchelli@usi.ch> wrote:
On 9/30/10 5:41 AM, Igor Stasenko wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K<bschwab@anest.ufl.edu> Â wrote:
Sig,
"A proper error handling is an important part of infrastructure-level project (such as NativeBoost), since then people who using it, can quickly determine what's wrong with their code."
Well said!!!! Â Still working on that grant proposal; I'll be glad when it's submitted. Â Do you have any sense of when callbacks will be available? Â Please don't feel any pressure from me, because I have a lot to do before I can make proper use of them.
I'd like to see someone, like you to start using it. And during it, i can start receiving feedback and so, NB could improve in quality and feature set :) See, i did most stuff , what i would need , but apparently i could miss something which may be userfull as well.
I would be happy to try it, but I find the creation of the VM a bit difficult. Could you provide a cog VM with NativeBoost for linux? That would be awesome ;)
Frankly i din't yet tried to build Cog under Linux, and having no idea how easy/hard to do that. I am also, have no idea if there an automatic way to package a built artifacts into some kind of package, like tarball. But definitely, will do that soon.
Alberto
_______________________________________________ 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.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization). - Stephen
Work can be many things. Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats. The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code. Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization). - Stephen
On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Work can be many things. Â Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Â Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. Â One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Â Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
Its up to you, of course. The native code is held inside a compiled method(s), and once it generaetd not dismissed unless you instruct so. So, it doesn't matters how much time it takes to generate code, because it done once at first method invocation, and then dropped only if you change the method or do 'NativeBoost clearNativeCode'. Native code could even survive an image restarts, but i forcely clearing it when fresh image starts, because there is too much nuances, where it won't go (for instance, you were running image under Squeak VM, and then restarted it under Cog).
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Â Â Â Â Add one and take log10() over the buffer; in-place transformation! */ { Â Â Â Â for(unsigned long i=0; i<size; i++){ Â Â Â Â data[i] = log10(data[i]+1); Â Â Â Â } }
That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Indeed. Â It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
- Stephen
_______________________________________________ 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.
Sig, Another question, and I don't know the answer yet, involves something that is not done via NativeBoost but is instead "just left to Cog" to optimize. Will something like replacing a double array with log(abs(buffer[i])+1) be reliably translated? Some seem to be suggesting that stuff like that and worse will just magically be as fast as if one took the time to code a C function and put it in shared library. Maybe it will. Any ideas? Not long enough, I got "the fail-over code for your PLUGIN (emphasis added) will take care of it" in response to questions about the vm's silent refusal to load functions from a library that was in fact the sole platform support for a piece of hardware. Even if there were backup Smalltalk code to talk to the device, it would not do the threading magic to run in the background, and it would not be fast enough to do the job. Less extreme but just as important are functions for Fourier and Wavelet Transforms, etc. I try to find shared libraries for such things, but there is invariably glue that might not be well supported and calls for some native code of some type, whether that comes from Cog, NativeBoost, or another function in a workhorse library of mine. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Thursday, September 30, 2010 2:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Work can be many things. Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
Its up to you, of course. The native code is held inside a compiled method(s), and once it generaetd not dismissed unless you instruct so. So, it doesn't matters how much time it takes to generate code, because it done once at first method invocation, and then dropped only if you change the method or do 'NativeBoost clearNativeCode'. Native code could even survive an image restarts, but i forcely clearing it when fresh image starts, because there is too much nuances, where it won't go (for instance, you were running image under Squeak VM, and then restarted it under Cog).
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
- Stephen
_______________________________________________ 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
On 30 September 2010 22:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
Another question, and I don't know the answer yet, involves something that is not done via NativeBoost but is instead "just left to Cog" to optimize. Â Will something like replacing a double array with log(abs(buffer[i])+1) be reliably translated? Â Some seem to be suggesting that stuff like that and worse will just magically be as fast as if one took the time to code a C function and put it in shared library. Â Maybe it will. Â Any ideas?
I'm not sure what you mean. Do you mean to make special #atLogAbs: method, which reads an element from array , but before returning a value calls log(abs(..))? This will be faster with primitive, since smalltalk if you do that: result := ((array at: i) abs+1) log. It has to do boxing/unboxing the floats at each send.
Not long enough, I got "the fail-over code for your PLUGIN (emphasis added) will take care of it" in response to questions about the vm's silent refusal to load functions from a library that was in fact the sole platform support for a piece of hardware. Â Even if there were backup Smalltalk code to talk to the device, it would not do the threading magic to run in the background, and it would not be fast enough to do the job.
Less extreme but just as important are functions for Fourier and Wavelet Transforms, etc. Â I try to find shared libraries for such things, but there is invariably glue that might not be well supported and calls for some native code of some type, whether that comes from Cog, NativeBoost, or another function in a workhorse library of mine.
Not sure what you mean.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Thursday, September 30, 2010 2:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Work can be many things. Â Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Â Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. Â One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Â Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
Its up to you, of course. The native code is held inside a compiled method(s), and once it generaetd not dismissed unless you instruct so. So, it doesn't matters how much time it takes to generate code, because it done once at first method invocation, and then dropped only if you change the method or do 'NativeBoost clearNativeCode'.
Native code could even survive an image restarts, but i forcely clearing it when fresh image starts, because there is too much nuances, where it won't go (for instance, you were running image under Squeak VM, and then restarted it under Cog).
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Â Â Â Â Add one and take log10() over the buffer; in-place transformation! */ { Â Â Â Â for(unsigned long i=0; i<size; i++){ Â Â Â Â data[i] = log10(data[i]+1); Â Â Â Â } }
That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Indeed. Â It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
- Stephen
_______________________________________________ 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
_______________________________________________ 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.
Sig, I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't. One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Thursday, September 30, 2010 9:20 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. On 30 September 2010 22:56, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
Another question, and I don't know the answer yet, involves something that is not done via NativeBoost but is instead "just left to Cog" to optimize. Will something like replacing a double array with log(abs(buffer[i])+1) be reliably translated? Some seem to be suggesting that stuff like that and worse will just magically be as fast as if one took the time to code a C function and put it in shared library. Maybe it will. Any ideas?
I'm not sure what you mean. Do you mean to make special #atLogAbs: method, which reads an element from array , but before returning a value calls log(abs(..))? This will be faster with primitive, since smalltalk if you do that: result := ((array at: i) abs+1) log. It has to do boxing/unboxing the floats at each send.
Not long enough, I got "the fail-over code for your PLUGIN (emphasis added) will take care of it" in response to questions about the vm's silent refusal to load functions from a library that was in fact the sole platform support for a piece of hardware. Even if there were backup Smalltalk code to talk to the device, it would not do the threading magic to run in the background, and it would not be fast enough to do the job.
Less extreme but just as important are functions for Fourier and Wavelet Transforms, etc. I try to find shared libraries for such things, but there is invariably glue that might not be well supported and calls for some native code of some type, whether that comes from Cog, NativeBoost, or another function in a workhorse library of mine.
Not sure what you mean.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Thursday, September 30, 2010 2:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Work can be many things. Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
Its up to you, of course. The native code is held inside a compiled method(s), and once it generaetd not dismissed unless you instruct so. So, it doesn't matters how much time it takes to generate code, because it done once at first method invocation, and then dropped only if you change the method or do 'NativeBoost clearNativeCode'.
Native code could even survive an image restarts, but i forcely clearing it when fresh image starts, because there is too much nuances, where it won't go (for instance, you were running image under Squeak VM, and then restarted it under Cog).
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
- Stephen
_______________________________________________ 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
_______________________________________________ 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
Hello 2010/10/1 Schwab,Wilhelm K <bschwab@anest.ufl.edu>
I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else)
I have many complex math stuff implemented in smalltalk and C in university. And my experience that no matter C or smalltalk you use for formula (equation) programming. In any case it will be not math formula like on paper. And readability will be bad. Debugging is bad because of complex calculations and diffirences in math formula and program language analogue. Just see fast fourier transformation. Equations is not so complex. But programme implementation... Ideally programming math formula or equation should not exists for user. You just put native math formula presentation to system and get results. Maybe similar solution exists?
Just a thought, I would say that Lukas Helvetia framework could be used here, to cleanly embed C++, C or whatever you like syntax into the existing Smalltalk ambient. So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code. Fernando On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote:
Sig,
I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
Bill
......
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
On 1 October 2010 10:33, Fernando olivero <fernando.olivero@usi.ch> wrote:
Just a thought,
I would say that Lukas Helvetia framework could be used here,  to cleanly embed C++, C or whatever you like  syntax into the existing Smalltalk ambient.
Yes, I like the idea of using Helvetia. I would be cool to invent some kind of platform-neutral assembler language. If one likes to write C or C++ , it would be cool too.
So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code.
Fernando
On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote:
Sig,
I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. Â In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
Bill
......
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com<mailto:siguctua@gmail.com>> wrote: On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Â Â Â Add one and take log10() over the buffer; in-place transformation! */ { Â Â Â for(unsigned long i=0; i<size; i++){ Â Â Â data[i] = log10(data[i]+1); Â Â Â } }
That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
_______________________________________________ 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.
On Oct 1, 2010, at 2:39 AM, "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> wrote:
Sig,
I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
Regarding syntax, I'm all in favor of using special purpose languages where it makes sense (but my intuition says that should be done sparingly or else everything will degenerate into an incomprehensible mess). In this case it would be very nice to think about a language designed specifically for expressing mathematical expressions rather than C++ (which btw I don't agree is better for expressing formulas...it's just different and perhaps closer to conventional mathematical syntax). Regarding performance, I think it's entirely possible to get similar performance to C++ in Smalltalk (or just about any other language for that matter)...however, I'm not aware of anything that can do this today. You could deal with the boxing/unboxing overhead with a sufficient amount of inlining based on runtime type analysis. Once fully inlined, you can apply more traditional optimization techniques. I don't even think this would be particularly hard to do (and to a degree it's all been done before), but it is a lot of work. As I said, I'm not aware of anything readily available that achieves these things. So, to get the performance you seek in a slightly more pleasing syntax (beauty is in the eye of the beholder), C++ may be your best bet for now. - Stephen
2010/9/30 Stephen Pair <stephen@pairhome.net>:
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Â Â Â Â Add one and take log10() over the buffer; in-place transformation! */ { Â Â Â Â for(unsigned long i=0; i<size; i++){ Â Â Â Â data[i] = log10(data[i]+1); Â Â Â Â } }
That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Suddenly, this reminds me ST/X... Nicolas
Indeed. Â It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization). - Stephen _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ST/X has some loyal followers, but it never really grabbed me. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Thursday, September 30, 2010 1:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. 2010/9/30 Stephen Pair <stephen@pairhome.net>:
On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
void LogOnePlus(double * data, unsigned long size) /* Add one and take log10() over the buffer; in-place transformation! */ { for(unsigned long i=0; i<size; i++){ data[i] = log10(data[i]+1); } }
That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
Of course its possible. After porting C parser/compiler into smalltalk :) Or perhaps some meta-language which looks like C, but which easier to translate to native code.
Suddenly, this reminds me ST/X... Nicolas
Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization). - Stephen _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Alberto Bacchelli -
Denis Kudriashov -
Fernando olivero -
Igor Stasenko -
Nicolas Cellier -
Schwab,Wilhelm K -
Stephen Pair -
stephen＠pairhome.net