benchmarks for the release

[Matthew Fluet]

> Also, as to the wc-input1, which is, indeed, very fine, I must point out that
> TextIO.inputLine is still too slow.  I think in my tests it was about 1/2
> the speed of C (with C using the correct #define so that stdio wasn't broken
> with stupid thread stuff).  My guess was that the problem was the extra copy
> (and allocation) used to save the characters forming the line.  If that is
> the cause,  it could be fixed by having some code which read the TextIO
> buffer but kept the buffers from being re-used.

A thought i had when browsing through the runtime sources is that a lot of
those wrapper functions cost us two c-calls with no intervening
processing.  (I guess if gcc turns them into tail calls, then its like 1.5
calls.)  Also, I tried implementing the C.c functions as native assembly
(they are just addressing into a char array), because we pay a C-call when
copying each byte out of an input string which originally comes in as a
CString and is then copied to an ML string.  But, it didn't seem to have
any effect.