From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Stack calibration Date: Fri, 12 Sep 2008 22:47:17 +0200 Message-ID: <87hc8lw0q2.fsf_-_@gnu.org> References: <47B2A8DF.9070004@tammer.net> <87tzkd8bvz.fsf@gnu.org> <87ejbh8ben.fsf@gnu.org> <47B2D88F.1040505@tammer.net> <87ir0tvx6e.fsf@inria.fr> <87wsp83807.fsf@ossau.uklinux.net> <871w7fore8.fsf@gnu.org> <66e540fe0802140226k3cd96c46x286ac753bbb2b8b7@mail.gmail.com> <87ejbfg4pr.fsf@gnu.org> <66e540fe0802140339n2121e1d9y85fcc9f019d8be0f@mail.gmail.com> <87prukog9w.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1221252493 1731 80.91.229.12 (12 Sep 2008 20:48:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Sep 2008 20:48:13 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Sep 12 22:49:04 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KeFZe-0000vt-Ck for guile-devel@m.gmane.org; Fri, 12 Sep 2008 22:49:02 +0200 Original-Received: from localhost ([127.0.0.1]:50582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeFYc-0008Ew-PX for guile-devel@m.gmane.org; Fri, 12 Sep 2008 16:47:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KeFYG-00085C-3w for guile-devel@gnu.org; Fri, 12 Sep 2008 16:47:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KeFYF-00084s-E4 for guile-devel@gnu.org; Fri, 12 Sep 2008 16:47:35 -0400 Original-Received: from [199.232.76.173] (port=46347 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KeFYF-00084p-A4 for guile-devel@gnu.org; Fri, 12 Sep 2008 16:47:35 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:49572 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KeFYE-0008Rb-ID for guile-devel@gnu.org; Fri, 12 Sep 2008 16:47:35 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KeFY9-0006Ca-Dz for guile-devel@gnu.org; Fri, 12 Sep 2008 20:47:29 +0000 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Sep 2008 20:47:29 +0000 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Sep 2008 20:47:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 119 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 27 Fructidor an 216 de la =?iso-8859-1?Q?R=E9volutio?= =?iso-8859-1?Q?n?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i686-pc-linux-gnu User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) Cancel-Lock: sha1:yaCsctu0uazWYo3qPPMrNxR11Ns= X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7679 Archived-At: Hi! Neil Jerram writes: > "Mikael Djurfeldt" writes: > >> I was thinking about inserting code which actually *measures* the size >> of frames during startup. This could be done, for example, by >> introducing a primitive which uses the internal stack measuring >> functions. One could use this primitive to measure how much stack >> space some code sample uses. By our knowledge of how many evaluator >> stack frames this code sample uses, we can compute a reliable estimate >> for the running instance of Guile. > > Below is a proposed patch to do this. When and if this gets deployed, > the third arg to %calibrate-stack-depth would be removed, so that it > doesn't generate any output. But for now it's interesting to see what > results people on various OSs get. That's the second important thing that should go in 1.8.6 IMO. A few notes. > --- ice-9/boot-9.scm 1 Sep 2007 17:11:00 -0000 1.356.2.10 > +++ ice-9/boot-9.scm 25 Feb 2008 21:45:44 -0000 > @@ -2289,6 +2289,14 @@ > (print-options print-enable print-disable) > (print-set!))) > > +;;; Stack depth calibration, for the 'stack debug option. > + > +(let ((x (%get-stack-depth))) > + (let loop ((count 10)) > + (if (zero? count) > + (%calibrate-stack-depth x (%get-stack-depth) 'report) > + (cons count (loop (- count 1)))))) > + [...] > +SCM_DEFINE (scm_sys_calibrate_stack_depth, "%calibrate-stack-depth", 2, 1, 0, > + (SCM d1, SCM d2, SCM debugp), > + "Calibrate linear transformation for stack depth limit checking.") > +#define FUNC_NAME s_scm_sys_calibrate_stack_depth > +{ > + /* x1 and x2 are the stack depth values that we get on a Debian > + GNU/Linux ia32 system - which we take as our canonical system. > + y1 and y2 are the values measured on the system where Guile is > + currently running. */ > + int x1 = 170, x2 = 690, y1, y2; These results are dependent on what the loop in `boot-9.scm' does. Thus, it'd be nicer if they weren't that far away from it. It might be worth mentioning the GCC version and optimization level that led to this result. Also, `x1' and `x2' can be made "static const" or some such. > + SCM_VALIDATE_INT_COPY (1, d1, y1); > + SCM_VALIDATE_INT_COPY (2, d2, y2); > + > + calibrated_m = ((double) (y2 - y1)) / (x2 - x1); > + calibrated_c = ((double) y2) - calibrated_m * x2; Shouldn't it be: calibrated_c = y1 - x1; Also, the computation of `calibrated_m' needs more casts to `double' I think. > + if (scm_is_true (debugp) && !SCM_UNBNDP (debugp)) > + { > + scm_puts (";; Stack calibration: (x1 x2 y1 y2 m c) = ", > + scm_current_output_port ()); > + scm_write (scm_list_n (scm_from_int (x1), scm_from_int (x2), > + d1, d2, > + scm_from_double (calibrated_m), > + scm_from_double (calibrated_c), > + SCM_UNDEFINED), > + SCM_UNDEFINED); > + scm_newline (SCM_UNDEFINED); > + } Could it be moved to a `%print-stack-calibration' function that we'd use for troubleshooting? > +void > +scm_calculate_stack_limit () > +{ > + scm_stack_limit = (int) (calibrated_m * SCM_STACK_LIMIT + calibrated_c); > +} How about entirely removing the startup overhead by computing the calibration factors only once, at installation time? This would mean: 1. Compile all of Guile with the default calibration factors (m = 1 and c = 0). 2. Run a Scheme script that computes `m' and `c' and produces, say, `calibration.h', which is included by `stackchk.c'. Both the computation and the reference stack depths (`x1' and `x2' above) would live in this script, which is clearer IMO. 3. Invoke `make' recursively, which should rebuild libguile with the appropriate calibration factor (typically, only `stackchk.lo' would need to be recompiled). Would you like to do something like this? Also, the on-line and Texi documentation of `eval-options' must be updated to specify that the stack depth unit is "abstract" and (hopefully) portable across platforms. Thanks, Ludo'.