And those that shouldn't be INT_TYPE should probably be size_t or ptrdiff_t instead. I suspect there are actually only a few places where int or INT32 really is the most appropriate type.

/ Martin Stjernholm, Roxen IS

Previous text:

2003-01-26 17:17: Subject: INT_TYPE = INT64

---

There are probably still some 'INT32' or 'int' variables that should actually be INT_TYPE.

/ Per Hedbor ()

There are a bunch of other funny errors, too:

| > sprintf("%x",281474976710656); | Result: "%"

And I suspect there is some bit rot in the Gmp.mpz routine:

| > Gmp.mpz(100000000000000); | (22) Result: 100000000000000 // correct INT64 -> mpz | > Gmp.mpz(1000000000000000); | (23) Result: 155575120199680 // duh? | > Gmp.mpz(10000000000000000); | (24) Result: 148376402329600 | > Gmp.mpz(100000000000000000); | (25) Result: 76389223628800 | > Gmp.mpz(1000000000000000000); | (26) Result: 200942316421120 | > Gmp.mpz(10000000000000000000); // mpz -> mpz again | (27) Result: 10000000000000000000

/ Mirar

Previous text:

2003-01-26 17:20: Subject: INT_TYPE = INT64

---

And those that shouldn't be INT_TYPE should probably be size_t or ptrdiff_t instead. I suspect there are actually only a few places where int or INT32 really is the most appropriate type.

/ Martin Stjernholm, Roxen IS

Popcount tells how many nonzero bits the number contains i twos complement. Since negative numbers contain an infinite number of nonzerobits, popcount() is not defined for negative numbers and simply return -1.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2003-01-26 23:28: Subject: INT_TYPE = INT64

---

I think the operation went rather successfull. I now seem to have a working Pike with 64-bit INT_TYPE. =^.^=

I only have 9 errors left in the testsuite now, of which about half is really obscure (Image issues) and the others just a little obscure (mpz).

What is ->popcount()?

| /home/mirar/pike/src/modules/Gmp/testsuite.in:222: Test 3395 (shift 2) failed. | 1: mixed a() { return Gmp.mpz(-1)->popcount(); } | 2: mixed b() { return -1; } | 3: | | o->a(): 4294967295 | o->b(): -1

/ Mirar

Some recent changes in the Gmp module seems to make it not load under certain circumstances:

| % pike 'werror("%O\n",84729847928734928374928374928347)' | Gmp.mpz conversion failed. | ./master.pike:251: | master()->compile_string("#define NOT(X) !(X)\n#define CHAR(X) 'X'\nmixed | run(int argc, array(string) argv,mapping(string:string) env){werror("%O\n",84729847928734928374928374928347);}",0,0)

| % pike 'werror("%O\n",Gmp.mpz);' | Gmp.mpz

I verified that the first never installs auto_bignum_program, but the forced module initiation in the second does.

Note: This is also broken in the pike previous to my INT_TYPE hacking.

/ Mirar

Previous text:

2003-01-26 23:54: Subject: INT_TYPE = INT64

---

Ah.

Benchmarks:

test 64-bit integers 32-bit integers Pike start overhead...... 0.000s 0.000s Ackermann................ 0.635s 0.610s Array & String Juggling.. 0.693s 0.654s Clone null-object........ 0.190s 22105263 0.181s 36482412/s Clone object............. 0.366s 7386018 0.396s 8325688/s Compile.................. 1.132s 85263 1.066s 113227 lines/s Compile & Exec........... -error- -error- GC....................... 0.580s 0.601s Matrix multiplication.... -error- -error- Loops Nested (local)..... 0.331s 506864532 0.316s 743967044 iters/s Loops Nested (global).... 0.537s 218639251 0.487s 310263584 iters/s Loops Recursed........... 1.045s 4013688 1.312s 3195660 iters/s

Both with 12-byte svalues (ie, double precision floats). Note that recursing loops seems to be faster (?!?) with 64-bit integers.

/ Mirar

Do you have a feeling for the accurancy in those figures? Are the results significant to the last digit?

/ Martin Stjernholm, Roxen IS

Previous text:

2003-01-27 12:35: Subject: INT_TYPE = INT64

---

Never minding that the benchmark test was broken, I've redone it now under better circumstances (and more test iterations). I also added a few tests to measure number creation with %<n>c - %4c gets Really Slow if the numbers parsed gets larger then MAXINT.

(wider then 80 characters, sorry)

Athlon XP @ 1600Mhz 12-byte svalue | 8-byte svalue -mcpu=athlon-xp -O3 int64, double | int32, double | int32, float | | Pike start overhead..... 0.000s | 0.001s | 0.001s Ackermann............... 0.632s | 0.618s | 1.061s Array & String Juggling. 0.692s | 0.676s | 0.669s Read binary INT16....... 0.307s 3260870 | 0.251s 3989704 | 0.245s* 4079111 (/s) Read binary INT32....... 0.190s* 2638191 | 2.158s 231696 | 2.082s* 240154 (/s) Read binary INT128...... 0.888s 11261 | 0.773s* 12931 | 0.795s 12586 (/s) Clone null-object....... 0.201s 1496259 | 0.182s 1645408 | 0.179s* 1677763 (/s) Clone object............ 0.378s* 794702 | 0.393s 763889 | 0.380s 789474 (/s) Compile................. 1.107s 21797 | 1.064s 22678 | 1.048s* 23045 (lines/s) Compile & Exec.......... 0.972s* 618406 | 1.121s 536366 | 0.978s 615068 (lines/s) GC...................... 0.606s | 0.608s | 0.532s* Matrix multiplication... 0.423s | 0.411s | 0.406s* Loops Nested (local).... 0.342s 49012092 | 0.313s 53544306 | 0.250s 67108880 (iters/s) Loops Nested (global)... 0.550s 30504029 | 0.525s 31938709 | 0.459s* 36555864 (iters/s) Loops Recursed.......... 1.112s! 942964 | 1.301s 805712 | 0.858s* 1222116 (iters/s)

• fastest

! faster then expected

/ Mirar

Fixed.

Actually, the libgmp mpz_popcount returns MAXUINT32 (as unsigned long int), so the answer was just not auto-converted to signed. I've added a test for that now, so the answer will stay compatible.

/ Mirar

Previous text:

2003-01-26 23:33: Subject: INT_TYPE = INT64

---

Popcount tells how many nonzero bits the number contains i twos complement. Since negative numbers contain an infinite number of nonzerobits, popcount() is not defined for negative numbers and simply return -1.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

int is often an appropriate type for loop variables in loops with a low maximum upper bound (< 32768).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2003-01-26 17:20: Subject: INT_TYPE = INT64

---

And those that shouldn't be INT_TYPE should probably be size_t or ptrdiff_t instead. I suspect there are actually only a few places where int or INT32 really is the most appropriate type.

/ Martin Stjernholm, Roxen IS