Re: [Chicken-hackers] Benchmark for "values" - interesting results

[Jörg F . Wittenberger]

On May 22 2013, Peter Bex wrote:

> On Mon, May 20, 2013 at 10:40:49PM +0200, Jörg F. Wittenberger wrote:
> ...
> > Maybe it's worth to consider to change the way arguments and return 
> > values are passed in Chicken. I know this would be the usual hell to 
> > implement.
>
> That sounds extremely painful indeed, and depending on how it's done might
> break a lot of code which makes use of the way values can be passed in C
> to native Scheme continuations (like the numbers egg does, for example).
>
> But still, it may be worth it.

I don't think the changes I have in mind would change too much about
the FFI.  That is at least not the documented FFI.  That one is simply
great and should stay.

Just C_return would become a variadic.

Sure code resorting to the internal API would have to be changed.

I'll come back ASAP with some demo code, but 1st I need to complete
what keeps me busy right now.  (I'd just forget too many details.)

> We already knew the SRFI implementations shipped with CHICKEN are
> extremely inefficient.  It's been a plan to rewrite some of them
> using faster internal versions for a while.  Also, the design of
> SRFI-1 and SRFI-13 is pretty stupid when considering efficiency,
> because many procedures gratuitously accept multiple arguments
> and when called differently the procedures may even do slightly
> different things, which makes it hard to optimize for.

I'm not familiar with Chickens optimizer.  Could Chicken pass
the ordinary first class value when used as variable reference
and still overload the name with a syntactic binding?  This
should make it rather easy to add some syntax atop of those SRFIs
to dispatch to fixed-args-one-case versions for efficiency.
(Remark: I would hate it if this would have to be build into
the compiler itself.  It should be possible to do this by means
of Scheme code loaded after the generic code.)

Wrt. the (abundant) use of multiple values in SRFI-1 I'd like
to add that I personally agree 100% with Olin Shivers comments
in the source.  I'd bad style to "stay on your head" to avoid
the use of multiple values here.  The result just so much faster.
Hence my conclusion: multiple values need to be faster.
Avoiding them is only an intermediate, immediate measure.

Wrt. SRFI-13 we might want to look at Gauche.
I only read about it so far.  But it seems use a smarter way to
treat strings.

> On the other hand, if we do decide to rewrite the handling of MV,
> this optimization may be a little premature because we don't know
> what will be faster, then.

I'd just keep the "real code" in a comment.

Best regards


/Jörg



.............