In message <[EMAIL PROTECTED]> (on 20 December 2004 20:48:23 +0100), [EMAIL PROTECTED] (Tels) wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Moin Allen, > >On Monday 20 December 2004 01:20, Ed Allen Smith wrote: >> In message <[EMAIL PROTECTED]> (on 19 December 2004 17:00:54 >> >> +0100), [EMAIL PROTECTED] (Tels) wrote: >> >-----BEGIN PGP SIGNED MESSAGE----- >> > >> >Moin Ed, >> >> Allen, but don't worry about it. > >Oh, sorry :) Excuse my igorance, but is "Ed" some sort of prefix like "Dr."?
No, I'm just called by my middle name - I was noting it for your future reference. I normally sign my messages -Allen, but must have forgotten. (The only reason I haven't changed my "Full Name" system entry is that it does help people remember the e in my email address...) >> >Can you please retry this with v1.74 from: >> > >> > http://bloodgate.com/perl/packages/devel/Math-BigInt-1.74.tar.gz >> >> Yep, works, thanks! BTW, what exactly are the changes for 64-bit systems? >> We're locally running with 64bitint (IRIX cc -n32) and long doubles, so >> this is a matter of interest here... > >You mean in Bigint v1.74 or in FastCalc v0.07? FastCalc doesn't have any >specific 64 bit code AFAIR. And I can't remember changing in 64bit for BigInt >(or even testing it with that - I probably should do this..) in the last year >or so.. See below... >What it basically amounts to is (warning, long winded): > >* FastCalc is like Calc, only that certain things are in XS to speed it up a >little. It should never be slower than Calc, but it will also not be much >faster (e.g. it will be linear, like factor 1.x, or 2.x - it will not change >things from O(N*N) to O(N) for instance.). All it cuts down is Perl >overhead. Depending on the frequency of various operations, I would anticipate that making a significant difference... linear can be helpful in borderline cases, though. >(It does not cut down overhead from BigInt itself, or overloaded math >overhead on top of that.) >* Basically, both Calc and FastCalc store the number in decimal, chopped into >parts. Got it. >* on most (32-bit) systems, each part contains 7 digits (the original BigInt >v0.1 used 5 digits). On some systems (older perl, uts, unicos etc) it uses >only 5 because these are known not to be able to chew on so big parts. On 64 >bit systems it *could* use 8 or even 9 (depending on what fits into an >integer), but reading the code I see it is now hard-coded and limited to 7, >because 8 produces failures in the random-code testcases. (I always wanted to >investigate how I can use 8 or 9 digits per part on 64 bit Perls. Need a >reliable metric to find out when.) Yes... with what versions of Perl were you seeing the random-code testcase failures on 64-bit machines? I am wondering regarding various NV_PRESERVES_UV changes that have taken place. (This reminds me of that I still need to finish up testing A. Perl_my_atof2 tuning and B. Math::Trig improved formulae...) >Hm, I should upate the "CHANGES" file. And >while I am at it, swap HISTORY and CHANGES, too. That was what I was referring to in regard to 64-bit machines - the references in the CHANGES file. >* More digits per part => less parts. Since operations are O(N) etc (where N >is the number of parts a certain input has), this means faster operations. Got it. >* Especially on border cases and for small numbers this matters because there >are many shortcuts for one-part inputs: > > [EMAIL PROTECTED]:~> cat bench.pl > #!/usr/bin/perl -w > > use Math::BigInt; > use Benchmark; > > my $c = 'Math::BigInt'; > my $x = $c->new('1234567'); > my $y = $c->new('1234567'); > my $u = $c->new('12345678'); > my $v = $c->new('12345678'); > > timethese (-5, > { > '1234567 * 1234567' => sub { $x * $y }, > '12345678 * 12345678' => sub { $u * $v }, > } ); > [EMAIL PROTECTED]:~> perl bench.pl > Benchmark: running 1234567 * 1234567, 12345678 * 12345678 for at least > 5 CPU seconds... > 1234567 * 1234567: 5s (5.27 usr + 0.01 sys = 5.28 CPU) 29903/s (n=157891) > 12345678 * 12345678: 5s (5.24 usr + 0.01 sys = 5.25 CPU) 20957/s (n=110026) > >Note: Benchmark contains overhead of BigInt and overloaded math, so in >reality the difference inside Calc is even bigger. > >* GMP stores the number internally in base-2. That means it can do certain >things _much_ faster, but it might only really pay off for big/huge >numbers. Got it. >It is amazing that sometimes the Perl code in Calc is faster than the XS => C >libgmp interface in GMP.pm :o) This causes me to wonder if some form of adaptive code - different calls depending on the size of the problem or whatever - may be advisable, or if such would introduce too much overhead to be worth it... although a simple rule of "use Calc if number of parts is <= X" might be fast enough to work, if there are already special cases for some X. >> >As for FastCalc failing, I intent to deprecate that package. It really >> >doesn't speed things up much, but creates tons of problems due to XS. >> >> Oh? Interesting. It had actually speeded things up by probably a factor of >> 2 or so here, albeit in comparison to 1.73 Calc. > >Oh. Cool. That shows that benchmarks are worthless. :) Heh. I suspect this might be linked with how many operations are involved and what operations are used, plus with what computer, compiler, compilation flags, etcetera are in use. Also note that this is probably a linear speedup, as you say above - I haven't tested it with that many sizes of problems. >(When I wrote FastCalc, I was faszinated by how much faster loops are, >f.i., in XS than in Perl Ah! This is going to be something that will considerably vary depending on the compiler and computer. SGI compilers are known for being rather good at various sorts of optimization, including loop unrolling et al _if_ they can figure out how the loop is going. (They're also rather slow, require enough flags to overrun normal command line limits for optimal performance, etcetera... sigh!) An interpreter is likely to be rather more difficult in this regard than is XS. >- I did some quick benchmarks a few weeks ago and couldn't find anything > that was substantially faster - so got the idea to "get rid of it"). What system did you do the benchmarks on, and of what operations? >The "problems" with the XS are that it introduces another maintaince >package for me on top of Calc. it just duplicates a lot of code, and >introduces it's own source of bugs (XS), which somehow feels all wrong to >me. Understand! Given that I don't like C much myself, I would actually personally prefer to go with pure Perl likewise, but practical considerations may override this. >Anyway, I'll let FastCalc live then. Thanks! I will try to let you know how things develop with later versions et al, including of compilation flags (I know more about this than when I compiled perl on the local systems previously), Perl itself, compilers, etcetera. It may well change. Advice to people in the FastCalc README and manpage to test to see whether or not it's worth it may be advisable... >Calc hasn't changed much in the last >versions of BigInt - all I did was reducing the overhead in BigInt itself. >The last Calc related change was in Bigint v1.70 when I simplified it's >interface to BigInt (thats why a new FastCalc was also neccessary). Ah! >> >If you look for a lib to replace Calc, please use 'GMP', it scales much >> >better and is quite stable now. :o) >> >> OK, will take a look, thanks! > >Please tell me about the performance and whether you encounter any bugs. I am >currently at releasing new versions of almost all my math modules, so that >will help! Will do; I will be going out of town shortly and am currently working on ATLAS compilations, so I can't guarantee anything, but I'll try. >Thanx for using my work and for the feedback, Thanks for all your work! >Tels > >PS: Sorry, if I buried you in technical details :) Heh. As I said, I'm currently working on ATLAS compilations (as in updating its porting and optimization for IRIX). Something that's at least partially Perl is much nicer :-}. -Allen -- Allen Smith http://cesario.rutgers.edu/easmith/ There is only one sound argument for democracy, and that is the argument that it is a crime for any man to hold himself out as better than other men, and, above all, a most heinous offense for him to prove it. - H. L. Mencken
