- Pharo-dev - lists.pharo.org

Re: [Pharo-project] about growing streams and allocating buffers

by StÃ©phane Ducasse

> Hi > > I've been doing some performance work lately in Seaside. Long story > short Seaside (and I guess AIDA too) spends of if it's rendering time in > WriteStream (#nextPutAll:, #nextPut:). > > The way WriteStream >> #pastEndPut: behaves is not really ideal for > Seaside. It grows the underlying collection by just enough to > accommodate the argument collection (or 20 which ever is bigger). Now > image the following not very unlikely scenario. You start with a 4k > buffer and put on average a 10 element collection (remember all those > tags are put individually) until you have a 16k response. You allocate > more than a thousand intermediary collections to get there. > What would be better suited for Seaside is doubling the required size. > In the worst case that would mean wasting 50% of memory but it would > make the overhead of creating intermediary collections logarithmic. In > the given example that would take us only three allocations to get there. > Now I do realize there are other applications for Pharo where this > strategy is not ideal and this is not a killer for us. I just wanted to > shed some light and this and ask whether other projects are in a similar > situation. Thanks for the info. Do you have an idea in which case allocating more would be a real problem? Because in VW there were some patterns: turning , into nextPut: to avoid exact the underlying string allocation. preallocation OrderedCollection new: instead of relying on its growing behavior. Final question May be we should be able to plug the stream behavior we want. Like that seaside people can get the speed out of it. I think that having fast web app is important. > > To get a feel how allocation limited Seaside is: avoiding one allocation > of a 16k ByteArray per request can make a difference in throughput > between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP > Components"). If anybody knows a way to make allocation of large young > space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd > like to hear it. > > Cheers > Philippe > >

Jan. 1, 2011

[Pharo-project] about growing streams and allocating buffers

by Philippe Marschall

Hi I've been doing some performance work lately in Seaside. Long story short Seaside (and I guess AIDA too) spends of if it's rendering time in WriteStream (#nextPutAll:, #nextPut:). The way WriteStream >> #pastEndPut: behaves is not really ideal for Seaside. It grows the underlying collection by just enough to accommodate the argument collection (or 20 which ever is bigger). Now image the following not very unlikely scenario. You start with a 4k buffer and put on average a 10 element collection (remember all those tags are put individually) until you have a 16k response. You allocate more than a thousand intermediary collections to get there. What would be better suited for Seaside is doubling the required size. In the worst case that would mean wasting 50% of memory but it would make the overhead of creating intermediary collections logarithmic. In the given example that would take us only three allocations to get there. Now I do realize there are other applications for Pharo where this strategy is not ideal and this is not a killer for us. I just wanted to shed some light and this and ask whether other projects are in a similar situation. To get a feel how allocation limited Seaside is: avoiding one allocation of a 16k ByteArray per request can make a difference in throughput between 10 Mbyte/s and 30 Mbyte/s (see "[Progress Report] Zinc HTTP Components"). If anybody knows a way to make allocation of large young space objects faster (Set GC Bias to Grow?, #vmParameterAt:put:?) I'd like to hear it. Cheers Philippe

Jan. 1, 2011

[Pharo-project] [OT] questions answered on stackexchange: Why do good programmers have ugly websites?

by Igor Stasenko

Funny. Really funny. Especially this one: " Just be thankful there's more than just a command-prompt. " I hope that with Pharo we have enough 'bad' programmers, which can make good designs.. otherwise we're in trouble :) -- Best regards, Igor Stasenko AKA sig.

Jan. 1, 2011

Re: [Pharo-project] Issue 3500 in pharo: Create deprecated13

by Igor Stasenko

looks fine as to me. On 1 January 2011 12:35, <pharo(a)googlecode.com> wrote: > Status: Fixed > Owner: stephane.ducasse > > New issue 3500 by stephane.ducasse: Create deprecated13 > http://code.google.com/p/pharo/issues/detail?id=3500 > > We should create a package deprecated13 as one of the first move in 1.3. > > > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 1, 2011

Re: [Pharo-project] new Cog VMs

by Philippe Marschall

On 31.12.2010 03:02, Eliot Miranda wrote: > > > > > Hi All, > > I've released a new version of Cog that has a substantially > improved code generator along the lines of Peter Deutsch's HPS > (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple > tecnique to identify constant references in bytecode and to support a > register-based calling convention. While this does produce faster code > it tends to accelerate low-level code much more than high-level code as > you can see by the following benchmarks: > > SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 > StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 > 192 - 691 / 6.91 -72% > > SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; > 64769127 sends/sec' > StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; > 128157989 sends/sec' > 931756141 - 753495217 / 7534952.17 -24% > 128157989 - 64769127 / 647691.27 -98% > > SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no > transcript > StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no > transcript) > 43406 - 47013 / 470.13 -7.67234594686576 > > The status of this code is essentially beta. The test suite runs the > same on the new code generator as on the old, but I think there are > still bugs because I get the occasional transient error. I am therefore > very interested in any reproducible errors you can find. > > The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a > few other important changes: > > - a bug fix to bytecode<->native pc mappng that produced incorrect > results for methods containing blocks with ^-returns in them. One > symptom is incorrect highlighting of the pc in the debugger, althoguh > symptoms could be much serious. > > - jitting interpreted methods on backward branches. Currently any > interpreted method that performs more than 20 backward branches will be > considered for JIT compilation and if it is suitable (default, <= 60 > literals) will be compiled to native code. > > - new callback support. I need to commit some changes to the Alien > package to provide access to this but essentially the VM's callback > support is now able to be ported to architectures with register-based > calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the > Alien code released soon, and to back-port the changes to the standard > VM before the end of the holiday. > > One thing that is still /not/ fixed is the lack of a SoundPlugin on > win32. Apologies. I'll try and get a fix for this before the end of > the holidays too, but time might be too tight. There are other > priorities such as harmonising the standard and Cog VMs for the 4.2 release. I gave it a short test with the latest Seaside. First the good news, I seem to get an average performance improvement of about 10%. However in some very rare cases the temps seem to be mixed up the very first time a method is executed and fine afterwards. For example in the method below when the div 'bench' is created. The very first time it is executed #div is sent to a BlockClosure, the next time it is fine. This is reproducible, if I recompile the package or restart the image it happens again the first time and is fine afterwards. I don't know how I can provide more information but I could upload the image somewhere. renderInline: aBlock factor: factor key: key on: html | startTime endTime count backColor anAssociation title referenceValue spi context document renderer stream runTime | count := 0. runTime := 200. anAssociation := referenceDict at: key ifAbsent: [ 'Undefined' -> 100000 ]. title := anAssociation key. referenceValue := anAssociation value. stream := WriteStream on: String new. document := builder documentClass on: stream codec: builder codec. context := WARenderContext new. context document: document. context actionUrl: builder actionUrl; resourceUrl: builder resourceUrl. renderer := builder rendererClass context: context. builder openDocument: document context: context. html div class: 'bench'; with: [ html heading: title. startTime := Time millisecondClockValue. endTime := startTime + runTime. [ Time millisecondClockValue < endTime ] whileTrue: [ count := count + 1. renderer render: aBlock; flush ] ]. builder closeDocument: document. spi := (count / referenceValue * (10000 / runTime)) rounded. backColor := spi > 100 ifTrue: [ '#5f5' ] ifFalse: [ spi < 50 ifTrue: [ '#f55' ] ifFalse: [ '#55f' ] ]. duration := duration + spi. html div style: 'float:left;padding:4px'; with: [ html big: spi greaseString , ' SPI'. html span class: 'iteration'; with: '(' , count greaseString , ' iterations)'. html break. html div class: 'rect'; style: 'background:' , backColor , ';width:' , (spi * 2) greaseString , 'px' ]. html div style: 'clear:both' Cheers Philippe

Jan. 1, 2011

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Updates: Status: Accepted Comment #3 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 we should pay attention that some methods are tagged 1.1 but this is better to key them in SmalltalkImage so we should probably just put them in a deprecated category but not in the package and add a comment to them

Jan. 1, 2011

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Comment #2 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 http://code.google.com/p/pharo/issues/detail?id=2733

Jan. 1, 2011

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Comment #1 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 related to 2733

Jan. 1, 2011

[Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 1.1 deprecated methods should be packaged in a separate package and unloaded from 1.3

Jan. 1, 2011

[Pharo-project] fixing deprecation process once for all

by StÃ©phane Ducasse

I took 5 min and wrote down that http://code.google.com/p/pharo/wiki/DeprecationProcess comment if you want.

Jan. 1, 2011