2012/5/17 Igor Stasenko <siguctua at gmail.com>:
> On 17 May 2012 02:52, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2012/5/17 Igor Stasenko <siguctua at gmail.com>:
>>> 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.
>

Not sure either :)

> With GMP, you can create a single number and mutate it, instead of
> creating new instances
> to hold an operation result.
> But i think you are agree that if you will do that, then comparison
> will be unfair.
>

Agree.
Beside, I once proposed to reduce creation of Rectangles and Points in
Morphic by mutating them when we knew we could.
I think that was my worse idea ever, turning a quasi-functional-like
nice feature into a potential stateful nightmare.
I also plaid this game with ArbitraryPrecisionFloat which has
inPlace... selectors, but since LargeInteger are not mutated (they
shall better not), this is a not really rewarding complexification.

Nicolas

>> Nicolas
>>
>
> --
> Best regards,
> Igor Stasenko.
>