thresholds

[Torbjorn Granlund]

David Newman <david.newman at jesus.ox.ac.uk> writes:

  The tests seem to show that having a more recent version of gcc and/or more
  aggressive CFLAGS doesn't necessarily mean you get better
  thresholds. However, some results differ considerably from the athlon
  defaults, GCDEXT_THRESHOLD being the most obvious.

I wouldn't call a certain threshold "better" than any other
threshold.  A lower threshold value might simply mean that the
code used for operands below that threshold happened to become
awfully slow by that compile.

It would be more interesting to use tune/speed from different
compiles.  The function arguments that tune/speed accepts aren't
too well documented, but you should be able to make a guess from
the list output buy the program itself when invoiked without any
arguments.

  The difference is not really too surprising though, as the file
  k7/gmp-mparam.h has to cover (I think) at least four different types of
  chip, from the early 800Mhz models to the most recent Bartons with 512k of
  L2 cache.

Alas, I think the various Athlons should be fairly similar as far
as GMP thresholds are concerned.  

  I don't imagine the different thresholds affect the speed of GMP greatly but
  it would seem sensible to have them chosen optimally. How much work would it
  take to change the compile process to do a "make tune" at compile time, if
  this is feasible?

I think we will leave it to our zealous users, since that will require
compile+tune and then a recompile.  :-)

-- 
Torbjörn