Memory settings
Locked
 
|
Hi Folks -
I spent the last two days in a bit of optimization mode for Qwaq Forums and one of the things that I found is that the memory settings Squeak ships with by default are abysmal for anything resembling 21st century memory sizes and processor speeds. I'm interested in an exchange with people who have been tweaking these settings to see what they come up with. For Forums, I have found the following to be significant: * IGC counts: I have found that I could speed up forums by about 30% simply by reducing the number of IGCs and tenures via the following settings: Smalltalk vmParameterAt: 5 put: 40000. "default: 4000" Smalltalk vmParameterAt: 6 put: 10000. "default: 2000" The effect of these changes is that we only do 1/10th of the frequency of incremental GCs. * Total memory sizes: I have found that insufficient free space is a major source of slowdowns (factor of 2-3). This can be avoided by biasing the VM to grow instead of collect (thanks John!) and ensure that there is enough headroom at all times: Smalltalk gcBiasToGrow: true. "default: false" Smalltalk gcBiasToGrowLimit: 8*1024*1024. "default: n/a" What I'm curious about is what settings other people with "21st century loads" on their applications have found to make a difference. The above seem to work out well for forums, significantly increasing the frame rate on small machines (up to 30%) but without having individual IGCs to be too slow for real-time processing (voice chat and rendering in our cases). Cheers, - Andreas |
|
|
Sophie has a SophieMemoryPolicy instance that also checks for
abnormal number of root related scans and forces a tenure. This fixes the problem when a large slot based object starts being scanned as part of the root lookup logic. (statMarkCount ) > (statAllocationCount*2) ifTrue: [[Smalltalk forceTenure] on: Error do: [:ex | ]]. "Tenure if we think too much root table marking is going on" It also btw had code in SophieMemoryPolicy >>calculateGoals that adjusted Smalltalk vmParameterAt: 5 and 6 to target a 1 ms incremental GC time. A singleton instance wakes up every 5 seconds and peeks at the GC statistical data. However I've not been doing this adjustment. I used Smalltalk gcBiasToGrowLimit: 32MB since that seemed to be a reasonable value for doing minor amounts of user interaction when I last looked at it, and I just doubled the vmParms 5/6 which as you point out is inadequate. I'll lastly note you must apply JMM-fixBiasToGrow.1.cs to your VMMaker image to ensure the "growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock)." has the missing period otherwise as noted earlier this year then the entire statement is dropped by SLANG and then causes the bias to grow logic to work incorrectly. I don't believe Tim has added this fix to VMMaker yet? On May 17, 2007, at 10:59 PM, Andreas Raab wrote: > Hi Folks - > > I spent the last two days in a bit of optimization mode for Qwaq > Forums and one of the things that I found is that the memory > settings Squeak ships with by default are abysmal for anything > resembling 21st century memory sizes and processor speeds. I'm > interested in an exchange with people who have been tweaking these > settings to see what they come up with. For Forums, I have found > the following to be significant: > > * IGC counts: I have found that I could speed up forums by about > 30% simply by reducing the number of IGCs and tenures via the > following settings: > Smalltalk vmParameterAt: 5 put: 40000. "default: 4000" > Smalltalk vmParameterAt: 6 put: 10000. "default: 2000" > The effect of these changes is that we only do 1/10th of the > frequency of incremental GCs. > > * Total memory sizes: I have found that insufficient free space is > a major source of slowdowns (factor of 2-3). This can be avoided by > biasing the VM to grow instead of collect (thanks John!) and ensure > that there is enough headroom at all times: > Smalltalk gcBiasToGrow: true. "default: false" > Smalltalk gcBiasToGrowLimit: 8*1024*1024. "default: n/a" > What I'm curious about is what settings other people with "21st > century loads" on their applications have found to make a > difference. The above seem to work out well for forums, > significantly increasing the frame rate on small machines (up to > 30%) but without having individual IGCs to be too slow for real- > time processing (voice chat and rendering in our cases). > > Cheers, > - Andreas > -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
|
Hi John -
John M McIntosh wrote: > It also btw had code in SophieMemoryPolicy >>calculateGoals that > adjusted Smalltalk vmParameterAt: 5 and 6 to target a 1 ms incremental > GC time. A singleton instance wakes up every 5 seconds and peeks at the > GC statistical data. However I've not been doing this adjustment. I'm actually more shooting for 5ms IGC times but having a process which tweaks these parameters is an interesting idea too. > I used Smalltalk gcBiasToGrowLimit: 32MB since that seemed to be a > reasonable value for doing minor amounts of user interaction when I last > looked at it, and I just doubled the vmParms 5/6 which as you point out > is inadequate. Right. Our allocation patterns are more agressive than your average Squeak image though, so simply doubling it was not enough (but even increasing it by ten didn't have any ill effects on IGC speed). > I'll lastly note you must apply JMM-fixBiasToGrow.1.cs to your VMMaker > image to ensure the "growSize := growHeadroom*3/2 - (self sizeOfFree: > freeBlock)." has the missing period > otherwise as noted earlier this year then the entire statement is > dropped by SLANG and then causes the bias to grow logic to work > incorrectly. I don't believe Tim has added this > fix to VMMaker yet? Oh! I hadn't noticed that. I'll fix it in my copy right away, thanks for pointing it out. Cheers, - Andreas |
|
|
On May 18, 2007, at 8:25 AM, Andreas Raab wrote: > Hi John - > > John M McIntosh wrote: >> It also btw had code in SophieMemoryPolicy >>calculateGoals that >> adjusted Smalltalk vmParameterAt: 5 and 6 to target a 1 ms >> incremental GC time. A singleton instance wakes up every 5 seconds >> and peeks at the GC statistical data. However I've not been doing >> this adjustment. > > I'm actually more shooting for 5ms IGC times but having a process > which tweaks these parameters is an interesting idea too. Ok, I had thought you usually were thinking of 1ms igc times because that means 1ms accuracy Delay pops. If you target a 5ms won't you risk Delays being off by 5ms? Also the VM uses these grow/shrink values by default. growHeadroom := 4*1024*1024. "four megabyte of headroom when growing" shrinkThreshold := 8*1024*1024. "eight megabyte of free space before shrinking" I don't think anyone overrides the values, say like Smalltalk vmParameterAt: 25 put: 24*1024*1024. "grow headroom" Smalltalk vmParameterAt: 24 put: 48*1024*1024. "shrink threshold" In the Memory policy task you might look at how much grow/shrinking is going on to avoid excessive grow/shrink actions based on your choices for bias to grow. -- ======================================================================== === John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |