(> SPEED DEBUG). (This is an incompatible change because there are
programs which relied on the old CMU-CL-style behavior to optimize
away their unbounded recursion which will now die of stack overflow.)
+ * minor incompatible change: The default BYTES-CONSED-BETWEEN-GCS
+ for non-GENCGC systems has been increased to 20M (since that
+ seems much closer to the likely performance optimum for modern
+ systems than the old 4M value was)
* SBCL runs on SPARC systems now. (thanks to Christophe Rhodes' port
of CMU CL's support for SPARC, and various endianness and other
SBCL portability fixes due to Christophe Rhodes and Dan Barlow)
;;;
;;; Unlike CMU CL, we don't export this variable. (There's no need to,
;;; since our BYTES-CONSED-BETWEEN-GCS function is SETFable.)
-(defvar *bytes-consed-between-gcs* (* 4 (expt 10 6)))
+(defvar *bytes-consed-between-gcs*
+ #+gencgc (* 4 (expt 10 6))
+ ;; Stop-and-copy GC is really really slow when used too often. CSR
+ ;; reported that even on his old 64 Mb SPARC, 20 Mb is much faster
+ ;; than 4 Mb when rebuilding SBCL ca. 0.7.1. For modern machines
+ ;; with >> 128 Mb memory, the optimum could be significantly more
+ ;; than this, but at least 20 Mb should be better than 4 Mb.
+ #-gencgc (* 20 (expt 10 6)))
(declaim (type index *bytes-consed-between-gcs*))
;;;; GC hooks
;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.
-;;; GC tuning has little effect on the x86 due to the generational
-;;; collector. For the older stop & copy collector, it assuredly
-;;; does. GC time is proportional to the amount of non-garbage
-;;; needing collection and copying; when the application involved is
-;;; the SBCL compiler, it doesn't take any longer to collect 20 Mb than
-;;; to collect 2 Mb. -dan, 20000819
-;;;
-;;; Actually, tweaking *BYTES-CONSED-BETWEEN-GCS* to 20Mb instead of
-;;; the default 2 seemed to make SBCL rebuild O(25%) faster on my 256
-;;; Mb K6/3, so I think it does have some effect on X86/GENCGC. I
-;;; haven't looked into why this would be, though. Also, I'm afraid
-;;; that using 20Mb here might be unfriendly to people using more-reasonable
-;;; machines (like old laptops with 48Mb of memory..) so I've
-;;; suppressed this tweak except for Alpha. -- WHN 2001-05-11
-#+(and sbcl alpha) ; SBCL/Alpha uses stop-and-copy, and Alphas have lotso RAM.
-(progn
- (sb-ext:gc-off)
- (setf (sb-ext:bytes-consed-between-gcs) (* 20 (expt 10 6)))
- (sb-ext:gc-on)
- (sb-ext:gc))
-
;;; SB-COLD holds stuff used to build the initial SBCL core file
;;; (including not only the final construction of the core file, but
;;; also the preliminary steps like e.g. building the cross-compiler
\f
;;;; general warm init compilation policy
-;;; Without generational GC, GC gets really slow unless we collect in
-;;; large chunks. For small chunks, efficiency tends to grow roughly
-;;; linearly with chunk size. Later we hit diminishing returns as we
-;;; approach the total amount of RAM we use, or we can even get into
-;;; performance trouble by clobbering cache and VM systems too hard.
-;;; But modern machines tend to think of 20 Mb as a moderate amount of
-;;; memory, and it's of the same order of magnitude as the amount of
-;;; RAM we need for the build, so it seems like a plausible chunk size.
-#-gencgc
-(progn
- (sb!ext:gc-off)
- (setf (sb!ext:bytes-consed-between-gcs) (* 20 (expt 10 6)))
- (sb!ext:gc-on))
-
(proclaim '(optimize (compilation-speed 1)
(debug #+sb-show 2 #-sb-show 1)
(inhibit-warnings 2)
;;; compiler warning instead of a failure to compile.)
(defun foo ()
(catch 0 (print 1331)))
+\f
+;;;; tests not in the problem domain, but of the consistency of the
+;;;; compiler machinery itself
+(in-package "SB-C")
+
+;;; Hunt for wrong-looking things in fundamental compiler definitions,
+;;; and gripe about them.
+;;;
+;;; FIXME: It should be possible to (1) repair the things that this
+;;; code gripes about, and then (2) make the code signal errors
+;;; instead of just printing complaints to standard output, in order
+;;; to prevent the code from later falling back into disrepair.
+(defun grovel-results (function)
+ (dolist (template (fun-info-templates (info :function :info function)))
+ (when (template-more-results-type template)
+ (format t "~&Template ~A has :MORE results, and translates ~A.~%"
+ (template-name template)
+ function)
+ (return nil))
+ (when (eq (template-result-types template) :conditional)
+ ;; dunno.
+ (return t))
+ (let ((types (template-result-types template))
+ (result-type (fun-type-returns (info :function :type function))))
+ (cond
+ ((values-type-p result-type)
+ (do ((ltypes (append (args-type-required result-type)
+ (args-type-optional result-type))
+ (rest ltypes))
+ (types types (rest types)))
+ ((null ltypes)
+ (unless (null types)
+ (format t "~&More types than ltypes in ~A, translating ~A.~%"
+ (template-name template)
+ function)
+ (return nil)))
+ (when (null types)
+ (unless (null ltypes)
+ (format t "~&More ltypes than types in ~A, translating ~A.~%"
+ (template-name template)
+ function)
+ (return nil)))))
+ ((eq result-type (specifier-type nil))
+ (unless (null types)
+ (format t "~&Template ~A returns values for function ~A with RESULT-TYPE NIL.~%"
+ (template-name template)
+ function)
+ (return nil)))
+ ((/= (length types) 1)
+ (format t "~&Template ~A isn't returning 1 value for ~A.~%"
+ (template-name template)
+ function)
+ (return nil))
+ (t t)))))
+(defun identify-suspect-vops (&optional (env (first
+ (last *info-environment*))))
+ (do-info (env :class class :type type :name name :value value)
+ (when (and (eq class :function) (eq type :type))
+ ;; OK, so we have an entry in the INFO database. Now, if ...
+ (let* ((info (info :function :info name))
+ (templates (and info (fun-info-templates info))))
+ (when templates
+ ;; ... it has translators
+ (grovel-results name))))))
+(identify-suspect-vops)
+\f
;;; success
(quit :unix-status 104)
;;; for internal versions, especially for internal versions off the
;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.7.1.20"
+"0.7.1.21"