I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
Computation" by David S. Touretzky, and came across a section where he
describes difference between eq and equal. And, says "Due to its greater
efficiency, programmers often use EQ instead of EQUAL when symbols are
being compared." Now, why would eq be more efficient than equal when
comparing only one symbol?
--
"Now the storm has passed over me
I'm left to drift on a dead calm sea
And watch her forever through the cracks in the beams
Nailed across the doorways of the bedrooms of my dreams"
Nikola Skoric wrote:
> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
> Computation" by David S. Touretzky, and came across a section where he
> describes difference between eq and equal. And, says "Due to its greater
> efficiency, programmers often use EQ instead of EQUAL when symbols are
> being compared." Now, why would eq be more efficient than equal when
> comparing only one symbol?
eq is generally more effecient than equal. However, as it compares
actual memory addresses of the two objects, it has a much stricter
definition of equality to equal, so you should only use it when you
want to compare symbols, or check that two things are the *same* object.
Nikola Skoric wrote:
> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
> Computation" by David S. Touretzky, and came across a section where he
> describes difference between eq and equal. And, says "Due to its greater
> efficiency, programmers often use EQ instead of EQUAL when symbols are
> being compared." Now, why would eq be more efficient than equal when
> comparing only one symbol?
A better question would be: is there any reason why a compiler could
not recognize that
(equal 'x y)
can be translated in exactly the same way as:
(eq 'x y)
?
It's statically obvious that (QUOTE X) produces an operand of type
symbol, which means that the EQUAL has the same semantics as EQ!
So I would not expect a plain occurence of EQ such as this to be any
faster than EQUAL, unless the code is interpreted, or the compiler is
dumb.
"Kaz Kylheku" <········@gmail.com> writes:
> Nikola Skoric wrote:
>> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
>> Computation" by David S. Touretzky, and came across a section where he
>> describes difference between eq and equal. And, says "Due to its greater
>> efficiency, programmers often use EQ instead of EQUAL when symbols are
>> being compared." Now, why would eq be more efficient than equal when
>> comparing only one symbol?
>
> A better question would be: is there any reason why a compiler could
> not recognize that
>
> (equal 'x y)
>
> can be translated in exactly the same way as:
>
> (eq 'x y)
>
> ?
(define-compiler-macro equal (&whole form x y)
(if (or (and (consp x) (eq 'quote (car x)) (symbolp (cadr x)))
(and (consp y) (eq 'quote (car y)) (symbolp (cadr y))))
`(eq ,x ,y)
form))
Of course, the compiler could be smarter and with type and flow
analysis know that an expression can return only a symbol and do this
substitution even for things like:
(equal (get-a-symbol) (random-expression))
> It's statically obvious that (QUOTE X) produces an operand of type
> symbol, which means that the EQUAL has the same semantics as EQ!
>
> So I would not expect a plain occurence of EQ such as this to be any
> faster than EQUAL, unless the code is interpreted, or the compiler is
> dumb.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Nikola Skoric wrote:
> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
> Computation" by David S. Touretzky, and came across a section where he
> describes difference between eq and equal. And, says "Due to its greater
> efficiency, programmers often use EQ instead of EQUAL when symbols are
> being compared." Now, why would eq be more efficient than equal when
> comparing only one symbol?
EQ doesn't need to perform checks of which types the arguments are, but
can just blindly perform a comparison of the pointers itself. EQL has to
perform a test whether the arguments are numers, characters or other
objects, and EQUAL has to perform even more checks in the general case.
The loss of efficiency is due to the overhead spent on the type tests.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Mon, 31 Oct 2005 13:28:15 +0100, Pascal Costanza <··@p-cos.net> wrote:
> Nikola Skoric wrote:
>> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
>> Computation" by David S. Touretzky, and came across a section where he
>> describes difference between eq and equal. And, says "Due to its
>> greater efficiency, programmers often use EQ instead of EQUAL when
>> symbols are being compared." Now, why would eq be more efficient than
>> equal when comparing only one symbol?
>
> EQ doesn't need to perform checks of which types the arguments are, but
> can just blindly perform a comparison of the pointers itself. EQL has to
> perform a test whether the arguments are numers, characters or other
> objects, and EQUAL has to perform even more checks in the general case.
> The loss of efficiency is due to the overhead spent on the type tests.
>
>
> Pascal
>
It compares whether to a 'human' eye they look the same.
= isomorphic singularity
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Nikola Skoric <·········@net4u.hr> writes:
> Now, why would eq be more efficient than equal when comparing only
> one symbol?
Eq compares the identity of its arguments, which is typically a single
primitive CPU operation (and thus "efficient"). Equal on the other
hand does different things for different types of arguments. For
example, two lists are equal if all the elements are pairwise equal,
regardless of the identity of the lists. For symbol arguments equal
will return exactly the same result as eq, but equal must first check
what the types of the arguments are, and this type-checking is what
makes equal less efficient than eq. (That is, unless the compiler can
infer at compile-time that at least one of the arguments is a symbol,
in which case equal becomes the same as eq also in terms of
efficiency.)
--
Frode Vatvedt Fjeld
On 31 Oct 2005 13:30:35 +0100
Frode Vatvedt Fjeld (······@cs.uit.no) said...
> For symbol arguments equal
> will return exactly the same result as eq, but equal must first check
> what the types of the arguments are, and this type-checking is what
> makes equal less efficient than eq.
Thanks!
--
"Now the storm has passed over me
I'm left to drift on a dead calm sea
And watch her forever through the cracks in the beams
Nailed across the doorways of the bedrooms of my dreams"
Nikola Skoric wrote:
> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
> Computation" by David S. Touretzky, and came across a section where he
> describes difference between eq and equal. And, says "Due to its greater
> efficiency, programmers often use EQ instead of EQUAL when symbols are
> being compared." Now, why would eq be more efficient than equal when
> comparing only one symbol?
I assume you already know the difference (at least after having read the
other answers). So you might still say: "Why can't EQUAL just check
whether it's args are EQ and abort before doing any further checks?"
Sure it can. And probably all implementations do so. However it is still
legal for the compiler to assume that the parameters are not EQ so may
not a generate simple CMP instruction but insert a call to the EQUAL
function (which is probably too big to inline). So you have the calling
overhead. Assuming you have no stack frame allocation this might cost
only 2 extra cycles (call+ret)[*]. But still, if you assume that the
test for equality is performed first you'd have a conditional jump
forward which is assumed to be *not* taken on static prediction, so this
would be quite expensive.
So, that's the micro-performance perspective.
HTH
[*] A branch may even cost nothing on modern superscalar processors.
E.g. PPC can schedule 4 instructions and one branch per cycle. But cache
issues and many other stuff play a role so let's not be so pedantic.
From: Duane Rettig
Subject: Re: diff. betw. equal and eq on simbols
Date:
Message-ID: <4u0exve3l.fsf@franz.com>
Thomas Schilling <······@yahoo.de> writes:
> Nikola Skoric wrote:
>> I've been reading "COMMON LISP: A Gentle Introduction to Symbolic
>> Computation" by David S. Touretzky, and came across a section where he
>> describes difference between eq and equal. And, says "Due to its greater
>> efficiency, programmers often use EQ instead of EQUAL when symbols are
>> being compared." Now, why would eq be more efficient than equal when
>> comparing only one symbol?
>
> I assume you already know the difference (at least after having read the
> other answers). So you might still say: "Why can't EQUAL just check
> whether it's args are EQ and abort before doing any further checks?"
In fact, Allegro CL does just this - the compilation of a straight
call to equal starts with an eq test (a single instruction) and if the
test succeeds, the testing is done. So in most cases, an equal test
for two arguments that are eq is just as fast as eq itself. The
extra testing comes in when the arguments are not eq. This is done
via a call to excl::equal-not-eq, which tries to prune branches as
quickly as possible; if the objects are of particular types (e.g.
symbol) and weren't eq, then they are also not equal.
Finally, one more optimization is possible; if one or both of the
arguments is known to the compiler to be a symbol (or other such
types) then the compiler can convert the equal call to an eq
compilation, since the results would be the same.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Thomas Schilling wrote:
> So, that's the micro-performance perspective.
Yes, and after having dissected the performance issues of the various
EQ, EQL and EQUAL operators, I think we should say something about a
more important issue here: The use of these different operators also
signals the programmer's intention, and that is what source code should
mostly be concerned about.
If you use EQ you tell readers of your program that you don't expect to
compare anything but just objects. If you use EQL you tell readers that
you expect to also deal with numbers and characters. And so on. This
will help readers of your code to make assumptions about the intent of
the source code and ultimately to better understand it. If you always
use the same generic operators (like EQUAL) the less information you
reveal about your intentions.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
From: Russell McManus
Subject: Re: diff. betw. equal and eq on simbols
Date:
Message-ID: <87psplwy25.fsf@cl-user.org>
Pascal Costanza <··@p-cos.net> writes:
> If you use EQ you tell readers of your program that you don't expect
> to compare anything but just objects. If you use EQL you tell
> readers that you expect to also deal with numbers and
> characters. And so on. This will help readers of your code to make
> assumptions about the intent of the source code and ultimately to
> better understand it. If you always use the same generic operators
> (like EQUAL) the less information you reveal about your intentions.
I almost never use eq, and therefore I'm not giving the programmer any
guarantees about symbols vs. characters vs. numbers etc. Instead I
just use eql.
I think that this is a perfectly valid approach, and I would recommend
it to others. eq is a waste of programmer time as far as I am
concerned.
-russ
Russell McManus wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>
>>If you use EQ you tell readers of your program that you don't expect
>>to compare anything but just objects. If you use EQL you tell
>>readers that you expect to also deal with numbers and
>>characters. And so on. This will help readers of your code to make
>>assumptions about the intent of the source code and ultimately to
>>better understand it. If you always use the same generic operators
>>(like EQUAL) the less information you reveal about your intentions.
>
> I almost never use eq, and therefore I'm not giving the programmer any
> guarantees about symbols vs. characters vs. numbers etc. Instead I
> just use eql.
>
> I think that this is a perfectly valid approach, and I would recommend
> it to others. eq is a waste of programmer time as far as I am
> concerned.
I think that's ok. The difference between EQL, EQUAL and EQUALP is more
important.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
On Mon, 31 Oct 2005 15:52:41 +0100
Pascal Costanza (··@p-cos.net) said...
> Russell McManus wrote:
> > I almost never use eq, and therefore I'm not giving the programmer any
> > guarantees about symbols vs. characters vs. numbers etc. Instead I
> > just use eql.
> >
> > I think that this is a perfectly valid approach, and I would recommend
> > it to others. eq is a waste of programmer time as far as I am
> > concerned.
>
> I think that's ok. The difference between EQL, EQUAL and EQUALP is more
> important.
Hmmmmmmm... nice. I thought there some very important reason why someone
would be forced to use eq when eql is at hand, and that my newbie mind
just can't figure it out, but now I'm happy :-)
Now, as you mentioned the more important thing, I'd like to ask a thing
which isn't quite clear in my textbook. It says eq compares addresses.
That's nice. But it doesn't say wether other operators do this :-) I can
only assume that equal doesn't, because it checks equality of every
element in lists it's examining, and it wouldn't do that if it was sure
that car of both list was physicaly the same cons (as eq is). So, equal
obviously doesn't compare adresses... but does eql? My textbook says
"eql is like eq except it can safely compare numbers of the same type".
Now, this sentence was a bit obscure to me so, I did a few tests and
figured out that sentence was supposed to state: "eql compares addresses
except for numbers of the same type or symbols which evaluate to numbers
of the same type". Now, I'd like someone to confirm or deny this
assumption of mine, please...
--
"Now the storm has passed over me
I'm left to drift on a dead calm sea
And watch her forever through the cracks in the beams
Nailed across the doorways of the bedrooms of my dreams"
Russell McManus <···············@yahoo.com> writes:
> Pascal Costanza <··@p-cos.net> writes:
>
>> If you use EQ you tell readers of your program that you don't expect
>> to compare anything but just objects. If you use EQL you tell
>> readers that you expect to also deal with numbers and
>> characters. And so on. This will help readers of your code to make
>> assumptions about the intent of the source code and ultimately to
>> better understand it. If you always use the same generic operators
>> (like EQUAL) the less information you reveal about your intentions.
>
> I almost never use eq, and therefore I'm not giving the programmer any
> guarantees about symbols vs. characters vs. numbers etc. Instead I
> just use eql.
>
> I think that this is a perfectly valid approach, and I would
> recommend it to others. eq is a waste of programmer time as far as
> I am concerned.
I concur. For me, whenever I see EQ I have to stop and wonder about
whether the programmer who used EQ *knew* it was okay to use EQ
instead of EQL or just *thought* it was. (There's also a philosophical
point that the presence of EQ makes numbers and characters into
somewhat less than first class objects since they don't have true
identity under EQ (since they can be copied any time.))
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/