Fun with spock (NativeBoost FFI)

>
> On May 14, 2012, at 12:49 AM, Igor Stasenko wrote:
>
>> On 14 May 2012 00:03, Lawson English <[hidden email]> wrote:
>>> [pharo-project list added back in]
>>>
>>>
>>> On 5/13/12 1:34 PM, Nicolas Cellier wrote:
>>>>
>>>> [100000 primeSwingFactorial] timeToRun 3411 [100000 factorial] timeToRun
>>>> 61219 So gmp is still 40x faster than a reasonably optimized Smalltalk
>>>> factorial... I think that's fair, because gmp is highly optimized. Since
>>>> cost is dominated by LargeInteger arithmetic, and since Smalltalk
>>>> LargeInteger arithmetic in primitives still operates on bytes, I'm not so
>>>> surprised of the gap... I'd like to see a 64bit image operating on 32 bits
>>>> positive integers digits, that would already be a progress... Nicolas
>>>
>>>
>>> For me, the most interesting thing would be to figure out how to integrate
>>> such external libraries more tightly into the language syntax.
>>>
>>> Right now,   x :=  3.14159... always creates a Float, which is stored as a
>>> double.
>>>
>>> x class ===> Float.
>>>
>>> What if I wanted to generate a gmplib floating point number (or rational or
>>> large integer) automatically when the gmplib binding is available?
> For Floats, there is a GNU project maintained by some groups at Inria:
>
>        http://www.mpfr.org/
>
> The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both
> efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for
> double-precision floating-point arithmetic (53-bit significand).
>
>

> 2012/5/14 Marcus Denker <[hidden email]>:
>>
>> On May 14, 2012, at 12:49 AM, Igor Stasenko wrote:
>>
>>> On 14 May 2012 00:03, Lawson English <[hidden email]> wrote:
>>>> [pharo-project list added back in]
>>>>
>>>>
>>>> On 5/13/12 1:34 PM, Nicolas Cellier wrote:
>>>>>
>>>>> [100000 primeSwingFactorial] timeToRun 3411 [100000 factorial] timeToRun
>>>>> 61219 So gmp is still 40x faster than a reasonably optimized Smalltalk
>>>>> factorial... I think that's fair, because gmp is highly optimized. Since
>>>>> cost is dominated by LargeInteger arithmetic, and since Smalltalk
>>>>> LargeInteger arithmetic in primitives still operates on bytes, I'm not so
>>>>> surprised of the gap... I'd like to see a 64bit image operating on 32 bits
>>>>> positive integers digits, that would already be a progress... Nicolas
>>>>
>>>>
>>>> For me, the most interesting thing would be to figure out how to integrate
>>>> such external libraries more tightly into the language syntax.
>>>>
>>>> Right now,   x :=  3.14159... always creates a Float, which is stored as a
>>>> double.
>>>>
>>>> x class ===> Float.
>>>>
>>>> What if I wanted to generate a gmplib floating point number (or rational or
>>>> large integer) automatically when the gmplib binding is available?
>> For Floats, there is a GNU project maintained by some groups at Inria:
>>
>>        http://www.mpfr.org/
>>
>> The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both
>> efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for
>> double-precision floating-point arithmetic (53-bit significand).
>>
>>
>
> Of course, this is a reference and I've added a link page from
> http://code.google.com/p/arbitrary-precision-float/ in
> http://code.google.com/p/arbitrary-precision-float/wiki/InspirationSources
> en clin d'oeil ;)
>
> I recommend the light weight Smalltalk library for casual need, fun,
> education and experimentation.
> For completness, decimal arithmetic, speed and intensive use, a 100%
> Smalltalk single programmer library developed in spare time cannot
> beat many man-years of development of GMP/MPFFR, so the choice shall
> be quite obvious.
>
> ArbitraryPrecisionFloat might still be an option as a fallback code,
> or for in image replication necessary for persisting external heap
> allocated data...
>
> Nicolas
>
>>
>> --
>> Marcus Denker -- http://marcusdenker.de
>>
>>
>

> The biggest downside of GMP library, is that you have to  manage
> resources in C way - i.e. manually..
> No GC -> more homework for adopter(s), and less performance.
>
> In docs it even says: yeah you can plug-in own memory management function(s),
> but beware that memory blocks can have pointers to each other.
> Which means, that even if i create a custom allocator to force this
> library to use
> object memory as heap, it won't work under moving GC.
>

> On 17 May 2012 01:37, Nicolas Cellier
> <[hidden email]> wrote:
>> 2012/5/14 Marcus Denker <[hidden email]>:
>>>
>>> On May 14, 2012, at 12:49 AM, Igor Stasenko wrote:
>>>
>>>> On 14 May 2012 00:03, Lawson English <[hidden email]> wrote:
>>>>> [pharo-project list added back in]
>>>>>
>>>>>
>>>>> On 5/13/12 1:34 PM, Nicolas Cellier wrote:
>>>>>>
>>>>>> [100000 primeSwingFactorial] timeToRun 3411 [100000 factorial] timeToRun
>>>>>> 61219 So gmp is still 40x faster than a reasonably optimized Smalltalk
>>>>>> factorial... I think that's fair, because gmp is highly optimized. Since
>>>>>> cost is dominated by LargeInteger arithmetic, and since Smalltalk
>>>>>> LargeInteger arithmetic in primitives still operates on bytes, I'm not so
>>>>>> surprised of the gap... I'd like to see a 64bit image operating on 32 bits
>>>>>> positive integers digits, that would already be a progress... Nicolas
>>>>>
>>>>>
>>>>> For me, the most interesting thing would be to figure out how to integrate
>>>>> such external libraries more tightly into the language syntax.
>>>>>
>>>>> Right now,   x :=  3.14159... always creates a Float, which is stored as a
>>>>> double.
>>>>>
>>>>> x class ===> Float.
>>>>>
>>>>> What if I wanted to generate a gmplib floating point number (or rational or
>>>>> large integer) automatically when the gmplib binding is available?
>>> For Floats, there is a GNU project maintained by some groups at Inria:
>>>
>>>        http://www.mpfr.org/
>>>
>>> The main goal of MPFR is to provide a library for multiple-precision floating-point computation which is both
>>> efficient and has a well-defined semantics. It copies the good ideas from the ANSI/IEEE-754 standard for
>>> double-precision floating-point arithmetic (53-bit significand).
>>>
>>>
>>
>> Of course, this is a reference and I've added a link page from
>> http://code.google.com/p/arbitrary-precision-float/ in
>> http://code.google.com/p/arbitrary-precision-float/wiki/InspirationSources
>> en clin d'oeil ;)
>>
>> I recommend the light weight Smalltalk library for casual need, fun,
>> education and experimentation.
>> For completness, decimal arithmetic, speed and intensive use, a 100%
>> Smalltalk single programmer library developed in spare time cannot
>> beat many man-years of development of GMP/MPFFR, so the choice shall
>> be quite obvious.
>>
>> ArbitraryPrecisionFloat might still be an option as a fallback code,
>> or for in image replication necessary for persisting external heap
>> allocated data...
>>
>> Nicolas
>>
>>>
>>> --
>>> Marcus Denker -- http://marcusdenker.de
>>>
>>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

> 2012/5/17 Igor Stasenko <[hidden email]>:
>> The biggest downside of GMP library, is that you have to  manage
>> resources in C way - i.e. manually..
>> No GC -> more homework for adopter(s), and less performance.
>>
>> In docs it even says: yeah you can plug-in own memory management function(s),
>> but beware that memory blocks can have pointers to each other.
>> Which means, that even if i create a custom allocator to force this
>> library to use
>> object memory as heap, it won't work under moving GC.
>>
>
> Funny, GST use GMP, and I was just reading Paolo Bonzini reporting GC
> was not efficient here:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-March/126700.html
>

> On 17 May 2012 02:52, Nicolas Cellier
> <[hidden email]> wrote:
>> 2012/5/17 Igor Stasenko <[hidden email]>:
>>> The biggest downside of GMP library, is that you have to  manage
>>> resources in C way - i.e. manually..
>>> No GC -> more homework for adopter(s), and less performance.
>>>
>>> In docs it even says: yeah you can plug-in own memory management function(s),
>>> but beware that memory blocks can have pointers to each other.
>>> Which means, that even if i create a custom allocator to force this
>>> library to use
>>> object memory as heap, it won't work under moving GC.
>>>
>>
>> Funny, GST use GMP, and I was just reading Paolo Bonzini reporting GC
>> was not efficient here:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-March/126700.html
>>
>
> i'm not sure what efficiency you referring to.
> sure thing a total run time for any algorithm under GC is affected by GC.
> But i really doubt that if you won't use GC, you will waste less time
> on resource management,
> given that your algorithm allocate & manage same amount of memory.
>