Re: eql faster than = (integer comparison on sbcl)?

On 28 Feb., 17:43, "Tim Bradshaw" <tfb+goo...@xxxxxxxx> wrote:
On Feb 28, 4:20 pm, krewin...@xxxxxxx wrote:

It works fine with sbcl 1.0.1 (on linux i686), but it gets faster if
the :test #'= is replaced by #'eql. Why is that? Shouldn't the #'=
version be faster (since it's a more specific test)?

Any pointer would be appreciated.

If the compiler can make the right assumptions they should be compiled
into the same code. But it's not at all clear to me that it can - it
would have to know an awful lot about MEMBER to be able to do this.
It may well be that by the time the comparison predicate is called by
MEMBER, it knows nothing about the types, and = may then have to do
more work (check things actually are numbers, be prepared to signal an
error) than EQL.

But more to the point, the performance of your code will probably be
dominated by list traversal if N is not a fairly small number. You
need a better way of checking for duplicates. If you *really* care
about performance, I'd suggest:

if N is small allocate an N-element array of some good type (bit array
might be worth trying, else array of some immediate type). Use this
to know when you have dups. (try and allocate it on the stack...)

If N is large use a hashtable.

--tim

Thanks a lot Tim and André, that really helped me. Now, after you
explained it, the answer seems so obvious. N is rather small, so I
guess I'll use an array.

Thanks again,
Albert


.

Relevant Pages

  • Re: Legacy alloc on 64 Bit system
    ... machine using the Protland compiler suite. ... The allocate routine takes a ... array to the allocated space. ... I don't speak for Intel, ...
    (comp.lang.fortran)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: allocating arrays, trouble
    ... Is this a compiler issue or just prohibited in Fortran 90? ... The array b in the following fragment is a so-called ... The program must allocate the memory for this array at ...
    (comp.lang.fortran)
  • Re: Overloading OPERATOR(+): my usage causing memory leaks.
    ... Imemory leaks when apply it to array arguments. ... I'd guess it to be a compiler bug, and I can even roughly guess where. ... assignment, but it seems a good candidate for something some compilers ... where a and b are derived types with allocatable components, the compiler should allocate ...
    (comp.lang.fortran)
  • Re: INTENT(WORKSPACE) as a new Fortran feature?
    ... >> the array once in the caller than each time within the subroutine. ... > the stack pointer is being changed to allocate local variables in any ... "actual" memory would never be touched at all. ... If, on a particular machine, the compiler knows that it would be ...
    (comp.lang.fortran)