gcrypt, MPI, GMP and powerpc64

[Torbjorn Granlund]

Werner Koch <wk at gnupg.org> writes:

  > don't follow them.  But if you're judging local changes in any GNU/Linux
  > or BSD system is an indicator on whether a package is maintained or not,
  > then I suppose all and every package is unmaintained.
  
  I don't understand why you insist after 10 years that at that time the
  package was maintained.
  
Because it was.  Look at the ChangeLog file in any GMP release, and
you'll see that GMP has been developed at a good pace during all the
years.  Not sure how you define "maintained", but it was provably
developed, and the mailing lists were being responed to.

  > The NIH factor is usually the most important one in situation such as
  > this.  Even if people very rarely would confess that to be a factor.
  
  A requested design goal for GnuPG was to avoid storing any sensible data
  in pageable memory.  Thus most of the alloca's had to be replaced by
  custiomized malloc functions.  For a general number crunching
  application this is not needed and to be avoided due to some overhead.
  
Custom allocation has been possible since GMP 1.  The TMP_ALLOC stuff
that defaults to using alloca, can trivially (at configure time) be
made to use the customized allocation.

  > Alright!  But what about your claims about x86 32-bit code?  Show us
  > your hidden tricks!  Let me again quote your statement from last year:
  > "We also need better optimized code for modern ia32 CPUS [than in GMP]
  
  I am not anymore a machine code expert.  However SSE etc are clearly
  things you want for crypto operations.
  
Ah, did you guess that GMP does not use SSE, and then based on that
guess spread the rumor that the GMP x86 code isn't very good?

GMP uses SSE, of course.

We've all seen FUD about GNU projects on the Net many times, but I am
astonished that a lead developer of one GNU project spreads FUD about
another GNU project.

-- 
Torbjörn