Gábor Melis | 1 Apr 11:08 2011
Picon

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
Robert Goldman | 1 Apr 15:08 2011

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)

Gábor Melis | 1 Apr 16:06 2011
Picon

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)

Juho Snellman | 2 Apr 04:02 2011
Picon
Picon

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
Jim Wise | 2 Apr 04:09 2011

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
Christophe Rhodes | 2 Apr 16:45 2011
Picon

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
Elliott Slaughter | 3 Apr 18:45 2011
Picon

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
Christophe Rhodes | 3 Apr 19:10 2011
Picon

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
Elliott Slaughter | 4 Apr 04:11 2011
Picon

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
Elliott Slaughter | 4 Apr 04:52 2011
Picon

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

Gmane