From: J. K. C. <J.k...@co...> - 2010-01-26 17:01:27
|
Thought I'd give you some feedback in the form of data on a recent jump in core size. I run a hunchentoot webserver on a (very) small dedicated server. That machine is running SBCL 1.0.31.28 and generates a core that is 43.2M I recently upgraded SBCL at home to 1.0.34.7. When I built the same webserver on that machine the core is now 74.2M. The dedicated server is a P4. The home machine is an AMD-64, if that makes any difference. I don't recall the previous version I was running on the AMD-64, but believe it was around 1.0.31 and it generated a core size for the webserver that was about the same as the dedicated machine at that time. It does seem to compile much faster though :) Regards. --Jeff Cunningham |
From: David O. <dso...@fu...> - 2010-01-27 06:22:27
|
On Tue, 26 Jan 2010, J. K. Cunningham wrote: > Thought I'd give you some feedback in the form of data on a recent > jump in core size. I run a hunchentoot webserver on a (very) small > dedicated server. That machine is running SBCL 1.0.31.28 and > generates a core that is 43.2M > > I recently upgraded SBCL at home to 1.0.34.7. When I built the same > webserver on that machine the core is now 74.2M. > > The dedicated server is a P4. The home machine is an AMD-64, if that > makes any difference. I don't recall the previous version I was > running on the AMD-64, but believe it was around 1.0.31 and it > generated a core size for the webserver that was about the same as > the dedicated machine at that time. I have consistently seen such differences in core sizes between x86 and x86-64, since I started using both architectures over a year ago, so I don't think it's related to changes introduced by various versions. -David |
From: Charlie M. <cha...@gm...> - 2010-01-27 14:18:12
|
Boinkmarks seems to support the core size claim along with speed regressions in TAK family, FPRINT-UGLY, and a couple others. http://sbcl.boinkor.net/boinkmarks/index View it with HTML5 capable browser. |
From: Nathan F. <fr...@gm...> - 2010-01-27 15:28:02
|
On Wed, Jan 27, 2010 at 9:17 AM, Charlie McMackin <cha...@gm...> wrote: > Boinkmarks seems to support the core size claim along with speed > regressions in TAK family, FPRINT-UGLY, and a couple others. > http://sbcl.boinkor.net/boinkmarks/index As a wild guess, I'm going to guess that this was due to 1.0.33.26, which turned on threads on x86oid Linux by default. Access to special variables becomes somewhat more expensive in thread-enabled builds. This hypothesis doesn't explain everything (SEARCH-SEQUENCE on x86, for instance), but it's a good first approximation. -Nathan |
From: J. K. C. <J.k...@co...> - 2010-01-27 16:13:45
|
On Wed, 2010-01-27 at 10:20 -0500, Nathan Froyd wrote: > On Wed, Jan 27, 2010 at 9:17 AM, Charlie McMackin <cha...@gm...> wrote: > > Boinkmarks seems to support the core size claim along with speed > > regressions in TAK family, FPRINT-UGLY, and a couple others. > > http://sbcl.boinkor.net/boinkmarks/index > > As a wild guess, I'm going to guess that this was due to 1.0.33.26, > which turned on threads on x86oid Linux by default. Access to special > variables becomes somewhat more expensive in thread-enabled builds. > > This hypothesis doesn't explain everything (SEARCH-SEQUENCE on x86, > for instance), but it's a good first approximation. > > -Nathan I always built SBCL with threads, so that probably isn't it. Also, to reiterate for David Owen, as I must not have been clear, the earlier AMD-64 core size was about the same (within 1-2M) of the i386 core size. Good to know about the special variable access. Does that include defconstants and defvars or just defparameters? --Jeff |
From: Paul K. <pv...@pv...> - 2010-01-27 16:23:23
|
On 2010-01-27, at 11:13 AM, J. K. Cunningham wrote: > Also, to reiterate for David Owen, as I must not have been clear, the > earlier AMD-64 core size was about the same (within 1-2M) of the i386 > core size. Definitely not. > Good to know about the special variable access. Does that include > defconstants and defvars or just defparameters? Specials, so defvar and defparameter. |
From: Nathan F. <fr...@gm...> - 2010-01-27 16:22:12
|
On Wed, Jan 27, 2010 at 11:13 AM, J. K. Cunningham <J.k...@co...> wrote: > On Wed, 2010-01-27 at 10:20 -0500, Nathan Froyd wrote: >> As a wild guess, I'm going to guess that this was due to 1.0.33.26, >> which turned on threads on x86oid Linux by default. Access to special >> variables becomes somewhat more expensive in thread-enabled builds. > > I always built SBCL with threads, so that probably isn't it. I was suggesting this for the boinkmarks regressions, not your original problem. My apologies for not being clearer. > Also, to reiterate for David Owen, as I must not have been clear, the > earlier AMD-64 core size was about the same (within 1-2M) of the i386 core > size. I find this *very* hard to believe. Just looking at the boinkmarks numbers indicates that core files (the base system, without anything loaded) have *always* been ~13-15MB larger on x86-64. That disparity should remain--and probably will widen--the more stuff you load into your core. I can believe your numbers if you were mistakenly comparing x86 cores *with* your loaded systems to x86-64 cores *without* your loaded systems. But apples-to-apples? No. > Good to know about the special variable access. Does that include > defconstants and defvars or just defparameters? It includes variables defined with DEFVAR or DEFPARAMETER. -Nathan |
From: J. K. C. <J.k...@co...> - 2010-01-28 17:11:04
|
On Wed, 2010-01-27 at 11:22 -0500, Nathan Froyd wrote: > > > Also, to reiterate for David Owen, as I must not have been clear, the > > earlier AMD-64 core size was about the same (within 1-2M) of the i386 core > > size. > > I find this *very* hard to believe. Just looking at the boinkmarks > numbers indicates that core files (the base system, without anything > loaded) have *always* been ~13-15MB larger on x86-64. That disparity > should remain--and probably will widen--the more stuff you load into > your core. I can believe your numbers if you were mistakenly > comparing x86 cores *with* your loaded systems to x86-64 cores > *without* your loaded systems. But apples-to-apples? No. > Comparing apples to apples is what I am trying to do, and you may be correct that I've omitted some difference. Let me try to reconstruct the sequence of events: * A couple months ago it was running Ubuntu 9.10 -i386 on an AMD-64 machine. When I installed that OS I used their SBCL binary to bootstrap my build of your latest snapshot at the time (would have been in November). I am sure I built that with threads. The size of a core loaded with my webserver was in the mid-forty Mb range. * I switched back to AMD-64 when Debian-5 came out. Again, I used their SBCL binary to bootstrap my build of 1.0.34.7. Again, threads were enabled. It was at this point that I noticed the high-seventy Mb sized cores loaded with the web-server. * While I believe I can recall midpoints - post OS change to 64-bits but pre-upgrade to 1.0.34.7 SBCL - where the core sizes were still in the mid-forties, I have none at this point for evidence and my memory isn't sufficiently accurate to bet money on. So where there are demonstrable facts, there were actually two variables: an OS change and an SBCL version change. --Jeff |
From: Nathan F. <fr...@gm...> - 2010-01-28 18:20:52
|
On Thu, Jan 28, 2010 at 12:10 PM, J. K. Cunningham <J.k...@co...> wrote: > On Wed, 2010-01-27 at 11:22 -0500, Nathan Froyd wrote: > I find this *very* hard to believe. Just looking at the boinkmarks > numbers indicates that core files (the base system, without anything > loaded) have *always* been ~13-15MB larger on x86-64. That disparity > should remain--and probably will widen--the more stuff you load into > your core. I can believe your numbers if you were mistakenly > comparing x86 cores *with* your loaded systems to x86-64 cores > *without* your loaded systems. But apples-to-apples? No. > > Comparing apples to apples is what I am trying to do, and you may be correct > that I've omitted some difference. Let me try to reconstruct the sequence of > events: > > * A couple months ago it was running Ubuntu 9.10 -i386 on an AMD-64 machine. > When I installed that OS I used their SBCL binary to bootstrap my build of > your latest snapshot at the time (would have been in November). I am sure I > built that with threads. The size of a core loaded with my webserver was in > the mid-forty Mb range. OK, it sounds like you had a 64-bit CPU and a 32-bit OS running on the machine. Building SBCL would have defaulted to a 32-bit (x86) build, since you can't run a 64-bit SBCL on a 32-bit OS. > * I switched back to AMD-64 when Debian-5 came out. Again, I used their SBCL > binary to bootstrap my build of 1.0.34.7. Again, threads were enabled. It > was at this point that I noticed the high-seventy Mb sized cores loaded with > the web-server. Assuming you mean "switched to a 64-bit OS" when you say "switched back to AMD-64", then an SBCL built here would be a 64-bit (x86-64) SBCL. (You could certainly build a 32-bit SBCL for the 64-bit OS, but it's not the default and requires a bit of fiddling.) You can check what CPU SBCL is compiled for by using (MACHINE-TYPE). If I've understood your timeline correctly, then I think you are comparing apples to oranges wrt core file size. If you wanted to try building a 32-bit SBCL on your Debian-5 machine and see what that weighs in at, that would be helpful--and if that still has a 70+ MB core, then we *do* have a problem. :) -Nathan |