in reply to Re^4: bigint == horrible performance?
in thread bigint == horrible performance?

Hi salva, sorry for the delay in responding.

I don't have the particular hardware in front of me at the moment, but as I recall: The problem wasn't in the runtime, it was during compilation. There was a particular pragma or definition required which was dependent on the version of glib installed. It was explicitly mentioned in a thread here on PM which I found while googling. I didn't have the time to deep-dive into it at the time.

I'll update this node once I get back on the system in question and give you the specific reference. Perhaps you can save me some time with the deep-diving.

update: Okay, found it. It's this business regarding how TI gets manipulated with __attribute__ and __mode__. Salient details:

I didn't pursue it much further because the project I was working on has to be very portable (mostly across linuxes, some solaris) across 32 and 64 bit architectures. I'm not saying your code isn't portable, but I'd like to avoid exceptional cases if possible.

On a more general note, for both Math::Int64 and Math::Int128, I would very much like a way to catch overflow conditions at the XS level; without this I have to punt to Math::BigInt when I'd really rather have the speed of your modules.


Replies are listed 'Best First'.
Re^6: bigint == horrible performance?
by salva (Canon) on Dec 20, 2011 at 13:34 UTC
    I would very much like a way to catch overflow conditions at the XS level

    Check the development version of Math::Int64 now supporting a die_on_overflow pragma that does just that.