[racket-dev] Optional equality predicate for assoc and member

7 minutes ago, Matthew Flatt wrote:
> 
> Switching to a Racket implementation costs time, but (with the JIT)
> it's not a huge difference --- similar to the cost of switching the C
> code from 32-bit to 64-bit mode on my machine. The JIT even manages to
> make `assq' slightly faster than C in 64-bit mode.

Is there some obvious reason for the huge difference in improvement
between the 32 and the 64 bits (Almost twice slower and roughly the
same resp.)?


> The cost for a non-JIT platform is why I hadn't changed `assq',
> `assv', and `assoc' before. But a plain-Racket implementation is
> surely better in the long run, and we can keep the C code and bind
> functions conditionally when the JIT is disabled. Maybe we can
> eventually close the gap between the JIT-generated code and C. Also,
> I think the JIT could be smarter about `equal?', which could tilt
> the balance in favor of the JIT for `assoc'.

(Maybe it'll be feasible to dump jit-generated machine code at some
point...?)


> I'm happy that the compiler is doing its job, but inlining
> optimizations are fragile, so I'm a little reluctant to rely on
> them.  Sad but true: the macro approach feels more comfortable for
> now.

If by "macro approach" you refer to what I was talking about, then
isn't that needed to have versions with inlined comparators?  (IIUC,
the equivalent optimization would be a form of RTCG, rather than a
plain optimization.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!