I really mean both. It's possible that new MPN_COPY code which we'll have relatively soon, will remove some of the performance deficit, but there are still many cases where one can avoid a copy altogether, use mpn's directly instead of mpz's or otherwise avoid using mpz_import/export with its associated overhead.
Of course I exaggerated on purpose, so that it would be cause for thought. But ultimately the observation is based in experience. Another issue associated with mpz_import and mpz_export is cache locality. If you have lots of different integers distributed throughout memory and you are importing to or from them, then likely you will have a lot of cache misses. It's often worthwhile figuring out a way to change the algorithm so this doesn't happen. Ultimately it all boils down to the observation that one should avoid unnecessary copies of data where possible, in timing critical code. Bill. 2009/5/23 Marc <[email protected]>: > > On May 22, 9:49 pm, Bill Hart <[email protected]> wrote: >> The main reason I recommended not to use that function in time >> critical stuff is it is very, very slow (for reasons I don't >> understand). > > When the endianness and everything is right, mpz_import and mpz_export > use MPN_COPY which calls copyi (on platforms where it exists), which > should be similar to memcpy (if there is a significant performance > difference between the 2 (and tune/speed can measure this easily), > something is wrong). So do you mean the overhead (there is quite a > bit, with several function calls and tests besides the allocation and > copy) is too much when dealing with many small integers? Or do you > mean there shouldn't even be a copy, exporting should just give a > pointer to the internal data (and make sure no one calls mpz_clear) > and importing should let a mpz take ownership of an existing buffer? > (This type of passing buffers around works better with a garbage > collector) > > Anyway, just from the name of the functions, it seems normal to try > and avoid continually importing/exporting in a critical part of the > code indeed... > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
