Development of Steel Bank Common Lisp

Gábor Melis | 1 Apr 2011 11:08

Re: with-timeout sucks

Robert Goldman <rpgoldman <at> sift.info> writes:

> So what am I to do if I have a computational process that I may want to
> choke off after a fixed amount of time?
>
> Seems like the WITH-TIMEOUT provides me no guarantee that unwinds will
> proceed properly, but WITH-DEADLINE is not appropriate, because it's
> only suitable for I/O timeouts.
>
> Sorry if these are obvious questions --- I've been programming mostly in
> Allegro, with green threads, so I haven't had to worry about these
> issues previously.

Actually, async unwind - by its very nature - is a problem on Allegro CL
as well (and, I'd hazard, on most implementations).

I tend to use WITH-TIMEOUT only around side effect free computation or
at least code whose side effects will be garbage after unwinding. I
trust the lisp to be async unwind safe (method calls, IO, etc), but I
certainly don't push it.

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

headers

Robert Goldman | 1 Apr 2011 15:08

Re: with-timeout sucks

On 4/1/11 Apr 1 -4:08 AM, Gábor Melis wrote:
> Robert Goldman <rpgoldman <at> sift.info> writes:
> 
>> So what am I to do if I have a computational process that I may want to
>> choke off after a fixed amount of time?
>>
>> Seems like the WITH-TIMEOUT provides me no guarantee that unwinds will
>> proceed properly, but WITH-DEADLINE is not appropriate, because it's
>> only suitable for I/O timeouts.
>>
>> Sorry if these are obvious questions --- I've been programming mostly in
>> Allegro, with green threads, so I haven't had to worry about these
>> issues previously.
> 
> Actually, async unwind - by its very nature - is a problem on Allegro CL
> as well (and, I'd hazard, on most implementations).

I can't say for sure, but I believe that Allegro has more gross
threading (time units are pretty chunky) and seems to have some stuff in
its low-level implementation that makes multi-threading safer.  I have
had cleaner results with multi-threaded I/O, for example.  Dunno if that
means that it just refuses to interrupt stuff it can't unwind, or has
handlers that unwind more carefully.  E.g., I have had happier results
with a WITH-TIMEOUT around READ-LINE on Allegro.  I can't say why...
[actually, I looked at READ-LINE in SBCL, and it seems interrupt unsafe
because it has a LET-allocated buffer.  would there be any interest in a
patch that made this buffer save its state if interrupted, so READ-LINE
doesn't lose data in such cases?]

>

(Continue reading)

headers

Gábor Melis | 1 Apr 2011 16:06

Re: with-timeout sucks

Robert Goldman <rpgoldman <at> sift.info> writes:

> I can't say for sure, but I believe that Allegro has more gross
> threading (time units are pretty chunky) and seems to have some stuff in
> its low-level implementation that makes multi-threading safer.

This is getting a bit offtopic, but green threads and the big process
quantum are the reason that thread unsafety bugs are less likely to
happen. Not so for SMP that SBCL has and Allegro has in the works.

> I have
> had cleaner results with multi-threaded I/O, for example.  Dunno if that
> means that it just refuses to interrupt stuff it can't unwind, or has
> handlers that unwind more carefully.  E.g., I have had happier results
> with a WITH-TIMEOUT around READ-LINE on Allegro.  I can't say why...

Interrupt handling in Allegro is safepoint based [1] so where interrupts
can be handled is more controllable. In all likelihood, SBCL will
eventually move to safepoints as well (when the windows stuff is
merged?).

> [actually, I looked at READ-LINE in SBCL, and it seems interrupt unsafe
> because it has a LET-allocated buffer.  would there be any interest in a
> patch that made this buffer save its state if interrupted, so READ-LINE
> doesn't lose data in such cases?]

I don't think you can implement that in a race free way under the
current interrupt handling regime.

> I was thinking that I was ok because I have pretty much side-effect free

(Continue reading)

headers

Juho Snellman | 2 Apr 2011 04:02

Re: Download page

On Wed, Mar 30, 2011 at 5:09 PM, Jim Wise <jwise <at> draga.com> wrote:

b.) On a lot of platforms, native or third-party packaging systems are a
great way to install sbcl. Should we have a brief list noting, eg,
that SBCL is available for NetBSD in pkgsrc, or MacOS in homebrew
(I've been very impressed with the homebrew sbcl integration, by the
way)?

The traditional SBCL stance has been the opposite: we have no idea of what distributors do to the packages or even know they aren't doing the right thing (from the SBCL perspective). Distro-specific customizations can make it hard to interpret bug reports or help users. So the basic recommendation has been for users to either use an "official" binary or build from source.

--
Juho Snellman

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

headers

Jim Wise | 2 Apr 2011 04:09

Re: Download page

On Apr 1, 2011, at 22:02, Juho Snellman <jsnell <at> iki.fi> wrote:

The traditional SBCL stance has been the opposite: we have no idea of what distributors do to the packages or even know they aren't doing the right thing (from the SBCL perspective). Distro-specific customizations can make it hard to interpret bug reports or help users. So the basic recommendation has been for users to either use an "official" binary or build from source.

That makes sense, thanks.

Any thoughts on offering "official experimental" binary distributions for features we want to test?

I'd be happy to upload sb-thread versions of the solaris and darwin ports for users to experiment with, but these are clearly not stable enough to be the default (and are not the default yet when building from source).

Thanks,

Sent from my iPhone.

Digital signature available upon request.

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

headers

Christophe Rhodes | 2 Apr 2011 16:45

Re: Proposal: A git-hosted workflow for SBCL

James Y Knight <foom <at> fuhm.net> writes:

> On Mar 28, 2011, at 12:47 PM, Cyrus Harmon wrote:

>> I'd like to propose that we resurrect the push to move to git. Any
>> objections?
>
> Yes, please. I'd note that commit messages still aren't working, and
> only Nikodemus has been manually mailing his out.

Not that I object to a well-documented move, but just for reference, I
believe I've fixed cvs commit use to syncmail.  We'll find out when the
next attempt to commit either sends mail, does not send mail, or fails
completely because I've botched the repository.

Cheers,

Christophe

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

headers

Elliott Slaughter | 3 Apr 2011 18:45

Optimization of array accesses

Hi there,

I'm wondering why in the following code SBCL complains about being unable to optimize the arithmetic despite my type declarations? I am on 1.0.46 on Mac OS X (64-bit, threaded).

The code:

(declaim (optimize (speed 3) (safety 0)))

(defun dot-sa (a b)

(declare (type (simple-array fixnum (4)) a b))

(+ (* (aref a 0) (aref b 0))

(* (aref a 1) (aref b 1))

(* (aref a 2) (aref b 2))

(* (aref a 3) (aref b 3))))

(defun test-dot-sa ()

(let ((a (vector 1 2 3 4))

(b (vector 4 3 2 1)))

(time (loop for i from 1 to 100000000 do (dot-sa a b)))))

And an example warning:

; in: DEFUN DOT-SA

; (* (AREF A 0) (AREF B 0))

;

; note: forced to do GENERIC-* (cost 30)

; unable to do inline fixnum arithmetic (cost 4) because:

; The result is a (VALUES

; (INTEGER -1329227995784915871750885555673497600

; 1329227995784915872903807060280344576)

; &OPTIONAL), not a (VALUES FIXNUM &REST T).

; unable to do inline (signed-byte 64) arithmetic (cost 5) because:

; The result is a (VALUES

; (INTEGER -1329227995784915871750885555673497600

; 1329227995784915872903807060280344576)

; &OPTIONAL), not a (VALUES (SIGNED-BYTE 64) &REST T).

; etc.

Thanks.

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

headers

Christophe Rhodes | 3 Apr 2011 19:10

Re: Optimization of array accesses

Elliott Slaughter <elliottslaughter <at> gmail.com> writes:

> I'm wondering why in the following code SBCL complains about being unable to
> optimize the arithmetic despite my type declarations? I am on 1.0.46 on Mac
> OS X (64-bit, threaded).
>
> The code:
>
> (declaim (optimize (speed 3) (safety 0)))
>
> (defun dot-sa (a b)
>   (declare (type (simple-array fixnum (4)) a b))
>   (+ (* (aref a 0) (aref b 0))
>      (* (aref a 1) (aref b 1))
>      (* (aref a 2) (aref b 2))
>      (* (aref a 3) (aref b 3))))

The compiler note that you gave, about generic-* rather than inline
fixnum arithmetic, is emitted because in doing an efficient
multiplication not only must the arguments in (* x y) be fixnums, so
also must the result -- and there's no way the compiler can guarantee
that from your type declaration.  (It could if either the arguments were
known to be smaller than the square root of MOST-POSITIVE-FIXNUM, or if
you make the promise that it will using (THE FIXNUM (* X Y)))

> (defun test-dot-sa ()
>   (let ((a (vector 1 2 3 4))
>         (b (vector 4 3 2 1)))
>     (time (loop for i from 1 to 100000000 do (dot-sa a b)))))

Note that (vector 1 2 3 4) does not return an object of type
(simple-array fixnum (4)) -- just because all the elements are a vector
are of type fixnum at a given time does not make the vector specialized
only to hold fixnums.

Cheers,

Christophe

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

headers

Elliott Slaughter | 4 Apr 2011 04:11

Re: Optimization of array accesses

On Sun, Apr 3, 2011 at 10:10 AM, Christophe Rhodes <csr21 <at> cantab.net> wrote:

Elliott Slaughter <elliottslaughter <at> gmail.com> writes:

> I'm wondering why in the following code SBCL complains about being unable to
> optimize the arithmetic despite my type declarations? I am on 1.0.46 on Mac
> OS X (64-bit, threaded).
>
> The code:
>
> (declaim (optimize (speed 3) (safety 0)))
>
> (defun dot-sa (a b)
> (declare (type (simple-array fixnum (4)) a b))
> (+ (* (aref a 0) (aref b 0))
> (* (aref a 1) (aref b 1))
> (* (aref a 2) (aref b 2))
> (* (aref a 3) (aref b 3))))

The compiler note that you gave, about generic-* rather than inline
fixnum arithmetic, is emitted because in doing an efficient
multiplication not only must the arguments in (* x y) be fixnums, so
also must the result -- and there's no way the compiler can guarantee
that from your type declaration. (It could if either the arguments were
known to be smaller than the square root of MOST-POSITIVE-FIXNUM, or if
you make the promise that it will using (THE FIXNUM (* X Y)))

That makes sense. (It also makes the code uglier, but I suppose that is to be expected.)

> (defun test-dot-sa ()
> (let ((a (vector 1 2 3 4))
> (b (vector 4 3 2 1)))
> (time (loop for i from 1 to 100000000 do (dot-sa a b)))))

Note that (vector 1 2 3 4) does not return an object of type
(simple-array fixnum (4)) -- just because all the elements are a vector
are of type fixnum at a given time does not make the vector specialized
only to hold fixnums.

Doh! That should have been (make-array '(4) :element-type 'fixnum :initial-contents '(1 2 3 4)) .

Cheers,

Christophe

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

headers

Elliott Slaughter | 4 Apr 2011 04:52

Re: Optimization of array accesses

Here's a follow up question:

I noticed that simple-vector and an unspecialized simple-array have wildly different performance. As far as I can tell though, both are unspecialized with respect to fixnums. I could expect that an unspecialized simple-array would get worse performance, but I'm not sure why simple-vector is doing so well when the type won't even let me specify the element-type.

Thanks.

The code, in case you are interested:

(defun dot-sv (a b)

(declare (type (simple-vector 4) a b))

(the fixnum (+ (the fixnum (* (the fixnum (svref a 0)) (the fixnum (svref b 0))))

(the fixnum (* (the fixnum (svref a 1)) (the fixnum (svref b 1))))

(the fixnum (* (the fixnum (svref a 2)) (the fixnum (svref b 2))))

(the fixnum (* (the fixnum (svref a 3)) (the fixnum (svref b 3)))))))

(defun dot-sa (a b)

(declare (type simple-array a b))

(the fixnum (+ (the fixnum (* (the fixnum (aref a 0)) (the fixnum (aref b 0))))

(the fixnum (* (the fixnum (aref a 1)) (the fixnum (aref b 1))))

(the fixnum (* (the fixnum (aref a 2)) (the fixnum (aref b 2))))

(the fixnum (* (the fixnum (aref a 3)) (the fixnum (aref b 3)))))))

(defun test-dot-sv-f ()

(let ((a (vector 1 2 3 4))

(b (vector 4 3 2 1)))

(time (loop for i from 1 to 100000000 do (dot-sv-f a b)))))

(defun test-dot-sa-g ()

(let ((a (make-array '(4) :initial-contents '(1 2 3 4)))

(b (make-array '(4) :initial-contents '(4 3 2 1))))

(time (loop for i from 1 to 100000000 do (dot-sa-g a b)))))

On Sun, Apr 3, 2011 at 7:11 PM, Elliott Slaughter <elliottslaughter <at> gmail.com> wrote:

On Sun, Apr 3, 2011 at 10:10 AM, Christophe Rhodes <csr21 <at> cantab.net> wrote:

Elliott Slaughter <elliottslaughter <at> gmail.com> writes:

> I'm wondering why in the following code SBCL complains about being unable to
> optimize the arithmetic despite my type declarations? I am on 1.0.46 on Mac
> OS X (64-bit, threaded).
>
> The code:
>
> (declaim (optimize (speed 3) (safety 0)))
>
> (defun dot-sa (a b)
> (declare (type (simple-array fixnum (4)) a b))
> (+ (* (aref a 0) (aref b 0))
> (* (aref a 1) (aref b 1))
> (* (aref a 2) (aref b 2))
> (* (aref a 3) (aref b 3))))

The compiler note that you gave, about generic-* rather than inline
fixnum arithmetic, is emitted because in doing an efficient
multiplication not only must the arguments in (* x y) be fixnums, so
also must the result -- and there's no way the compiler can guarantee
that from your type declaration. (It could if either the arguments were
known to be smaller than the square root of MOST-POSITIVE-FIXNUM, or if
you make the promise that it will using (THE FIXNUM (* X Y)))

That makes sense. (It also makes the code uglier, but I suppose that is to be expected.)

> (defun test-dot-sa ()
> (let ((a (vector 1 2 3 4))
> (b (vector 4 3 2 1)))
> (time (loop for i from 1 to 100000000 do (dot-sa a b)))))

Note that (vector 1 2 3 4) does not return an object of type
(simple-array fixnum (4)) -- just because all the elements are a vector
are of type fixnum at a given time does not make the vector specialized
only to hold fixnums.

Doh! That should have been (make-array '(4) :element-type 'fixnum :initial-contents '(1 2 3 4)) .

Cheers,

Christophe

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

81	May 2013
142	April 2013
49	March 2013
53	February 2013
36	January 2013
21	December 2012
45	November 2012
48	October 2012
52	September 2012
24	August 2012
14	July 2012
21	June 2012
69	May 2012
87	April 2012
41	March 2012
8	February 2012
20	January 2012
59	December 2011
129	November 2011
56	October 2011
35	September 2011
134	August 2011
33	July 2011
102	June 2011
112	May 2011
38	April 2011
90	March 2011
113	February 2011
71	January 2011
49	December 2010
52	November 2010
122	October 2010
110	September 2010
110	August 2010
38	July 2010
111	June 2010
87	May 2010
133	April 2010
131	March 2010
91	February 2010
91	January 2010
139	December 2009
78	November 2009
179	October 2009
108	September 2009
134	August 2009
106	July 2009
217	June 2009
168	May 2009
185	April 2009
171	March 2009
118	February 2009
155	January 2009
291	December 2008
167	November 2008
270	October 2008
86	September 2008
103	August 2008
127	July 2008
147	June 2008
204	May 2008
132	April 2008
189	March 2008
202	February 2008
190	January 2008
201	December 2007
199	November 2007
99	October 2007
136	September 2007
150	August 2007
191	July 2007
129	June 2007
132	May 2007
244	April 2007
177	March 2007
85	February 2007
151	January 2007
157	December 2006
208	November 2006
116	October 2006
100	September 2006
178	August 2006
73	July 2006
184	June 2006
188	May 2006
174	April 2006
149	March 2006
181	February 2006
214	January 2006
155	December 2005
140	November 2005
124	October 2005
120	September 2005
302	August 2005
185	July 2005
198	June 2005
200	May 2005
178	April 2005
210	March 2005
101	February 2005
148	January 2005
134	December 2004
97	November 2004
111	October 2004
164	September 2004
147	August 2004
94	July 2004
116	June 2004
202	May 2004
243	April 2004
163	March 2004
97	February 2004
89	January 2004
86	December 2003
183	November 2003
118	October 2003
215	September 2003
184	August 2003
68	July 2003
142	June 2003
211	May 2003
146	April 2003
103	March 2003
128	February 2003
100	January 2003
88	December 2002
92	November 2002
89	October 2002
97	September 2002
65	August 2002
41	July 2002
62	June 2002
90	May 2002
116	April 2002
5	March 2002
1	January 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30