[Pharo-project] NativeBoost and Cog. A working protype.

Schwab,Wilhelm K bschwab at anest.ufl.edu
Fri Oct 1 02:39:57 EDT 2010


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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
Sent: Thursday, September 30, 2010 9:20 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.

On 30 September 2010 22:56, Schwab,Wilhelm K <bschwab at 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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
> Sent: Thursday, September 30, 2010 2:37 PM
> To: Pharo-project at lists.gforge.inria.fr
> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>
> On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab at 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 at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen at pairhome.net]
>> Sent: Thursday, September 30, 2010 11:33 AM
>> To: Pharo-project at 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 at gmail.com<mailto:siguctua at gmail.com>> wrote:
>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab at anest.ufl.edu<mailto:bschwab at 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 at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




More information about the Pharo-dev mailing list