[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH][5] numbers integration

From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH][5] numbers integration
Date: Sun, 15 Feb 2015 13:26:25 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Feb 13, 2015 at 11:30:42AM +0100, Felix Winkelmann wrote:
> We must avoid the CPS-call, at all costs.

In many cases this is already avoided: a simple loop that uses the
loop variable to index a string or a vector will effectively be
rewritten to an inline fixnum version of + or -, due to the fact
that string-index is declared to be enforcing.  That means it knows
these variables can only ever be fixnums, for which there are
inlined specializations.

This only leaves the problem of loops that don't really use the
loop counter except to track progress so other way.  I looked at
the "destructive" program from chicken-benchmark, which does something
like that.  It is 3 to 4 times slower than master with numbers.
I looked at the generated code and found out it was unable to determine
that the loop variables are always integers.

Simply replacing the calls to "-" with "##sys#integer-minus" (which the
scrutinizer would've done if it would have been able to correctly deduce
the types) makes the benchmark perform twice as fast, already.  That makes
it only twice as slow as the original program, instead of 4 times as slow.

I don't quite understand why the scrutinizer is unable to detect such a
simple case.  I managed to boil it down to the following silly program:

(let lp ((j 4))
  (if (zero? j)
      (print j)
      (lp (- j 1))))

Rewriting manually doesn't help:

(letrec ((lp (lambda (j)
               (if (zero? j)
                   (print j)
                   (lp (- j 1))))))
  (lp 4))


(do ((j 4 (- j 1)))
    ((zero? j) (print j)))

are both the same program, but none of these seem to make the compiler
understand that j can only be an integer.

The scrutinizer doesn't seem to see that j is an integer, even though
"lp" is not escaping, and is only invoked in one place, with an integer.
I would have expected it to at least figure out it is a "number", but
that doesn't seem to be the case.  Of course, it would be even better if
it could be made to understand it can only be a fixnum, but that would
require tricky range analysis, whereas this immediate problem requires
only simple types as they are available right now.


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]