[Pharo-project] [squeak-dev] Fun with spock (NativeBoost FFI)

Igor Stasenko siguctua at gmail.com
Thu May 17 00:28:07 UTC 2012


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
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2012/5/14 Marcus Denker <marcus.denker at inria.fr>:
>>
>> On May 14, 2012, at 12:49 AM, Igor Stasenko wrote:
>>
>>> On 14 May 2012 00:03, Lawson English <lenglish5 at cox.net> 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.


More information about the Squeak-dev mailing list