Steel Bank Common Lisp

On Wed, Jan 28, 2009 at 10:35 AM, Leslie P. Polzer
<sky@...:

>
> I have two CLOS objects that seem to be pretty identical
> -- same print output and same address.
>
> Yet EQ returns NIL when they are compared.
>
> How is this possible?


Is it a quiz?

> Is it a quiz?

No, I'm asking for internal criteria that could make
two CLOS objects that are apparently identical not EQ.

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

On Wed, 28 Jan 2009 10:42:24 +0100, Pierpaolo Bernardi wrote:

> Is it a quiz?<div class="gmail_quote">On Wed, Jan 28, 2009 at 10:35 AM,
> Leslie P. Polzer <span dir="ltr">&lt;<a

Would you mind sending e-mails to this list in plaintext?

Tamas

http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.htm

"Pointer equality" as it were.

On Wed, Jan 28, 2009 at 9:48 AM, Leslie P. Polzer
<sky@...:

>
> > Is it a quiz?
>
> No, I'm asking for internal criteria that could make
> two CLOS objects that are apparently identical not EQ.
>
> --
> LinkedIn Profile: http://www.linkedin.com/in/polzer
> Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
> Blog: http://blog.viridian-project.de/
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

2009/1/28 Leslie P. Polzer <sky@...>:
>
> I have two CLOS objects that seem to be pretty identical
> -- same print output and same address.
>
> Yet EQ returns NIL when they are compared.
>
> How is this possible?

It shouldn't be. Do you have a reproducible example?

You may also try using the following sanity-checking function:

  (defun sanity-check (obj1 obj2)
    (declare (optimize (speed 1) (safety 1) (debug 1)))
    (let ((addr1 (sb-kernel:get-lisp-obj-address obj1))
	  (addr2 (sb-kernel:get-lisp-obj-address obj2)))
      (format t "~&obj1 is at ~X~%obj2 is at ~X~%(eq obj1 obj2) => ~S~%"
	      addr1 addr2 (eq obj1 obj2))))

> 	  (addr2 (sb-kernel:get-lisp-obj-address obj2)))

That sheds a bit of light:

EQM(19): one

#<OBJ {AAFD571}>>
EQM(20): two

#<OBJ {AAFD571}>>

EQM(24): (sb-kernel:get-lisp-obj-address one)

199984081
EQM(25): (sb-kernel:get-lisp-obj-address two)

179295617

Both ONE's and TWO's hex display corresponds to the second value.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

> Does destructive modification of one visibly alter the other?

No.

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/

On Sun, Jan 18, 2009 at 7:23 AM, Daniel Herring <dherring@...> wrote:
> To paraphrase a question I found on LispForum,
> http://www.lispforum.com/viewtopic.php?f=2&t=242
>
> Why does
> (progv '(p q) '(nil t) (eval '(or p q)))
> issue warnings when
> (progv '(p q) '(nil t) (eval '(and p q)))
> does not?

Neither warns is SB-EXT:*EVALUATOR-MODE* is :INTERPRET. When it is
:COMPILE, "nontrivial" evaluations are implemented essentailly via

 (funcall (compile nil `(lambda () ,form)))

. The OR macroexpands into something like

 (LET ((#:G907 P))
   (IF #:G907 #:G907 Q))

whereas the AND expands into

 (IF P Q NIL)

Even the simple evaluator is able to deal with the latter without
first compiling it, but LET forces it to use the compile-then-funcall
strategy. Since the variables have not been declaimed SPECIAL, the
compiler warns about unbound variables.

Cheers,

 -- Nikodemus

On Sun, 18 Jan 2009, Nikodemus Siivola wrote:
> On Sun, Jan 18, 2009 at 7:23 AM, Daniel Herring <dherring@...> wrote:
>> To paraphrase a question I found on LispForum,
>> http://www.lispforum.com/viewtopic.php?f=2&t=242
>>
>> Why does
>> (progv '(p q) '(nil t) (eval '(or p q)))
>> issue warnings when
>> (progv '(p q) '(nil t) (eval '(and p q)))
>> does not?
>
> Neither warns is SB-EXT:*EVALUATOR-MODE* is :INTERPRET. When it is
> :COMPILE, "nontrivial" evaluations are implemented essentailly via
>
> (funcall (compile nil `(lambda () ,form)))
>
> . The OR macroexpands into something like
>
> (LET ((#:G907 P))
>   (IF #:G907 #:G907 Q))
>
> whereas the AND expands into
>
> (IF P Q NIL)
>
> Even the simple evaluator is able to deal with the latter without
> first compiling it, but LET forces it to use the compile-then-funcall
> strategy. Since the variables have not been declaimed SPECIAL, the
> compiler warns about unbound variables.

Ok.  I had seen the OR macroexpansion, but didn't realize LET was 
triggering a compilation.  Given your explanation and a night's sleep, the 
warnings now make perfect sense.

Thanks,
Daniel

On Thu, Jan 15, 2009 at 10:57 PM, Stephen Westfold <westfold@...> wrote:
> Last March Rudi Schlatte helped me fix a bug in win32-sockets.lisp.
> The problem was that after loading sb-bsd-sockets and then saving an
> executable or core, WSAStartup was not being called on startup. I
> fixed it by replacing
>
> (defvar *wsa-startup-call*
>  (wsa-startup (make-wsa-version 2 2)))
>
> by
>
> (defun wsa-init ()
>  (wsa-startup (make-wsa-version 2 2)))
>
> (push 'swa-init sb-ext:*init-hooks*)
>
> (defvar *wsa-startup-call*
>  (wsa-init))
>
>
> I did report this fix at the time, but the currently distributed sbcl
> still contains the bug, so I need to reapply the fix each time I
> install the new version. This is becoming more of a problem as more of
> my colleagues are using the windows version of our software.
>
> Could someone with more knowledge than me verify and install this
> patch or one they consider better?

Thanks for the reminder! Should be taken care of in 1.0.24.46.

Cheers,

 -- Nikodemus

On Sun, Jan 11, 2009 at 4:51 PM, Nikodemus Siivola
<nikodemus@...> wrote:
> On Wed, Dec 31, 2008 at 10:22 PM, Simon Handley <shandley_42@...> wrote:
>> I'm trying to track down a possible memory leak associated with SAPs, and
>> I'm hoping that someone else has already seen this and I've just stupidly
>> missed an obvious solution in the list archives.

Oh, by the by: plain text messages are *strongly* preferred.

> Cheers,
>
>  -- Nikodemus

On Fri, Jan 9, 2009 at 7:19 PM, karol skocik <karol.skocik@...> wrote:

> I would like to optimize our application written with several SBCL
> specific things already baked in, so I am looking for SBCL specific
> options for speeding up mainly CLOS slot access. Juho mentioned on
> #lisp a possibility to add sealing declarations. How do I tell SBCL
> that I want to seal a class that won't be redefined or subclasses
> later in run-time?

The declamation you are looking for is

  (declaim (sb-ext:freeze-type foo))

except that it doesn't really help: it doesn't prevent class
redefinitions, and it doesn't help optimize slot-access.

Are you familiar with the performance discussion in

  http://www.sbcl.org/manual/Slot-access.html#Slot-access

?

If you need slot accesses with speeds beyond the "slot-value with
constant second argument in defmethod body" described there, you can
use a custom metaclass to provide a :LOCATION argument for slots,
orders the slots based on that in COMPUTE-SLOTS, and use
STANDARD-INSTANCE-ACCESS to access them -- but beating the best-case
slot-value speed is pretty hard, since it has extra support in the
method dispatch machinery.

I had maybe ~80% if slot location sealing written up, which does this
semi-automatically, but the performance win was minimal.

Other tricks to speed up your slot access performance:

1. If you need fast slot-accesses in a DEFUN for some reason (?),
define a multi-value accessor method:

 (defmethod values-for-foo ((x bar) (y zot) (z quux))
   (values (slot-value x 'a)
           (slot-value y 'b)
           (slot-value z 'c)))

This allows you to get the fast slot accesses for the slots you need
and pay for the dispatch only one. Most of the time you are better of
using a DEFMETHOD instead of the DEFUN instead, though -- but if
you're not receiving the instances whose slots you are interested in
as arguments, this may be worthwhile.

2. Encapsulate a specialized structure: instead of storing your data
directly in the standard object, define a structure with multiple
typed slots to hold it, and store it in the standard object. Then you
need to pay for the CLOS access only once, and can get the fast
structure object instance access (along with compiler-knowledge of
slot types) after that.

3. Use defstructs. Redefinitions suck, and you don't get multiple
inheritance -- but the slot accesses are fast, compiler knows about
slot types, and you can stack allocate them, so sometimes it is well
worth it.

Cheers,

 -- Nikodemus

Hi,
  thanks for clarification,

>  (declaim (sb-ext:freeze-type foo))
>

I will follow advice 3. along with others and rewrite our most
performance sensitive classes as structs, so I guess this declamation
can't hurt then.


>  http://www.sbcl.org/manual/Slot-access.html#Slot-access
>

I missed that in manual, thanks for the link.

> Other tricks to speed up your slot access performance:
>
> 1. If you need fast slot-accesses in a DEFUN for some reason (?),
> define a multi-value accessor method:
>
>  (defmethod values-for-foo ((x bar) (y zot) (z quux))
>   (values (slot-value x 'a)
>           (slot-value y 'b)
>           (slot-value z 'c)))
>
> This allows you to get the fast slot accesses for the slots you need
> and pay for the dispatch only one. Most of the time you are better of
> using a DEFMETHOD instead of the DEFUN instead, though -- but if
> you're not receiving the instances whose slots you are interested in
> as arguments, this may be worthwhile.
>
> 2. Encapsulate a specialized structure: instead of storing your data
> directly in the standard object, define a structure with multiple
> typed slots to hold it, and store it in the standard object. Then you
> need to pay for the CLOS access only once, and can get the fast
> structure object instance access (along with compiler-knowledge of
> slot types) after that.
>
> 3. Use defstructs. Redefinitions suck, and you don't get multiple
> inheritance -- but the slot accesses are fast, compiler knows about
> slot types, and you can stack allocate them, so sometimes it is well
> worth it.
>

These are all very good advices and I will follow them! Thanks!

Karol

On Sat, Jan 10, 2009 at 9:28 PM, karol skocik <karol.skocik@...> wrote:
> Hi,
>  thanks for clarification,
>
>>  (declaim (sb-ext:freeze-type foo))
>>
>
> I will follow advice 3. along with others and rewrite our most
> performance sensitive classes as structs, so I guess this declamation
> can't hurt then.

It won't really help either -- it will only change the way TYPEP test
for frozen types are compiled slightly, without any real performance
advantage. Add to that the fact that if/when proper inheritance
sealing is implemented, the FREEZE-TYPE declamation is likely to be
deprecated, I would recommend against using it.

Cheers,

 -- Nikodemus

On Fri, Jan 9, 2009 at 11:31 AM, Leslie P. Polzer
<sky@...> wrote:

> it should be enough to lock a hash table shared between
> multiple threads when a write is in progress.

In practice this is currently true, yes, but this is not in any way
guaranteed: implementation details may change, and that can mean that
concurrent reads are future-proof safe.

> Using a mutex however would make readers block each
> other, too.
>
> How can I block only when a write is in progress?

You need to roll a read-write lock. (Yes, it would be nice for SBCL to
provide one.)

Cheers,

 -- Nikodemus