You can subscribe to this list here.
2000 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
|
May
(16) |
Jun
(5) |
Jul
(5) |
Aug
(27) |
Sep
(25) |
Oct
(10) |
Nov
(40) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(78) |
Feb
(80) |
Mar
(35) |
Apr
(73) |
May
(97) |
Jun
(44) |
Jul
(38) |
Aug
(43) |
Sep
(94) |
Oct
(124) |
Nov
(13) |
Dec
(79) |
2002 |
Jan
(144) |
Feb
(68) |
Mar
(128) |
Apr
(117) |
May
(90) |
Jun
(63) |
Jul
(42) |
Aug
(66) |
Sep
(97) |
Oct
(89) |
Nov
(92) |
Dec
(88) |
2003 |
Jan
(101) |
Feb
(127) |
Mar
(103) |
Apr
(145) |
May
(211) |
Jun
(143) |
Jul
(67) |
Aug
(184) |
Sep
(212) |
Oct
(117) |
Nov
(181) |
Dec
(86) |
2004 |
Jan
(92) |
Feb
(95) |
Mar
(163) |
Apr
(242) |
May
(202) |
Jun
(114) |
Jul
(94) |
Aug
(148) |
Sep
(163) |
Oct
(111) |
Nov
(95) |
Dec
(133) |
2005 |
Jan
(148) |
Feb
(102) |
Mar
(213) |
Apr
(178) |
May
(202) |
Jun
(199) |
Jul
(189) |
Aug
(309) |
Sep
(126) |
Oct
(128) |
Nov
(148) |
Dec
(156) |
2006 |
Jan
(222) |
Feb
(184) |
Mar
(152) |
Apr
(176) |
May
(189) |
Jun
(186) |
Jul
(75) |
Aug
(182) |
Sep
(103) |
Oct
(144) |
Nov
(265) |
Dec
(197) |
2007 |
Jan
(175) |
Feb
(202) |
Mar
(212) |
Apr
(309) |
May
(203) |
Jun
(162) |
Jul
(207) |
Aug
(156) |
Sep
(136) |
Oct
(99) |
Nov
(199) |
Dec
(201) |
2008 |
Jan
(190) |
Feb
(201) |
Mar
(180) |
Apr
(132) |
May
(204) |
Jun
(149) |
Jul
(125) |
Aug
(102) |
Sep
(86) |
Oct
(269) |
Nov
(167) |
Dec
(291) |
2009 |
Jan
(155) |
Feb
(119) |
Mar
(174) |
Apr
(186) |
May
(168) |
Jun
(217) |
Jul
(107) |
Aug
(134) |
Sep
(111) |
Oct
(184) |
Nov
(81) |
Dec
(140) |
2010 |
Jan
(91) |
Feb
(93) |
Mar
(132) |
Apr
(137) |
May
(86) |
Jun
(112) |
Jul
(38) |
Aug
(112) |
Sep
(111) |
Oct
(124) |
Nov
(52) |
Dec
(49) |
2011 |
Jan
(72) |
Feb
(115) |
Mar
(91) |
Apr
(38) |
May
(119) |
Jun
(129) |
Jul
(34) |
Aug
(140) |
Sep
(37) |
Oct
(58) |
Nov
(130) |
Dec
(59) |
2012 |
Jan
(20) |
Feb
(9) |
Mar
(41) |
Apr
(89) |
May
(69) |
Jun
(21) |
Jul
(14) |
Aug
(24) |
Sep
(52) |
Oct
(49) |
Nov
(45) |
Dec
(21) |
2013 |
Jan
(36) |
Feb
(53) |
Mar
(50) |
Apr
(142) |
May
(125) |
Jun
(120) |
Jul
(89) |
Aug
(82) |
Sep
(45) |
Oct
(104) |
Nov
(69) |
Dec
(40) |
2014 |
Jan
(28) |
Feb
(85) |
Mar
(99) |
Apr
(108) |
May
(92) |
Jun
(73) |
Jul
(49) |
Aug
(65) |
Sep
(48) |
Oct
(61) |
Nov
(34) |
Dec
(41) |
2015 |
Jan
(84) |
Feb
(46) |
Mar
(81) |
Apr
(83) |
May
(56) |
Jun
(27) |
Jul
(47) |
Aug
(30) |
Sep
(31) |
Oct
(57) |
Nov
(65) |
Dec
(90) |
2016 |
Jan
(52) |
Feb
(71) |
Mar
(76) |
Apr
(37) |
May
(43) |
Jun
(16) |
Jul
(17) |
Aug
(51) |
Sep
(48) |
Oct
(40) |
Nov
(21) |
Dec
(36) |
2017 |
Jan
(40) |
Feb
(57) |
Mar
(47) |
Apr
(45) |
May
(28) |
Jun
(30) |
Jul
(53) |
Aug
(71) |
Sep
(48) |
Oct
(58) |
Nov
(42) |
Dec
(49) |
2018 |
Jan
(94) |
Feb
(50) |
Mar
(59) |
Apr
(56) |
May
(27) |
Jun
(35) |
Jul
(32) |
Aug
(56) |
Sep
(35) |
Oct
(26) |
Nov
(35) |
Dec
(46) |
2019 |
Jan
(36) |
Feb
(53) |
Mar
(53) |
Apr
(37) |
May
(28) |
Jun
(12) |
Jul
(75) |
Aug
(81) |
Sep
(70) |
Oct
(46) |
Nov
(115) |
Dec
(124) |
2020 |
Jan
(65) |
Feb
(95) |
Mar
(289) |
Apr
(106) |
May
(165) |
Jun
(63) |
Jul
(129) |
Aug
(107) |
Sep
(86) |
Oct
(85) |
Nov
(94) |
Dec
(107) |
2021 |
Jan
(67) |
Feb
(103) |
Mar
(131) |
Apr
(98) |
May
(116) |
Jun
(85) |
Jul
(26) |
Aug
(133) |
Sep
(60) |
Oct
(130) |
Nov
(196) |
Dec
(120) |
2022 |
Jan
(155) |
Feb
(107) |
Mar
(123) |
Apr
(232) |
May
(194) |
Jun
(139) |
Jul
(82) |
Aug
(58) |
Sep
(49) |
Oct
(71) |
Nov
(69) |
Dec
(117) |
2023 |
Jan
(142) |
Feb
(64) |
Mar
(114) |
Apr
(34) |
May
(56) |
Jun
(113) |
Jul
(87) |
Aug
(99) |
Sep
(49) |
Oct
(97) |
Nov
(88) |
Dec
(131) |
2024 |
Jan
(158) |
Feb
(106) |
Mar
(171) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stas B. <sta...@gm...> - 2024-03-20 17:39:29
|
Isn't it shadowed? If not, why not? On Wed, Mar 20, 2024 at 8:35 PM Douglas Katzman via Sbcl-devel < sbc...@li...> wrote: > > > Need sb-xc:fixnum here? > > + >> +(defun get-lisp-obj-address (x) >> + (etypecase x >> + (character >> + (dpb (char-code x) >> + (byte (- sb-vm:n-word-bits >> + sb-vm:n-widetag-bits) sb-vm:n-widetag-bits) >> + sb-vm:character-widetag)) >> + (fixnum >> + (ldb (byte sb-vm:n-word-bits 0) (ash x sb-vm:n-fixnum-tag-bits))))) >> >> _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Douglas K. <do...@go...> - 2024-03-20 17:34:06
|
Need sb-xc:fixnum here? + > +(defun get-lisp-obj-address (x) > + (etypecase x > + (character > + (dpb (char-code x) > + (byte (- sb-vm:n-word-bits > + sb-vm:n-widetag-bits) sb-vm:n-widetag-bits) > + sb-vm:character-widetag)) > + (fixnum > + (ldb (byte sb-vm:n-word-bits 0) (ash x sb-vm:n-fixnum-tag-bits))))) > > |
From: Christophe R. <cs...@ca...> - 2024-03-20 15:52:52
|
Rather than recording and replaying results of floating point computations for the purpose of doing float computations (e.g. for constant folding or type derivation) in the cross-compiler, we can do portable computations on the bits in the float representation, and verify that those operations correctly implemented the target semantics once the system is up and running. The changes at https://github.com/sbcl/sbcl/compare/master...csrhodes:sbcl:float implement this. For basic floating point operations, we compute the mathematically correct answer using mostly rationals (with some additional care to handle special-valued floats such as the infinities and negative zero), and generate our cross-float / flonum objects from this correct answer. For transcendental operations, we use a lookup table for the particular values we need during cross-compilation. The changes have successfully built, and validated a build-all-cores.sh output file. I also verified as I went that the changes reproduced the xfloat-math.lisp-expr file, only deleting that file as the last commit. I am confident in the consistency of this, and that this is an improvement (no more worrying about whether the host's version of LOG, or indeed FROUND, is correct enough) -- and would be happy to merge before the freeze for sbcl-2.4.3: but in case someone else's workflow is affected by this, please take a look at it or tell me what you need. Cheers, Christophe |
From: Stas B. <sta...@gm...> - 2024-03-19 23:43:56
|
fasteval has its own lexenv type, so that's easy, but the other interpreter doesn't. On Wed, Mar 20, 2024 at 2:31 AM Stas Boukarev <sta...@gm...> wrote: > It appears macro bodies are evaluated during compilation. > > On Wed, Mar 20, 2024 at 2:20 AM Stas Boukarev <sta...@gm...> wrote: > >> It doesn't fail on the CI, though. How come is CASE-TO-JUMP-TABLE even >> being called? CASE doesn't expand to it outside of compilation. Adding >> stubs will be a nightmare. >> >> On Wed, Mar 20, 2024 at 2:01 AM Douglas Katzman via Sbcl-devel < >> sbc...@li...> wrote: >> >>> (choosing an arbitrary commit to reply to ...) >>> I think CASE-TO-JUMP-TABLE needs some stubs for sb-fasteval. >>> I just built an SBCL at the latest commit and installed that to make >>> sure I've got no work-in-progress in my tree. >>> Build-all-cores fails now, as below (and many more) >>> >>> ; file: /Users/dougk/lisp/sbcl/src/compiler/srctran.lisp >>> ; in: DEFUN INTERVAL-ADD >>> ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-LOW SB-C::X) >>> ; (SB-C::INTERVAL-LOW SB-C::Y)) >>> ; >>> ; caught ERROR: >>> ; during macroexpansion of (BOUND-BINOP SB-XC:+ (INTERVAL-LOW X) ...). >>> Use >>> ; *BREAK-ON-SIGNALS* to intercept. >>> ; >>> ; The function HOST-SB-C:CASE-TO-JUMP-TABLE is undefined. >>> >>> ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-HIGH SB-C::X) >>> ; (SB-C::INTERVAL-HIGH SB-C::Y)) >>> ; >>> _______________________________________________ >>> Sbcl-devel mailing list >>> Sbc...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >>> >> |
From: Stas B. <sta...@gm...> - 2024-03-19 23:32:08
|
It appears macro bodies are evaluated during compilation. On Wed, Mar 20, 2024 at 2:20 AM Stas Boukarev <sta...@gm...> wrote: > It doesn't fail on the CI, though. How come is CASE-TO-JUMP-TABLE even > being called? CASE doesn't expand to it outside of compilation. Adding > stubs will be a nightmare. > > On Wed, Mar 20, 2024 at 2:01 AM Douglas Katzman via Sbcl-devel < > sbc...@li...> wrote: > >> (choosing an arbitrary commit to reply to ...) >> I think CASE-TO-JUMP-TABLE needs some stubs for sb-fasteval. >> I just built an SBCL at the latest commit and installed that to make sure >> I've got no work-in-progress in my tree. >> Build-all-cores fails now, as below (and many more) >> >> ; file: /Users/dougk/lisp/sbcl/src/compiler/srctran.lisp >> ; in: DEFUN INTERVAL-ADD >> ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-LOW SB-C::X) >> ; (SB-C::INTERVAL-LOW SB-C::Y)) >> ; >> ; caught ERROR: >> ; during macroexpansion of (BOUND-BINOP SB-XC:+ (INTERVAL-LOW X) ...). >> Use >> ; *BREAK-ON-SIGNALS* to intercept. >> ; >> ; The function HOST-SB-C:CASE-TO-JUMP-TABLE is undefined. >> >> ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-HIGH SB-C::X) >> ; (SB-C::INTERVAL-HIGH SB-C::Y)) >> ; >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> > |
From: Stas B. <sta...@gm...> - 2024-03-19 23:20:50
|
It doesn't fail on the CI, though. How come is CASE-TO-JUMP-TABLE even being called? CASE doesn't expand to it outside of compilation. Adding stubs will be a nightmare. On Wed, Mar 20, 2024 at 2:01 AM Douglas Katzman via Sbcl-devel < sbc...@li...> wrote: > (choosing an arbitrary commit to reply to ...) > I think CASE-TO-JUMP-TABLE needs some stubs for sb-fasteval. > I just built an SBCL at the latest commit and installed that to make sure > I've got no work-in-progress in my tree. > Build-all-cores fails now, as below (and many more) > > ; file: /Users/dougk/lisp/sbcl/src/compiler/srctran.lisp > ; in: DEFUN INTERVAL-ADD > ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-LOW SB-C::X) > ; (SB-C::INTERVAL-LOW SB-C::Y)) > ; > ; caught ERROR: > ; during macroexpansion of (BOUND-BINOP SB-XC:+ (INTERVAL-LOW X) ...). > Use > ; *BREAK-ON-SIGNALS* to intercept. > ; > ; The function HOST-SB-C:CASE-TO-JUMP-TABLE is undefined. > > ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-HIGH SB-C::X) > ; (SB-C::INTERVAL-HIGH SB-C::Y)) > ; > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Douglas K. <do...@go...> - 2024-03-19 22:59:11
|
(choosing an arbitrary commit to reply to ...) I think CASE-TO-JUMP-TABLE needs some stubs for sb-fasteval. I just built an SBCL at the latest commit and installed that to make sure I've got no work-in-progress in my tree. Build-all-cores fails now, as below (and many more) ; file: /Users/dougk/lisp/sbcl/src/compiler/srctran.lisp ; in: DEFUN INTERVAL-ADD ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-LOW SB-C::X) ; (SB-C::INTERVAL-LOW SB-C::Y)) ; ; caught ERROR: ; during macroexpansion of (BOUND-BINOP SB-XC:+ (INTERVAL-LOW X) ...). Use ; *BREAK-ON-SIGNALS* to intercept. ; ; The function HOST-SB-C:CASE-TO-JUMP-TABLE is undefined. ; (SB-C::BOUND-BINOP SB-XC:+ (SB-C::INTERVAL-HIGH SB-C::X) ; (SB-C::INTERVAL-HIGH SB-C::Y)) ; |
From: Douglas K. <do...@go...> - 2024-03-19 00:50:40
|
Doesn't really matter what the name component is so I made it into #\#. |
From: Stas B. <sta...@gm...> - 2024-03-19 00:21:46
|
// Running elfcore.test.sh in COMPILE evaluator mode ../../run-sbcl.sh --script ../../tools-for-build/elftool.lisp split \ --dynamic-space-size 256 ../../output/sbcl.core shrinkwrap-sbcl.s Unhandled SB-C::INPUT-ERROR-IN-LOAD in thread #<SB-THREAD:THREAD tid=70225 "main thread" RUNNING {1000EE0003}>: READ error during LOAD: Lock on package SB-C violated when interning *DEBUG-NAME-SHARP* while in package SB-EDITCORE. See also: The SBCL Manual, Node "Package Locks" (in form starting at line: 292, column: 0, position: 13574) On Tue, Mar 19, 2024 at 2:15 AM apache--- via Sbcl-commits < sbc...@li...> wrote: > The branch "master" has been updated in SBCL: > via de9f00c4c6f55178b2adff11b0dbdc152eca90c0 (commit) > from 1d0a27b130a87296ddcf3a5ef82d4391e1080f8c (commit) > > - Log ----------------------------------------------------------------- > commit de9f00c4c6f55178b2adff11b0dbdc152eca90c0 > Author: Charles Zhang <cha...@ya...> > Date: Sun Mar 17 19:16:49 2024 +0100 > > Make stuff regarding debug names much less complex. > > Don't show the full binding form for LET function debug names, just > show the names of the variables bound. This makes it so that > arbitrarily nested hairy stuff is NEVER debug-namified. This means > instead of truncating debug name forms, we can just use them as-is, > avoiding consing new objects. No new stuff is dumped that wasn't > already going to get dumped anyway. Printer control variables can be > used to display the debug names differently if need be, we don't need > to reinvent that. It was also found that we were passing literal leaf > objects to the &aux debug name, so don't do that. > > The upshot is that we can get rid of all the debug-name-marker > structures. There's no reason that something that exists purely for > compiler debugging should be privileged and have its own fop. > --- > src/code/load.lisp | 6 ---- > src/cold/compile-cold-sbcl.lisp | 2 +- > src/compiler/dump.lisp | 5 ---- > src/compiler/early-c.lisp | 57 > ++++-------------------------------- > src/compiler/generic/layout-ids.lisp | 1 - > src/compiler/ir1-translators.lisp | 4 ++- > src/compiler/ir1tran-lambda.lisp | 3 +- > src/compiler/ir1tran.lisp | 1 - > xfloat-math.lisp-expr | 2 ++ > 9 files changed, 13 insertions(+), 68 deletions(-) > > diff --git a/src/code/load.lisp b/src/code/load.lisp > index 8baf38d5c..caa87f837 100644 > --- a/src/code/load.lisp > +++ b/src/code/load.lisp > @@ -787,12 +787,6 @@ > (incf ptr))) > res)) > > -;;; Symbol-like entities > -(define-fop 49 :not-host (fop-debug-name-marker ((:operands kind))) > - (ecase kind > - (1 sb-c::*debug-name-sharp*) > - (2 sb-c::*debug-name-ellipsis*))) > - > (define-fop 45 :not-host (fop-layout ((:operands depthoid flags length) > name bitmap inherits)) > (decf depthoid) ; was bumped by 1 since non-stack args can't encode > negatives > diff --git a/src/cold/compile-cold-sbcl.lisp > b/src/cold/compile-cold-sbcl.lisp > index 8ebc52811..fd4487a64 100644 > --- a/src/cold/compile-cold-sbcl.lisp > +++ b/src/cold/compile-cold-sbcl.lisp > @@ -30,7 +30,7 @@ > ;;; in the cross-compiler was confusing as hell. > ;;; Consider any toplevel form in make-host-2 - it will have constants in > it, > ;;; and we need to know if each constant is dumpable. So we call > DUMPABLE-LEAFLIKE-P > -;;; which invokes SB-XC:TYPEP. But SB-XC:TYPEP may know nothing of > DEBUG-NAME-MARKER > +;;; which invokes SB-XC:TYPEP. But SB-XC:TYPEP may know nothing of a > particular struct type > ;;; until that DEFSTRUCT is seen. So how did it ever work? Well, for > starters, > ;;; if it's an unknown type, we need to signal a PARSE-UNKNOWN-TYPE > condition. > ;;; To signal that, we check whether that condition is in > *HANDLED-CONDITIONS*. > diff --git a/src/compiler/dump.lisp b/src/compiler/dump.lisp > index 096197d52..d26c85cfa 100644 > --- a/src/compiler/dump.lisp > +++ b/src/compiler/dump.lisp > @@ -477,11 +477,6 @@ > (dump-object 'values-specifier-type file) > (dump-object (type-specifier x) file) > (dump-fop 'fop-funcall file 1)) > - (sb-c::debug-name-marker ; these are atoms, much like symbols > - (dump-fop 'fop-debug-name-marker file > - (cond ((eq x sb-c::*debug-name-sharp*) 1) > - ((eq x sb-c::*debug-name-ellipsis*) 2) > - (t (bug "Bogus debug name marker"))))) > (instance > (multiple-value-bind (slot-names slot-names-p) > (gethash x (fasl-output-saved-slot-names file)) > diff --git a/src/compiler/early-c.lisp b/src/compiler/early-c.lisp > index 1c7213aee..b004ee244 100644 > --- a/src/compiler/early-c.lisp > +++ b/src/compiler/early-c.lisp > @@ -158,60 +158,13 @@ > (setf (bit seen h) 1))) > f)) > > -(defstruct (debug-name-marker (:print-function print-debug-name-marker) > - (:copier nil))) > -(declaim (freeze-type debug-name-marker)) > - > -(defvar *debug-name-level* 4) > -(defvar *debug-name-length* 12) > -(defvar *debug-name-punt*) > -(define-load-time-global *debug-name-sharp* (make-debug-name-marker)) > -(define-load-time-global *debug-name-ellipsis* (make-debug-name-marker)) > - > -(defun print-debug-name-marker (marker stream level) > - (declare (ignore level)) > - (cond ((eq marker *debug-name-sharp*) > - (write-char #\# stream)) > - ((eq marker *debug-name-ellipsis*) > - (write-string "..." stream)) > - (t > - (write-string "???" stream)))) > - > (declaim (ftype (sfunction () list) name-context)) > (defun debug-name (type thing &optional context) > - (let ((*debug-name-punt* nil)) > - (labels ((walk (x) > - (typecase x > - (cons > - (if (plusp *debug-name-level*) > - (let ((*debug-name-level* (1- *debug-name-level*))) > - (do ((tail (cdr x) (cdr tail)) > - (name (cons (walk (car x)) nil) > - (cons (walk (car tail)) name)) > - (n (1- *debug-name-length*) (1- n))) > - ((or (not (consp tail)) > - (not (plusp n)) > - *debug-name-punt*) > - (cond (*debug-name-punt* > - (setf *debug-name-punt* nil) > - (nreverse name)) > - ((atom tail) > - (nconc (nreverse name) (walk tail))) > - (t > - (setf *debug-name-punt* t) > - (nconc (nreverse name) (list > *debug-name-ellipsis*))))))) > - *debug-name-sharp*)) > - ((or symbol number string) > - x) > - (t > - ;; wtf?? This looks like a source of sensitivity to the > cross-compiler host > - ;; in addition to which it seems generally a stupid > idea. > - (type-of x))))) > - (let ((name (list* type (walk thing) (when context > (name-context))))) > - (when (legal-fun-name-p name) > - (bug "~S is a legal function name, and cannot be used as a ~ > - debug name." name)) > - name)))) > + (let ((name (list* type thing (when context (name-context))))) > + (when (legal-fun-name-p name) > + (bug "~S is a legal function name, and cannot be used as a ~ > + debug name." name)) > + name)) > > ;;; Bound during eval-when :compile-time evaluation. > (defvar *compile-time-eval* nil) > diff --git a/src/compiler/generic/layout-ids.lisp > b/src/compiler/generic/layout-ids.lisp > index e38ebe4e0..bb59bba69 100644 > --- a/src/compiler/generic/layout-ids.lisp > +++ b/src/compiler/generic/layout-ids.lisp > @@ -154,7 +154,6 @@ SB-KERNEL:HAIRY-TYPE > SB-C::LOCAL-CALL-CONTEXT > SB-C::IR2-NLX-INFO > SB-C::LVAR-FUNCTION-ANNOTATION > -SB-C::DEBUG-NAME-MARKER > SB-C::CORE-DEBUG-SOURCE > SB-REGALLOC::INTERFERENCE-GRAPH > SB-C::RESTART-LOCATION > diff --git a/src/compiler/ir1-translators.lisp > b/src/compiler/ir1-translators.lisp > index 0e69e65dc..21e209750 100644 > --- a/src/compiler/ir1-translators.lisp > +++ b/src/compiler/ir1-translators.lisp > @@ -884,7 +884,9 @@ have been evaluated." > forms > vars > :post-binding-lexenv post-binding-lexenv > - :debug-name (debug-name 'let bindings)))) > + :debug-name (debug-name 'let > + (mapcar > #'leaf-source-name > + vars))))) > (reference-leaf start ctran fun-lvar fun))) > (ir1-convert-combination-args fun-lvar ctran next result > values > :arg-source-forms > bindings)))))) > diff --git a/src/compiler/ir1tran-lambda.lisp > b/src/compiler/ir1tran-lambda.lisp > index 2a978e313..f48c10aaf 100644 > --- a/src/compiler/ir1tran-lambda.lisp > +++ b/src/compiler/ir1tran-lambda.lisp > @@ -131,7 +131,8 @@ > :post-binding-lexenv > post-binding-lexenv > :debug-name (debug-name > '&aux-bindings > - aux-vars) > + (mapcar > #'leaf-source-name > + aux-vars)) > :value-source-forms (rest > value-source-forms)))) > (reference-leaf start ctran fun-lvar fun) > (ir1-convert-combination-args fun-lvar ctran next result > diff --git a/src/compiler/ir1tran.lisp b/src/compiler/ir1tran.lisp > index 78bf25812..d81f583ab 100644 > --- a/src/compiler/ir1tran.lisp > +++ b/src/compiler/ir1tran.lisp > @@ -332,7 +332,6 @@ > system-area-pointer > #+sb-simd-pack simd-pack > #+sb-simd-pack-256 simd-pack-256)) > - (cl:typep obj 'debug-name-marker) > ;; STANDARD-OBJECT layouts use MAKE-LOAD-FORM, but all other layouts > ;; have the same status as symbols - composite objects but leaflike. > (and (typep obj 'layout) (not (layout-for-pcl-obj-p obj))) > diff --git a/xfloat-math.lisp-expr b/xfloat-math.lisp-expr > index 45b51b9cc..bb964c4e9 100644 > --- a/xfloat-math.lisp-expr > +++ b/xfloat-math.lisp-expr > @@ -5685,6 +5685,7 @@ > (<= (#.(S #x40800000) #.(D #x40300000 0)) T) > (<= (#.(S #x40A00000) 0) NIL) > (<= (#.(S #x40A00000) 16) T) > +(<= (#.(S #x40A00000) #.(S #x40C00000)) T) > (<= (#.(S #x40A00000) #.(S #x41700000)) T) > (<= (#.(S #x40A00000) #.(S #x41800000)) T) > (<= (#.(S #x40A00000) #.(S #x7F7FFFFF)) T) > @@ -8037,6 +8038,7 @@ > (<= (#.(D #x40122123 #x45B5DEC) #.(D #x7FEFFFFF #xFFFFFFFF)) T) > (<= (#.(D #x40140000 0) 0) NIL) > (<= (#.(D #x40140000 0) 16) T) > +(<= (#.(D #x40140000 0) #.(D #x40180000 0)) T) > (<= (#.(D #x40140000 0) #.(D #x402E0000 0)) T) > (<= (#.(D #x40140000 0) #.(D #x40300000 0)) T) > (<= (#.(D #x40140000 0) #.(D #x7FEFFFFF #xFFFFFFFF)) T) > > ----------------------------------------------------------------------- > > > hooks/post-receive > -- > SBCL > > > _______________________________________________ > Sbcl-commits mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-commits > |
From: Stas B. <sta...@gm...> - 2024-03-18 18:22:35
|
Sure, there are still many possible transformations to add. On Mon, Mar 18, 2024 at 8:54 PM Douglas Katzman via Sbcl-devel < sbc...@li...> wrote: > Should we change what "suitable" means, now that there is perfect hashing? > Specifically at: > > ;; TOOD: this size could be reduced now. For spread-out fixnum > keys, > ;; we'll use a perfect hash, making the table exactly sized. > ;; So the situation where low load factor is beneficial are few. > (size-limit (* (length keys) 2))) > > Maybe there is a calculation we could do, e.g. if the perfect hash needs > neither SCRAMBLE nor TAB arrays but only uses shifts and adds, it's good to > perfectly size the table if it was large. > But if the waste is small, it's better to have unused rows. This factor I > chose of 2 is very arbitrary. > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Douglas K. <do...@go...> - 2024-03-18 17:50:57
|
Should we change what "suitable" means, now that there is perfect hashing? Specifically at: ;; TOOD: this size could be reduced now. For spread-out fixnum keys, ;; we'll use a perfect hash, making the table exactly sized. ;; So the situation where low load factor is beneficial are few. (size-limit (* (length keys) 2))) Maybe there is a calculation we could do, e.g. if the perfect hash needs neither SCRAMBLE nor TAB arrays but only uses shifts and adds, it's good to perfectly size the table if it was large. But if the waste is small, it's better to have unused rows. This factor I chose of 2 is very arbitrary. |
From: Stas B. <sta...@gm...> - 2024-03-18 13:39:23
|
The new code I added is prepared for compile-perfect-hash returning NIL. Can't say anything for the rest. On Mon, Mar 18, 2024 at 4:34 PM Douglas Katzman <do...@go...> wrote: > The Bob Jenkins code was able to compute a non-minimal hash of these keys > but the Lisp wrapper didn't try that because the input size wasn't a > power-of-2. But using the non-minimal hash and additional array lookup we > could remap to the required range. > I really didn't want any consumer of the MPH generator to have to confront > the possibility of it not returning any output (as long as the 32-bit > inputs were deemed unique). Are you sure that all places are OK with it? > I guess we need a generator that is actually maintained. > > On Mon, Mar 18, 2024 at 9:13 AM stassats via Sbcl-commits < > sbc...@li...> wrote: > >> The branch "master" has been updated in SBCL: >> via cfbafa3b38dd6a47e4f2c2d14b4a0e4ca711417b (commit) >> from d15363cef2211180a4e6c20d6343dc31af9767e1 (commit) >> >> - Log ----------------------------------------------------------------- >> commit cfbafa3b38dd6a47e4f2c2d14b4a0e4ca711417b >> Author: Stas Boukarev <sta...@gm...> >> Date: Mon Mar 18 16:06:08 2024 +0300 >> >> Correctly exit from make-perfect-hash-lambda. >> >> When failing to compute a perfect hash. >> >> Fixes lp#2058210 >> --- >> src/compiler/sxhash.lisp | 30 +++++++++++++++--------------- >> 1 file changed, 15 insertions(+), 15 deletions(-) >> >> diff --git a/src/compiler/sxhash.lisp b/src/compiler/sxhash.lisp >> index 851964c12..350a20820 100644 >> --- a/src/compiler/sxhash.lisp >> +++ b/src/compiler/sxhash.lisp >> @@ -230,21 +230,21 @@ >> (function (* char) int system-area-pointer >> int)) >> (logior (if minimal 1 0) (if fast 2 0)) >> (sb-sys:vector-sap array) (length >> array)))))) >> - (let ((string (findit minimal))) >> - (when (and (not string) >> - (= (length array) (power-of-two-ceiling >> (length array))) >> - minimal) >> - ;; Possibly try again as non-minimal because it's >> equivalent on 2^N keys. >> - ;; This should NOT be needed but it works around a >> deficiency >> - ;; in C which I am not smart enough to fix. >> - (when (null (setq string (findit nil))) >> - (return-from make-perfect-hash-lambda nil))) >> - (let ((expr (with-standard-io-syntax >> - (let ((*package* #.(find-package >> "SB-C"))) >> - (read-from-string string))))) >> - (when cacheable (setf (gethash cache-key cache) >> expr)) >> - (setf returned-string string) >> - expr))))))) >> + (let* ((string >> + (or (findit minimal) >> + (and minimal >> + (= (length array) >> (power-of-two-ceiling (length array))) >> + ;; Try again as non-minimal because >> it's equivalent on 2^N keys. >> + ;; This should NOT be needed but it >> works around a deficiency >> + ;; in C which I am not smart enough >> to fix. >> + (findit nil)) >> + (return-from make-perfect-hash-lambda >> nil))) >> + (expr (with-standard-io-syntax >> + (let ((*package* #.(find-package >> "SB-C"))) >> + (read-from-string string))))) >> + (when cacheable (setf (gethash cache-key cache) >> expr)) >> + (setf returned-string string) >> + expr)))))) >> (let ((tables)) >> ;; Hoist the constants into symbol-macrolets rather than LETs >> ;; because my work-in-progress 32-bit-modular-arithmetic optimizer >> >> ----------------------------------------------------------------------- >> >> >> hooks/post-receive >> -- >> SBCL >> >> >> _______________________________________________ >> Sbcl-commits mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-commits >> > |
From: Douglas K. <do...@go...> - 2024-03-18 13:34:59
|
The Bob Jenkins code was able to compute a non-minimal hash of these keys but the Lisp wrapper didn't try that because the input size wasn't a power-of-2. But using the non-minimal hash and additional array lookup we could remap to the required range. I really didn't want any consumer of the MPH generator to have to confront the possibility of it not returning any output (as long as the 32-bit inputs were deemed unique). Are you sure that all places are OK with it? I guess we need a generator that is actually maintained. On Mon, Mar 18, 2024 at 9:13 AM stassats via Sbcl-commits < sbc...@li...> wrote: > The branch "master" has been updated in SBCL: > via cfbafa3b38dd6a47e4f2c2d14b4a0e4ca711417b (commit) > from d15363cef2211180a4e6c20d6343dc31af9767e1 (commit) > > - Log ----------------------------------------------------------------- > commit cfbafa3b38dd6a47e4f2c2d14b4a0e4ca711417b > Author: Stas Boukarev <sta...@gm...> > Date: Mon Mar 18 16:06:08 2024 +0300 > > Correctly exit from make-perfect-hash-lambda. > > When failing to compute a perfect hash. > > Fixes lp#2058210 > --- > src/compiler/sxhash.lisp | 30 +++++++++++++++--------------- > 1 file changed, 15 insertions(+), 15 deletions(-) > > diff --git a/src/compiler/sxhash.lisp b/src/compiler/sxhash.lisp > index 851964c12..350a20820 100644 > --- a/src/compiler/sxhash.lisp > +++ b/src/compiler/sxhash.lisp > @@ -230,21 +230,21 @@ > (function (* char) int system-area-pointer > int)) > (logior (if minimal 1 0) (if fast 2 0)) > (sb-sys:vector-sap array) (length array)))))) > - (let ((string (findit minimal))) > - (when (and (not string) > - (= (length array) (power-of-two-ceiling > (length array))) > - minimal) > - ;; Possibly try again as non-minimal because it's > equivalent on 2^N keys. > - ;; This should NOT be needed but it works around a > deficiency > - ;; in C which I am not smart enough to fix. > - (when (null (setq string (findit nil))) > - (return-from make-perfect-hash-lambda nil))) > - (let ((expr (with-standard-io-syntax > - (let ((*package* #.(find-package > "SB-C"))) > - (read-from-string string))))) > - (when cacheable (setf (gethash cache-key cache) > expr)) > - (setf returned-string string) > - expr))))))) > + (let* ((string > + (or (findit minimal) > + (and minimal > + (= (length array) > (power-of-two-ceiling (length array))) > + ;; Try again as non-minimal because > it's equivalent on 2^N keys. > + ;; This should NOT be needed but it > works around a deficiency > + ;; in C which I am not smart enough > to fix. > + (findit nil)) > + (return-from make-perfect-hash-lambda > nil))) > + (expr (with-standard-io-syntax > + (let ((*package* #.(find-package > "SB-C"))) > + (read-from-string string))))) > + (when cacheable (setf (gethash cache-key cache) expr)) > + (setf returned-string string) > + expr)))))) > (let ((tables)) > ;; Hoist the constants into symbol-macrolets rather than LETs > ;; because my work-in-progress 32-bit-modular-arithmetic optimizer > > ----------------------------------------------------------------------- > > > hooks/post-receive > -- > SBCL > > > _______________________________________________ > Sbcl-commits mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-commits > |
From: Stas B. <sta...@gm...> - 2024-03-18 12:28:30
|
That just shows that Linux is not a serious OS. On Mon, Mar 18, 2024 at 12:01 PM Robert Boyer <rob...@gm...> wrote: > Dear heroes, you wonderful SBCL bug guys, > > Is this a bug, or just the way it is supposed to be? For example, how > about a good old fashioned error message of some sort? > > The following kills my Chromebook. In a previous very related message I > sent a lot > of info, namely /proc/cpuinfo. Let me know if you want any more info. > > ;;; sbcl --dynamic-space-size 32000 --no-userinit > ;;; This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp. > > (defun sum (n) > (declare (fixnum n)) > (let ((ar (make-array n :element-type '(integer 0 1))) > (cnt 0) > (i 0)) > (declare (type (array (integer 0 1) (*))) > (fixnum cnt i)) > (loop > (cond ((eql i n) (return nil))) > (setf (aref ar i) 1) > (incf i)) > (setf i 0) > (loop > (cond ((eql i n) (return cnt))) > (incf cnt (aref ar i)) > (incf i)))) > > (sum (expt 10 11)) > > ;;; My Chromebook dies. My best evidence is that the clock on the side > panel > ;;; gets way behind. Sometimes, the machine will reboot by itself, but not > ;;; well. > > ;;; ⏻ with ⟳ held down it is! > > Bob > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Stas B. <sta...@gm...> - 2024-03-17 16:35:43
|
gcc and clang do recognize both switch and ifs, but I suppose if we provide a way for optimized code to emit the code it wants then it's sufficient. On Sun, Mar 17, 2024 at 7:32 PM Douglas Katzman <do...@go...> wrote: > I don't need general if-else trees. It was the only mechanism available > when I made the first version of jump tables > > On Sun, Mar 17, 2024 at 12:00 PM Stas Boukarev <sta...@gm...> wrote: > >> How important would you say is converting IF+EQL trees to jump-tables? >> Would only handling *CASE and FIND/MEMBER be enough? >> sb-c:jump-table already works pretty well on arm64 (although it doesn't >> actually speed things up). Not handling IF+OR+EQL would reduce some >> complexity. >> > |
From: Douglas K. <do...@go...> - 2024-03-17 16:32:44
|
I don't need general if-else trees. It was the only mechanism available when I made the first version of jump tables On Sun, Mar 17, 2024 at 12:00 PM Stas Boukarev <sta...@gm...> wrote: > How important would you say is converting IF+EQL trees to jump-tables? > Would only handling *CASE and FIND/MEMBER be enough? > sb-c:jump-table already works pretty well on arm64 (although it doesn't > actually speed things up). Not handling IF+OR+EQL would reduce some > complexity. > |
From: Stas B. <sta...@gm...> - 2024-03-17 16:01:09
|
How important would you say is converting IF+EQL trees to jump-tables? Would only handling *CASE and FIND/MEMBER be enough? sb-c:jump-table already works pretty well on arm64 (although it doesn't actually speed things up). Not handling IF+OR+EQL would reduce some complexity. On Wed, Mar 13, 2024 at 10:15 PM Douglas Katzman <do...@go...> wrote: > Whatever you think is best; your efforts on improving it are greatly > appreciated. To be clear, you do realize that CASE has been doing > hash-based dispatch since 5 years ago > <https://sourceforge.net/p/sbcl/sbcl/ci/423fb47c44a687c6930d891e259710fe2862c22a>, > right? > Our testing showed performance gains from the older code. Anything that > is done to make it even better now is icing on the cake. The fact that it > never inserts unreachable branches is already a win in terms of density of > the jump table. > |
From: Stas B. <sta...@gm...> - 2024-03-17 14:50:29
|
Try read-sequence instead. On Sun, Mar 17, 2024 at 5:32 PM Robert Boyer <rob...@gm...> wrote: > Thanks again for SBCL, the best Lisp I have ever used. > > read-byte and write-byte seem a lot slower than /usr/bin/cp by a factor of > 4. > > The file cp.lisp is attached. > > > sbcl --no-userinit > This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (load "cp.lisp") > -rw-r----- 1 bob chronos-access 1250000000 Mar 16 17:10 > primes-below-10000000000.bin > T > * (compare) > Evaluation took: > 142.388 seconds of real time > 67.973978 seconds of total run time (63.841888 user, 4.132090 system) > 47.74% CPU > 158,563,705,669 processor cycles > 0 bytes consed > > Evaluation took: > 32.013 seconds of real time > 0.002824 seconds of total run time (0.001445 user, 0.001379 system) > 0.01% CPU > 15 forms interpreted > 35,648,311,244 processor cycles > 0 bytes consed > > #<SB-IMPL::PROCESS :EXITED 0> > * (/ 142.388 32.013) > 4.447818 > * > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Charles Z. <cha...@ya...> - 2024-03-17 09:19:26
|
I can appreciate that it was written for a reason, though what prompted this was that I looked at how the instance was laid out on my machine and noticed there was no padding word and was confused and realized that for the majority of configurations it is not true that headers and layouts are combined into one slot, so the count was just off by one. I agree the comment should have been phrased better, though this prompts me to think that maybe alternative A for compact instance header is more useful if we want it to work for all platforms to make memory layout more uniform (and also bring the advantages to more than just x86-64). The current implementation is a no-go on darwin macs for example which disallow usage of low 32-bit space. What about an alternative C that is like alternative A, only we make instance widetags 0 so that we don’t even need arithmetic to extract the layout? And now that raw slots are interleaved, putting the %length in the layout seems to add close to no overhead for non-GC code? (For standard objects the length is fixed anyway and for structs who cares outside of introspection/gc?) This would even make it applicable for 32-bit with no restrictions on pointer size for 64-bit. What do you think? Am Sonntag, März 17, 2024, 3:32 AM schrieb Douglas Katzman <do...@go...>: You may not appreciate the comment you removed, and while it may now be irrelevant, it was not.If you go back far enough in the logs, all structures were required to dump their physical length (after rounding) which made it impossible to recover the logical length, and moreover there were discrepancies between instances dumped by genesis and dumped by the target compiler, so it was sort of useful to know where screwups happened, why, and what the expected representation is. commit 81b94868053359caf775930c2cf2027a8057e43f Author: Douglas Katzman <do...@go...> Date: Fri Mar 14 12:13:03 2014 -0400 Fix discrepancy in %instance-length for instances created by genesis. diff --git a/src/compiler/generic/genesis.lisp b/src/compiler/generic/genesis.lisp index 84c9c5f72..80a57e4be 100644 --- a/src/compiler/generic/genesis.lisp +++ b/src/compiler/generic/genesis.lisp @@ -2068,8 +2068,11 @@ core and return a descriptor to it." (+ sb!vm:instance-slots-offset (target-layout-index 'n-untagged-slots))))) (ntagged (- size nuntagged))) + ;; An instance's header word should always indicate that it has an *odd* + ;; number of words after the header so that the total with header is even. (write-memory result (make-other-immediate-descriptor - size sb!vm:instance-header-widetag)) + (+ size (logandc1 size 1)) + sb!vm:instance-header-widetag)) (write-wordindexed result sb!vm:instance-slots-offset layout) (do ((index 1 (1+ index))) ((eql index size)) So you made me go and do archaeology for no reason other than rebut your editorial remark "It seems bad that this comment says X" which I personally think is as misplaced as the comment, particularly for structures that genesis dumps. On Sat, Mar 16, 2024 at 9:12 PM apache--- via Sbcl-commits <sbc...@li...> wrote: The branch "master" has been updated in SBCL: via 97d72107460a03d81f48eff3f9c6683458f05927 (commit) from f14716915a8cf723edfff81203be5d990c88119a (commit) - Log ----------------------------------------------------------------- commit 97d72107460a03d81f48eff3f9c6683458f05927 Author: Charles Zhang <cha...@ya...> Date: Sun Mar 17 02:09:29 2024 +0100 Remove misleading comment. It only applies to one specific configuration on one specific architecture, so it seems very bad to write it as if it were a universal truth. Also it's weird to restate how structs are laid out in memory here. --- src/code/source-location.lisp | 1 - 1 file changed, 1 deletion(-) diff --git a/src/code/source-location.lisp b/src/code/source-location.lisp index cc72c3b79..b2256de27 100644 --- a/src/code/source-location.lisp +++ b/src/code/source-location.lisp @@ -13,7 +13,6 @@ ;;; A DEFINITION-SOURCE-LOCATION contains two packed fixnums in the INDICES slot, ;;; and unless there is a non-nil plist, does not store the plist. -;;; Packed representation is: header + layout, namestring, indices, (padding) (def!struct (definition-source-location (:constructor %make-basic-definition-source-location (namestring indices)) ----------------------------------------------------------------------- hooks/post-receive -- SBCL _______________________________________________ Sbcl-commits mailing list Sbc...@li... https://lists.sourceforge.net/lists/listinfo/sbcl-commits |
From: Douglas K. <do...@go...> - 2024-03-17 02:38:39
|
You may not appreciate the comment you removed, and while it may now be irrelevant, it was not. If you go back far enough in the logs, all structures were required to dump their physical length (after rounding) which made it impossible to recover the logical length, and moreover there were discrepancies between instances dumped by genesis and dumped by the target compiler, so it was sort of useful to know where screwups happened, why, and what the expected representation is. commit 81b94868053359caf775930c2cf2027a8057e43f Author: Douglas Katzman <do...@go...> Date: Fri Mar 14 12:13:03 2014 -0400 Fix discrepancy in %instance-length for instances created by genesis. *diff --git a/src/compiler/generic/genesis.lisp b/src/compiler/generic/genesis.lisp* *index 84c9c5f72..80a57e4be 100644* *--- a/src/compiler/generic/genesis.lisp* *+++ b/src/compiler/generic/genesis.lisp* @@ -2068,8 +2068,11 @@ core and return a descriptor to it." (+ sb!vm:instance-slots-offset (target-layout-index 'n-untagged-slots))))) (ntagged (- size nuntagged))) + ;; An instance's header word should always indicate that it has an *odd* + ;; number of words after the header so that the total with header is even. (write-memory result (make-other-immediate-descriptor - size sb!vm:instance-header-widetag)) + (+ size (logandc1 size 1)) + sb!vm:instance-header-widetag)) (write-wordindexed result sb!vm:instance-slots-offset layout) (do ((index 1 (1+ index))) ((eql index size)) So you made me go and do archaeology for no reason other than rebut your editorial remark "It seems bad that this comment says X" which I personally think is as misplaced as the comment, particularly for structures that genesis dumps. On Sat, Mar 16, 2024 at 9:12 PM apache--- via Sbcl-commits < sbc...@li...> wrote: > The branch "master" has been updated in SBCL: > via 97d72107460a03d81f48eff3f9c6683458f05927 (commit) > from f14716915a8cf723edfff81203be5d990c88119a (commit) > > - Log ----------------------------------------------------------------- > commit 97d72107460a03d81f48eff3f9c6683458f05927 > Author: Charles Zhang <cha...@ya...> > Date: Sun Mar 17 02:09:29 2024 +0100 > > Remove misleading comment. > > It only applies to one specific configuration on one specific > architecture, so it seems very bad to write it as if it were a > universal truth. Also it's weird to restate how structs are laid out > in memory here. > --- > src/code/source-location.lisp | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/code/source-location.lisp b/src/code/source-location.lisp > index cc72c3b79..b2256de27 100644 > --- a/src/code/source-location.lisp > +++ b/src/code/source-location.lisp > @@ -13,7 +13,6 @@ > > ;;; A DEFINITION-SOURCE-LOCATION contains two packed fixnums in the > INDICES slot, > ;;; and unless there is a non-nil plist, does not store the plist. > -;;; Packed representation is: header + layout, namestring, indices, > (padding) > (def!struct (definition-source-location > (:constructor %make-basic-definition-source-location > (namestring indices)) > > ----------------------------------------------------------------------- > > > hooks/post-receive > -- > SBCL > > > _______________________________________________ > Sbcl-commits mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-commits > |
From: Arthur M. <art...@li...> - 2024-03-16 10:16:32
|
"Stelian Ionescu" <sio...@cd...> writes: > Some time ago Doug tried replacing sb-thread primitives with FFI calls to pthread_* functions. It didn't pass all tests > but I'm willing to finish it if you agree to replace SBCL's homegrown ones at least on Unix platforms. > The benefits are 1) the libc primitives are interrupt-safe 2) they're fast 3) you don't have to maintain them. > The downsides are 1) a lack of Windows support and 2) sb-thread:mutex-owner > can't be implemented with POSIX. Hi, forgive me for chimming in out of the blue, but more out of curiosity; can I ask if SBCL pthred-win32 implementation and/or could it use if that is not the case already? Do they implement all the functions you need? Their conformance page lists function/struct/defines they inplement: https://sourceforge.net/p/pthreads4w/wiki/Conformance/ I have been looking a bit in runtime, and thus far I see only pure win32 functions (GetTrheadID, etc ...). I wonder if it would be possible to use posix-win32 library on Windows, and also, a bit regression, what would be needed to make sbcl C runtime compile with msvc compiler and skip mingw/msys2 runtimes, at least fot the C part. I understand sb-unix needs some posix funcitons which are not easily available in Windows OS. Best regards /arthur > Cheers, > Stelian Ionescu > > On Thu, Mar 14, 2024 at 4:32 PM Stas Boukarev <sta...@gm...> wrote: > > I'm vacillating between keeping or removing deadlock detection. But I can't really measure any performance > difference, if anything, sometimes they make things faster, as it spins some time in user space for a lock to > get freed in that time. > > I figured you might be. > For my part I'm trying to get rid of pile of I-don't-know-what which has N different ways to expand > thread:with-mutex in the hope of making it faster than sb-thread:with-mutex. > With #+ultrafutex, nothing is faster than sb-thread:with-mutex, and nobody needs the option to elide the > unwind-protect for the sake of speed. > The other problem is that anything that hand-rolls its own logic via grab-mutex totally defeats the > enhancement you get with #+ultrafutex. > > > > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > -- > Stelian Ionescu > > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Douglas K. <do...@go...> - 2024-03-15 13:53:28
|
It's this: - (setf (compiled-debug-var-symbol (svref vars i)) - (symbolicate! #.(find-package "SB-DEBUG") "ARG-" - (format nil "~V,'0D" width i)))))) + (setf (compiled-debug-var-name (svref vars i)) + (format nil "ARG-~V,'0D" width i))))) Symbols also go to the heap, and make-symbol ensures that the string gets reallocated on the heap if it wasn't. So this string is in the arena, the debug-var itself isn't I'll probably stick a possibly-base-stringize-to-heap on there and check that it fixes the problem |
From: Robert S. <rj...@fd...> - 2024-03-15 12:53:07
|
Douglas Katzman <do...@go...> wrote: > Do we have x86-64 systems that don't support #+sb-futex? That's the > reason for no STATE slot in the mutex structure. I'd think they all > support #+sb-futex by now NetBSD doesn't have futexes. |
From: Christophe R. <cs...@ca...> - 2024-03-15 10:56:12
|
Hi all, The arrangements for the SBCL25 workshop in Vienna are firming up, and I expect registration to open soon. In the meantime, the workshop has a minimal web page at <https://sbcl.org/sbcl25/> with some (hopefully) helpful local information. All attendees will be welcome to give lightning-style short talks about sbcl-related things, either directly related to activities at the workshop, or more general. But if anyone on this list would like to propose a longer-form talk with space for more detail, now is the time to get in touch! I'd suggest thinking in terms of about 30-40 minutes, and an audience made up of people already aware of at least some detail of SBCL (and definitely Common Lisp, etc.) -- so little introduction needed on that side, and plenty of scope for getting into the nitty gritty detail. If you'd like to propose such a talk, please send me a short proposal as soon as reasonably possible. I look forward to seeing many of you in person in Vienna, Best, Christophe |
From: Charles Z. <cha...@ya...> - 2024-03-15 10:11:38
|
Looks like you’re right that it’s the larger commit that caused this assertion. I don’t know enough about arenas to know why that would happen though, especially since it doesn’t look like i touched anything that looks like ensure-list-to-heap or changed any allocation pattern specifically to do with debug var structures? Am Freitag, März 15, 2024, 4:33 AM schrieb Douglas Katzman <do...@go...>: Some change along the lines of your current work - probably the large one before this - causes debug vars to be allocated in an arena, failing the assertion thusly:(I'll try to find it myself but might ask for help.) ::: UNEXPECTED-FAILURE :DEBUG-DATA-FORCE-TO-HEAP due to SIMPLE-ERROR: "The assertion (NULL (C-FIND-HEAP->ARENA A)) failed with (C-FIND-HEAP->ARENA A) = (#<SB-DI::COMPILED-DEBUG-VAR SB-PCL:ARG-0 0 {10013A5243}> #<SB-DI::COMPILED-DEBUG-VAR SB-PCL:ARG-0 0 {1001383313}> |