From: Cyrus H. <ch...@bo...> - 2005-05-18 17:58:01
Attachments:
sbcl-768m-dynamic-space-20050518.patch
|
Dear sbcl-devel, I've been using the following patch with a 768M heap for a few weeks on OS X 10.4 and 10.4.1 (for a day anyway) and everything seems to work fine. This patch enables me to work with very large arrays (big images and matrices mostly) and I would like to see it merged into the main trunk. I've attached the patch but since it's short I've included it here as well. The summary of the changes are: 1. Moved the linkage table to #x0a00 0000 -- #x0b00 0000 2. Moved dynamic-0-space to #x1000 0000 -- # x3fff f000 3. Moved dynamic-1-space to #x4000 0000 -- # x6fff f000 4. moved dnyamic-space to match the new dynamic-0-space If anyone has suggestions for better values or reasons why these are suboptimal, I'd love to hear them. Thanks! Cyrus Index: sbcl/src/compiler/ppc/parms.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/compiler/ppc/parms.lisp,v retrieving revision 1.19 diff -u -r1.19 parms.lisp --- sbcl/src/compiler/ppc/parms.lisp 11 Mar 2005 17:10:10 -0000 1.19 +++ sbcl/src/compiler/ppc/parms.lisp 18 May 2005 17:49:34 -0000 @@ -93,19 +93,19 @@ ;;; FIXME: this is a gross violation of OAOO, done purely to support ;;; the #define of DYNAMIC_SPACE_SIZE in validate.c -- CSR, 2002-02-25 ;;; (these numbers should match dynamic-0-*) -(def!constant dynamic-space-start #x40000000) -(def!constant dynamic-space-end #x47fff000) +(def!constant dynamic-space-start #x10000000) +(def!constant dynamic-space-end #x3ffff000) ;;; nothing _seems_ to be using these addresses -(def!constant dynamic-0-space-start #x40000000) -(def!constant dynamic-0-space-end #x47fff000) -(def!constant dynamic-1-space-start #x48000000) -(def!constant dynamic-1-space-end #x4ffff000) +(def!constant dynamic-0-space-start #x10000000) +(def!constant dynamic-0-space-end #x3ffff000) +(def!constant dynamic-1-space-start #x40000000) +(def!constant dynamic-1-space-end #x6ffff000) #!+darwin (progn - (def!constant linkage-table-space-start #x50000000) - (def!constant linkage-table-space-end #x51000000) + (def!constant linkage-table-space-start #x0a000000) + (def!constant linkage-table-space-end #x0b000000) (def!constant linkage-table-entry-size 16)) ;;;; Other miscellaneous constants. |
From: Nikodemus S. <nik...@ra...> - 2005-05-18 18:12:26
Attachments:
sbcl-768m-dynamic-space-20050518.patch
|
On Wed, 18 May 2005, Cyrus Harmon wrote: > I've been using the following patch with a 768M heap for a few weeks on OS X > 10.4 and 10.4.1 (for a day anyway) and everything seems to work fine. This Good to hear. Are the spaces the same as in the earlier one you sent a few weeks back? > patch enables me to work with very large arrays (big images and matrices > mostly) and I would like to see it merged into the main trunk. I've attached I've been meaning to merge this (well, the earlier one at any rate), but it's been stuck on my queue, and I haven't had the time to either build or test it yet. ...but I will get around to it in a week on the outside unless someone gets there first. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Cyrus H. <ch...@bo...> - 2005-05-18 18:34:49
|
Yes, the spaces are the same as what I sent a week ago, although that patch also includes the code for computing current_dynamic_space_end and modifications to room. I'm happy to separate out that part and resubmit it is its own patch if that would help (and that code also needs to be tested on non-PPC platforms as well). [As an aside, the motivation for pushing this patch through is that I'd like to package up some code for dealing with Nikon NEF (raw) files and it requires a big dynamic space to work with images from the Nikon D2X.] Didn't mean to rush you, but I wanted to make sure that the patch wasn't so uninteresting that it was summarily dismissed without comment. :-) Thanks again, Cyrus On May 18, 2005, at 11:12 AM, Nikodemus Siivola wrote: > Good to hear. Are the spaces the same as in the earlier one you > sent afew weeks back? ... > I've been meaning to merge this (well, the earlier one at any > rate), butit's been stuck on my queue, and I haven't had the time > to either build > or test it yet. ...but I will get around to it in a week on the > outside > unless someone gets there first. |
From: Nikodemus S. <nik...@ra...> - 2005-05-18 18:45:10
|
On Wed, 18 May 2005, Cyrus Harmon wrote: > Yes, the spaces are the same as what I sent a week ago, although that patch > also includes the code for computing current_dynamic_space_end and > modifications to room. I'm happy to separate out that part and resubmit it is Oh yes. I'd quite forgotten about that additional bit. Actually it was probably one of the reasons why nothing happened yet, as on seeing it my first thought was, "I need to think about this: seems like we should be able to do it from the current setup." I guess the moral here is that small orthogonal patches are preferred and tend to be dealt with faster. ;-) > Didn't mean to rush you, but I wanted to make sure that the patch wasn't so > uninteresting that it was summarily dismissed without comment. :-) Nono. You're quite right in following up on this -- this is as it should be, imo. (And I think a few weeks is a sensible interval to wait as opposed to a few days or few months.) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2005-05-24 20:15:11
|
Cyrus Harmon writes: > I've been using the following patch with a 768M heap for a few weeks > on OS X 10.4 and 10.4.1 (for a day anyway) and everything seems to > work fine. This patch enables me to work with very large arrays (big > images and matrices mostly) and I would like to see it merged into > the main trunk. I've attached the patch but since it's short I've > included it here as well. I posted a patch for a larger heap on OS X some time ago, but I didn't push for it to be merged because it does have some downsides. On my system (640 MB of memory), this seemed to cause an overall slowdown. I would suggest moving the spaces, but using a smaller (256 MB?) heap by default, and putting a comment in ppc/parms.lisp stating where you can safely extend the dynamic-0- and dynamic-1-spaces to. |
From: Nikodemus S. <nik...@ra...> - 2005-05-25 12:05:24
|
On Tue, 24 May 2005, Thomas F. Burdick wrote: > I posted a patch for a larger heap on OS X some time ago, but I didn't > push for it to be merged because it does have some downsides. On my > system (640 MB of memory), this seemed to cause an overall slowdown. > I would suggest moving the spaces, but using a smaller (256 MB?) heap > by default, and putting a comment in ppc/parms.lisp stating where you > can safely extend the dynamic-0- and dynamic-1-spaces to. Thanks for the heads up. I was planning to merge this after 0.9.1, but I'll run some benchmarks first. Instead od making this a build-option, it might also pay to incorporate this with the --dynamic-space-size patch by (?) David Lichtblau. By the by: for the benefit of those not following sbcl-commits religiously in preparation for merging the callback stuff SBCL can now directly allocate specialized vectors to static-space. See SB-INT:MAKE-STATIC-VECTOR. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Nikodemus S. <nik...@ra...> - 2005-05-29 15:50:45
|
On Wed, 18 May 2005, Cyrus Harmon wrote: > I've been using the following patch with a 768M heap for a few weeks on OS X > 10.4 and 10.4.1 (for a day anyway) and everything seems to work fine. This Thank you. Merged in SBCL 0.9.1.5. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |