Smalltalk › Pharo › Pharo Smalltalk Developers

NativeBoost and Cog. A working protype.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Igor Stasenko

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K

Re: NativeBoost and Cog. A working protype.

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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
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
[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

Igor Stasenko

Re: NativeBoost and Cog. A working protype.

On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]> 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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Alberto Bacchelli

Re: NativeBoost and Cog. A working protype.

On 9/30/10 5:41 AM, Igor Stasenko wrote:

> On 30 September 2010 06:20, Schwab,Wilhelm K<[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor Stasenko

Re: NativeBoost and Cog. A working protype.

On 30 September 2010 11:18, Alberto Bacchelli <[hidden email]> wrote:

> On 9/30/10 5:41 AM, Igor Stasenko wrote:
>>
>> On 30 September 2010 06:20, Schwab,Wilhelm K<[hidden email]>
>> 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
> [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

Stephen Pair

Re: NativeBoost and Cog. A working protype.

In reply to this post by Igor Stasenko

On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]> wrote:

On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K

Re: NativeBoost and Cog. A working protype.

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: [hidden email] [[hidden email]] On Behalf Of Stephen Pair [[hidden email]]
Sent: Thursday, September 30, 2010 11:33 AM
To: [hidden email]
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.

On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]<mailto:[hidden email]>> wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> wrote:

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: NativeBoost and Cog. A working protype.

In reply to this post by Stephen Pair

2010/9/30 Stephen Pair <[hidden email]>:

> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]>
>> 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
> [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

Schwab,Wilhelm K

Re: NativeBoost and Cog. A working protype.

ST/X has some loyal followers, but it never really grabbed me.

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Nicolas Cellier [[hidden email]]
Sent: Thursday, September 30, 2010 1:39 PM
To: [hidden email]
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.

2010/9/30 Stephen Pair <[hidden email]>:

Igor Stasenko

Re: NativeBoost and Cog. A working protype.

In reply to this post by Schwab,Wilhelm K

On 30 September 2010 20:30, Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Stephen Pair [[hidden email]]
> Sent: Thursday, September 30, 2010 11:33 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>
> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]<mailto:[hidden email]>> wrote:
> On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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
> [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

Schwab,Wilhelm K

Re: NativeBoost and Cog. A working protype.

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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Thursday, September 30, 2010 2:37 PM
To: [hidden email]
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.

On 30 September 2010 20:30, Schwab,Wilhelm K <[hidden email]> 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).

--
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

Igor Stasenko

Re: NativeBoost and Cog. A working protype.

On 30 September 2010 22:56, Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
> Sent: Thursday, September 30, 2010 2:37 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>
> On 30 September 2010 20:30, Schwab,Wilhelm K <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Stephen Pair [[hidden email]]
>> Sent: Thursday, September 30, 2010 11:33 AM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>
>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]<mailto:[hidden email]>> wrote:
>> On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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
>> [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
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K

Re: NativeBoost and Cog. A working protype.

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: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Thursday, September 30, 2010 9:20 PM
To: [hidden email]
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.

On 30 September 2010 22:56, Schwab,Wilhelm K <[hidden email]> 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.

Denis Kudriashov

Re: NativeBoost and Cog. A working protype.

Hello

2010/10/1 Schwab,Wilhelm K <[hidden email]>

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?

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Fernando olivero-2

Re: NativeBoost and Cog. A working protype.

In reply to this post by Schwab,Wilhelm K

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: [hidden email] [[hidden email]] On Behalf Of Stephen Pair [[hidden email]]
>>> Sent: Thursday, September 30, 2010 11:33 AM
>>> To: [hidden email]
>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>>
>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]<mailto:[hidden email]>> wrote:
>>> On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor Stasenko

Re: NativeBoost and Cog. A working protype.

On 1 October 2010 10:33, Fernando olivero <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Stephen Pair [[hidden email]]
>>>> Sent: Thursday, September 30, 2010 11:33 AM
>>>> To: [hidden email]
>>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>>>
>>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <[hidden email]<mailto:[hidden email]>> wrote:
>>>> On 30 September 2010 06:20, Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>> 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
> [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

Stephen Pair

Re: NativeBoost and Cog. A working protype.

In reply to this post by Schwab,Wilhelm K

On Oct 1, 2010, at 2:39 AM, "Schwab,Wilhelm K" <[hidden email]> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project