Re^3: bigint == horrible performance?

[mojotoad]

So I've bumped into some stuff lately. XS extensions with no particular expectation of whether you're on an actual 64-bit bus or not. Perl itself actually recommends that it be compiled into 32-bit mode even when on a 64-bit architecture because the docs suppose <it will rarely be actually required>. (those are semi-quotes)

So now, in the XS world, I've found myself facing a couple of things: 64 bit stuff and ipv6 (128 bits).

In the XS world, Math::Int64 works quite nicely. However, I get way too many explosions with Math::128 at this point. So, I end up using packed arrays and timely casting, while hopefully not misplacing network byte-order.

32-bit (and I guess 64-bit?) perl has unsigned, int, 'double', and 'string'. (e.g. UV, IV, NV, and PV). There is no native perl guarantee for 64-bit or 128-bit other than a string.

I understand the perils of assuming too much about the data types. But in the world of XS, <whimper>

Cheers,
Matt

[BrowserUk]

salva produces great code and enthusiastically maintains and extends his modules at the drop of a hat.

Indeed, Math::Int128 came about because I asked a simple question here, and he offered to write one.

And lo, two days later it was so.

If the module is giving you problems, help him to help you. You will not regret the effort.

[salva]

I am really interested in knowing the details of any "explosions" related to Math::Int128. Report them through the CPAN bugtracker, please!

[syphilis]

I am really interested in knowing the details of any "explosions" related to Math::Int128

Me, too. Some elaboration would be appreciated - even if it's just a link to the bug report that salva has requested.

Cheers,
Rob

[mojotoad]

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:

• Math::Int128 version 0.05
• linux 2.6.32-36 (Ubuntu 10.04, yeah yeah)
• gcc v 4.4.3
• you specifically reference this in your comments: http://gcc.gnu.org/gcc-4.4/changes.html which would seem to apply to my version of gcc

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.

Thanks,
Matt

[salva]

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.