Automating widetag dispatch

I would like to optimize some (apply #'map-into ..) calls where the
sequence(s) passed are not created by me. That is, optimize the
non-open-coded MAP-INTO.

I gathered the pieces of the widetag dispatching code for
VECTOR-SUBSEQ* and wrote a general macro for creating dispatch tables.
Using the first parameter as the specialized array,
DEFINE-ARRAY-DISPATCH defines each specializing function with a
corresponding type declaration inside. VECTOR-SUBSEQ* may now be
written as:

(define-array-dispatch vector-subseq-dispatch (array start end)
  (declare (optimize speed (safety 0)))
  (declare (type index start end))
  (subseq array start end))

(defun vector-subseq* (sequence start end)
  (declare (type vector sequence))
  (declare (type index start)
           (type (or null index) end)
           (optimize speed))
  (with-array-data ((data sequence)
                    (start start)
                    (end end)
                    :check-fill-pointer t
                    :force-inline t)
    (vector-subseq-dispatch data start end)))

To slightly complicate matters, the current MAP-INTO is kludgy. With
that kludginess fixed[1], a basic MAP-INTO benchmark drops from 385ms

BUG: incorrect results from LOGAND (AMD64)

Hi,

* (lisp-implementation-version)
"1.0.57.15-35f68f4"
* (defun foo (x)
    (declare (optimize (space 2))
             (type (integer 12417236377505266230 12417274239874990070) x))
    (logand 8459622733968096971 x))
FOO
* (foo 12417237222845306758)
11836165733894624898  ;; <-- incorrect
* (logand 8459622733968096971 12417237222845306758)
2612793697039849090
* (defun bar (x) 
    (declare (type (integer 22965360520649903105 22965361070405717069) x))
    (lognand 6936474818856893141 x))
BAR
* (bar 22965361070405716988)
#<unknown immediate object, lowtag=#b1, widetag=#x41 {FFFFFFEFFD4D3D41}>

(More random-integer testing.)

--

-- 
Eric Marsden

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 

rudimentary escape analysis for NLXs [Was: master: lazy *STACK-TOP-HINT*s]

On 21 May 2012 23:16, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:
> On 21 May 2012 19:00, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:
>
>>> Does it mean that
>>>
>>>  (define-condition once-again () ())
>>>
>>>  (prog ((+once-again+ (make-condition 'once-again))
>>>         (n 1000000))
>>>   :again
>>>     (handler-bind ((once-again #'(lambda (c)
>>>                                    (declare (ignore c))
>>>                                    (go :again))))
>>>       (unless (zerop (decf n))
>>>         (error +once-again+))))
>>>
>>> now runs in nearly constant space?

...stuff...

> After those (TYPEP CONDITION (CAR HANDLER)) seems to be the last
> source of consing in SIGNAL, aside from the &REST list allocation
> which doesn't matter here.

Amusingly, it turned out that the TYPEP consing came from NLX value
cells as well. Rudimentary escape analysis is enough to sort this out.

I already committed the SIGNAL improvements, but would much appreciate
it if someone could find the time to review this one before I commit
it. I keep having the feeling I'm missing something obvious.

package name for implicit generic function symbols

I'm always annoyed by messages like:

   Implicitly creating new generic function FOO.

scrolling by in my slime window. WTF is FOO? Well, the problem is that FOO is usually in the then-current
package and so the package identifier isn't printed out. The following patch causes the package name to be
printed in the STYLE-WARNING. Any objections to seeing this in the tree post-freeze?

thanks,

Cyrus

diff --git a/src/code/condition.lisp b/src/code/condition.lisp
index 3e7e84e..d0b7013 100644
--- a/src/code/condition.lisp
+++ b/src/code/condition.lisp
@@ -1004,8 +1004,9 @@ (define-condition implicit-generic-function-warning (style-warning)
   ((name :initarg :name :reader implicit-generic-function-name))
   (:report
    (lambda (condition stream)
-     (format stream "~@<Implicitly creating new generic function ~S.~:@>"
-             (implicit-generic-function-name condition)))))
+     (let ((*package* (find-package :keyword)))
+       (format stream "~@<Implicitly creating new generic function ~S.~:@>"
+               (implicit-generic-function-name condition))))))

 (define-condition extension-failure (reference-condition simple-error)
   ())

SBCL compiler bug? Overzealous optimization?

In looking over the errors generated by a cl-test-grid run, I looked
into the trivial-backtrace test that was failing. [1] I think that
I've uncovered a subtle bug in the SBCL compiler.

    [1] http://cl-test-grid.appspot.com/blob?key=100025

I'm using almost-the-latest SBCL (1.0.55.0-abb03f9-dirty) compiled for
64-bit with threading on MacOSX Lion (10.7.3).

This is the simplest I can seem to get the same problem to arise is
this:

    (defun absorbs ()
      (let ((ret 'no-error))
        (handler-case
            (let ((y 0))
              (/ y))
          (division-by-zero (c) (setf ret c)))
        ret))

When that compiles, it gives no warnings.  When invoked, it returns
NO-ERROR.

This, on the other hand, gives me a warning at compile time and
returns an instance of the division-by-zero error when invoked.

    (defun throws ()
      (let ((ret 'no-error))
        (handler-case

Fwd: Less world-locking in PCL

Forgot to CC the list.

---------- Forwarded message ----------
From: Nikodemus Siivola <nikodemus <at> random-state.net>
Date: 14 May 2012 20:07
Subject: Re: [Sbcl-devel] Less world-locking in PCL
To: Paul Khuong <pvk <at> pvk.ca>

On 27 March 2012 11:22, Nikodemus Siivola <nikodemus <at> random-state.net> wrote:

> I have (hm, had? can't find it just now) a not-quite-shipshape tree
> somewhere that takes the same approach to some of the PCL issues, but
> uses closures instead of interpreted functions. (Re-instating a code
> path that was deleted a few years back.) That tree is not part of my
> threading work. The motivation there was to speed up CLOS code by
> compiling things only if they get called at least N times.

Well, it is part of my threading work now. :)

 https://github.com/nikodemus/SBCL/tree/wip-clos-sans-compiler

Above is current the work in progress tree -- not much there yet, but
enough to show the basic idea. (Could not find my old tree, so this is
what I've hacked up today -- hence not very far yet, and virtually
untested.)

Cheers,

 -- nikodemus

freeze for 1.0.57

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

BUG: SB-VM::FAST-ASH-LEFT-MOD32/UNSIGNED=>UNSIGNED on PowerPC

Hi,

On PowerPC:

* (lisp-implementation-version)
"1.0.56.68-e0aff99"
*  (lambda (x)
     (declare (type (rational * 4) x))
     (logbitp x 122741952))
debugger invoked on a SIMPLE-ERROR:
  #<SB-C:TN t1> is not valid as the first argument to VOP:
  SB-VM::FAST-ASH-LEFT-MOD32/UNSIGNED=>UNSIGNED
Primitive type: T
SC restrictions:
  (SB-VM::UNSIGNED-REG)
The primitive type disallows these loadable SCs:
  (SB-VM::UNSIGNED-REG)

[From pfdietz's random-integer testing]

--

-- 
Eric Marsden

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

BUG: incorrect type checks on AMD64

Hi,

* (lisp-implementation-version)
"1.0.56.66-2892e35"
* (defun foo (x)
    (declare (optimize (speed 0) (space 0))
             (type (integer -228645653448155482 -228645653447928749) x))
    (floor 1.0 (the (integer -228645653448151677 -228645653448150900) x)))
FOO
* (foo -228645653448151381)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002979243}>:
  The value -228645653448151381
  is not of type
    (INTEGER -228645653448151677 -228645653448150900).

[From pfdietz's random-integer testing]

--

-- 
Eric Marsden

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Interface changes

I would like to have a dialogue about how we want to deal with
interface changes, namely what we do when we remove or rename exported
symbols that are used in libraries and systems outside SBCL.

I started pushing *features* symbols to guide this in my personal
builds, I don't think this can be answer.  There'll be too many and
when I use an official build I crash and burn.

My toy has auto-recovery for this kind of change.  Code that
determines whether certain symbols are present, with the required
sugar to deal with names of possibly not yet existing packages.  It is
the ugliest code in my toy which probably takes it right to being
among the ugliest pieces of code this side of Saturn.

One straightforward solution is that we introduce *feature* symbols
but batch up interface changes so that we don't flood ourselves with
symbols.  :sbcl-api-1, :sbcl-api-2 ...

Pure interface changes without functionality changes could also have
third-party modules that translate.

Martin
--

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer <at> cons.org>   http://www.cons.org/cracauer/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

wanted: sb-sequence docs

https://bugs.launchpad.net/sbcl/+bug/994528

Just saying,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel