Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^4: bigint == horrible performance?

by salva (Monsignor)
on Nov 08, 2011 at 11:20 UTC ( #936750=note: print w/ replies, xml ) Need Help??


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

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


Comment on Re^4: bigint == horrible performance?
Re^5: bigint == horrible performance?
by syphilis (Canon) on Nov 08, 2011 at 12:03 UTC
    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
Re^5: bigint == horrible performance?
by mojotoad (Monsignor) on Dec 13, 2011 at 08:15 UTC
    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.

    Thanks,
    Matt

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://936750]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (16)
As of 2014-10-21 07:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (98 votes), past polls