-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/10/2010 02:20 PM, Simonson, Lucanus J wrote:
My experience with GMP has been that reusing existing GMP objects instead of declaring new ones was a significant performance enhancement. I don't think it is true that cost of operations is even greater than the cost of allocation, mush less significantly so, in general.
That depends on the size you're using and what you're doing with it. For a 65-bit integer like you mentioned, doing nothing but addition and subtraction, you're right. For a 4096-bit one using a lot of exponentiation (think RSA encryption), the cost of the operations will *definitely* outweigh the cost of allocation, and by such a large margin that the allocation will be completely unnoticeable. Most examples will fall somewhere between those two extremes.
It is reasonable, particularly with fixed integer, to expect that the common case will be operations on a number of bits only slightly larger than the built in integer types support. If I need 65 bits (and I do) I will code it myself rather than pay for an allocation (and I did).
That's certainly a viable option, if you've got the luxury of the time and interest to do it. Your average developer often doesn't, or values his own time more than he needs efficiency in that part of his program. The library is designed for large integers -- something that's usually noticeably larger than 65 bits -- so it probably won't be optimal for really small integers like that. It'll get the job done though, so I don't consider that a problem.
It isn't clear to me what fixed integer provides if it allocates on the heap. Why would anyone use it?
Because it simplifies his life. I can't predict what problems someone might put it to, but I can imagine a few, such as emulating an old mainframe or minicomputer that had an odd number of bits (I've heard of computers with everything from seven to 36 bits, for instance). It was a requested feature, and it required very little additional effort, so I added it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwRPKgACgkQp9x9jeZ9/wRylQCeP7abF9+Xf1btTmSk2rchcVPi AiwAoMcZUxvPYmt+4StdK1WLwWh2SDaE =Qsoc -----END PGP SIGNATURE-----