[Larceny-users] Performance Of SHA-256 Implementation

[William D Clinger]

Ray Racine wrote:

> The answer is correct, however, the 1 sec calculation time is a bit longer
> than anticipated along with the 4 million allocated words.  I understand why
> bitwise manipulations are going to be slower in dynamically typed language
> with type tag bits.  Thought I'd toss it out in the hopes someone may spot a
> low hanging fruit change in my implementation, recommend some compiler
> options etc.   At a minimum it might make a decent benchmark for grading
> (rnrs arithmetic bitwise) implementations.

Thanks.  Felix has already pointed you to the workarounds
appropriate for the current system.  Some of the allocation
may come from bignums generated as intermediate values.

There is hope for improvement in future releases.  Most of
the current inefficiency comes from implementing the R6RS
semantics without regard for performance.  The great primop
cleanup began with v0.97 "Funny in the Head", but only a
few bitwise operations were improved, and almost all of the
improvements applied mainly to bignums, not fixnums.  Most
of the changes in the next release are likely to consist of
minor bug fixes and performance improvements.  The bitwise
and bytevector operations are among the lowest-hanging fruit
for that release.

> P.S. Noticed the Larceny SVN and mail list has been a bit quiet. Anything
> new and notable coming down on the Larceny front? 64Bit? Native threads?

Our main priority right now is Felix's thesis defense and
completing transfer of his maintenance responsibilities to
me.  So far as new releases of Larceny go, integrating his
new garbage collector is the first priority.  A 64-bit
Larceny is essential, but we'll do a 64-bit Petit Larceny
first because Sassy doesn't support the 64-bit instructions
we need, and coming up with the 64-bit runtime will be easier
if we don't have to change the compiler and assembler at the
same time.  I think 64 bits is a higher priority than native
threads.