I have long worried that our meticulously tuned library suffers from speed regressions which are unnoticed. I am aware of many ways this may happen!
I just now discovered that 64-bit Atom (the original ones, not Silvermont and later) had a major regression for mpn_add_n and mpn_sub_n, from 3 c/l to about 4.3 c/l. These old Atoms are the most important CPUs for GMP, so no real harm done. The x86_64/atom/aors_n.asm file originally had fast code, then later was changed to just include x86_64/coreisbr/aors_n.asm which also happened to run optimally for Atom. That was fine when that was arranged, but then the latter file was rewritten, and the new code was not good for Atom. Regression! We need a broad mechanism for catching regressions, both sudden ones and gradual ones over time. (I implemented good Atom code now by staring with Marco's x86/atom/aors_n.asm and trivially edit it to make it 64-bit. I could have reverted to the old Atom-specific code, but Marco's code is neater and had a few cycles less overhead.) -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
