February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by StÃ©phane Ducasse

Hi john have a look MessageNode class side methods you will see the list of messages that are inlined. Stef On Feb 17, 2011, at 3:21 PM, John B Thiel wrote: > Cog VM -- Thanks and Performance / Optimization Questions > > > To Everyone, thanks for your great work on Pharo and Squeak, and to > Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks > for the Squeak VM Cog and its precursors, which I was keenly > anticipating for a decade or so, and is really going into stride with > the latest builds. > > I like to code with awareness of performance issues. Can you tell or > point me to some performance and efficiency tips for Cog and the > Squeak compiler -- detail on which methods are inlined, best among > alternatives, etc. For example, I understand #to:do: is inlined -- > what about #to:do:by: and #timesRepeat and #repeat ? Basically, I > would like to read a full overview of which core methods are specially > optimized (or planned). > > I know about the list of NoLookup primitives, as per Object > class>>howToModifyPrimitives, supposing that is still valid? > > What do you think is a reasonable speed factor for number-crunching > Squeak code vs C ? I am seeing about 20x slower in the semi-large > scale, which surprised me a bit because I got about 10x on smaller > tests, and a simple fib: with beautiful Cog is now about 3x (wow!). > That range, 3x tiny tight loop, to 20x for general multi-class > computation, seems a bit wide -- is it about expected? > > My profiling does not reveal any hotspots, as such -- it's basically > 2, 3, 5% scattered around, so I envision this is just the general > vm/jit overhead as you scale up -- referencing distant objects, slots, > dispatch lookups, more cache misses, etc. But maybe I am generally > using some backwater loop/control methods, techniques, etc. that could > be tuned up. e.g. I seem to recall a trace at some point showing > #timesRepeat taking 10% of the time (?!). Also, I recall reading > about an anomaly with BlockClosures -- something like being rebuilt > every time thru the loop - has that been fixed? Any other gotchas to > watch for currently? > > (Also, any notoriously slow subsystems? For example, Transcript > writing is glacial.) > > The Squeak bytecode compiler looks fairly straightforward and > non-optimizing - just statement by statement translation. So it > misses e.g. chances to store and reuse, instead of pop, etc. I see > lots of redundant sequences emitted. Are those kind of things now > optimized out by Cog, or would tighter bytecode be another potential > optimization path. (Is that what the Opal project is targetting?) > > -- jbthiel >

Feb. 17, 2011

[Pharo-project] Issue 3727 in pharo: Fix Inspector Menu

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3727 by Benjamin...(a)gmail.com: Fix Inspector Menu http://code.google.com/p/pharo/issues/detail?id=3727 To reproduce: -inspect any object - right clic in the text area Igor fixed it :) Attachments: FixInspectorMenu.1.cs 516 bytes

Feb. 17, 2011

[Pharo-project] Issue 3726 in pharo: Turn the orange corner into a real Morph object

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com CC: siguc...(a)gmail.com New issue 3726 by Benjamin...(a)gmail.com: Turn the orange corner into a real Morph object http://code.google.com/p/pharo/issues/detail?id=3726 Gofer new squeaksource: 'PharoTaskForces'; package: 'AdorementMorph'; load Then add the attached cs. For now, it just cahnge the cursor into a hand ^^ But soon, we will attach behavior Attachments: Morphic-IgorStasenko.834.1.cs 1.8 KB

Feb. 17, 2011

[Pharo-project] Issue 3725 in pharo: OnTheFlySelectionLists

by pharo＠googlecode.com

Status: RFC Owner: Benjamin...(a)gmail.com New issue 3725 by Benjamin...(a)gmail.com: OnTheFlySelectionLists http://code.google.com/p/pharo/issues/detail?id=3725 Gofer new squeaksource: 'OnTheFlySelectionLis'; package: 'OnTheFlySelectionLists'; load 2 new kinds of PluggableList where the selection is seted on the fly. Attached a cs which integrated them in the Core browser Attachments: BrowserUseAutoSelectionList.1.cs 1.6 KB

Feb. 17, 2011

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by David T. Lewis

I cannot really answer your questions directly, but you will find lots of information on these topics in Eliot's blog: http://www.mirandabanda.org/cogblog/ Dave On Thu, Feb 17, 2011 at 06:21:01AM -0800, John B Thiel wrote: > Cog VM -- Thanks and Performance / Optimization Questions > > > To Everyone, thanks for your great work on Pharo and Squeak, and to > Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks > for the Squeak VM Cog and its precursors, which I was keenly > anticipating for a decade or so, and is really going into stride with > the latest builds. > > I like to code with awareness of performance issues. Can you tell or > point me to some performance and efficiency tips for Cog and the > Squeak compiler -- detail on which methods are inlined, best among > alternatives, etc. For example, I understand #to:do: is inlined -- > what about #to:do:by: and #timesRepeat and #repeat ? Basically, I > would like to read a full overview of which core methods are specially > optimized (or planned). > > I know about the list of NoLookup primitives, as per Object > class>>howToModifyPrimitives, supposing that is still valid? > > What do you think is a reasonable speed factor for number-crunching > Squeak code vs C ? I am seeing about 20x slower in the semi-large > scale, which surprised me a bit because I got about 10x on smaller > tests, and a simple fib: with beautiful Cog is now about 3x (wow!). > That range, 3x tiny tight loop, to 20x for general multi-class > computation, seems a bit wide -- is it about expected? > > My profiling does not reveal any hotspots, as such -- it's basically > 2, 3, 5% scattered around, so I envision this is just the general > vm/jit overhead as you scale up -- referencing distant objects, slots, > dispatch lookups, more cache misses, etc. But maybe I am generally > using some backwater loop/control methods, techniques, etc. that could > be tuned up. e.g. I seem to recall a trace at some point showing > #timesRepeat taking 10% of the time (?!). Also, I recall reading > about an anomaly with BlockClosures -- something like being rebuilt > every time thru the loop - has that been fixed? Any other gotchas to > watch for currently? > > (Also, any notoriously slow subsystems? For example, Transcript > writing is glacial.) > > The Squeak bytecode compiler looks fairly straightforward and > non-optimizing - just statement by statement translation. So it > misses e.g. chances to store and reuse, instead of pop, etc. I see > lots of redundant sequences emitted. Are those kind of things now > optimized out by Cog, or would tighter bytecode be another potential > optimization path. (Is that what the Opal project is targetting?) > > -- jbthiel

Feb. 17, 2011

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by Damien Pollet

On Thu, Feb 17, 2011 at 15:21, John B Thiel <jbthiel(a)gmail.com> wrote: > I like to code with awareness of performance issues. Â Can you tell or > point me to some performance and efficiency tips for Cog and the > Squeak compiler -- detail on which methods are inlined, best among > alternatives, etc. Â For example, I understand #to:do: is inlined -- > what about #to:do:by: and #timesRepeat and #repeat Â ? Â Basically, I > would like to read a full overview of which core methods are specially > optimized (or planned). I think these methods should be marked with pragmas. Not sure how the compiler decides to implement this or that inlined method, but maybe an idea for the compiler redesign ? -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Feb. 17, 2011

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by Schwab,Wilhelm K

A nice mix is to do memory management and logic (e.g. decide when to stop iterating) in Smalltalk and to have C-callable "primitives" for the heavy loops. A great way to reach the latter is to define the functions using extern "C" - then you can use C++ features (streams, templates) in the function bodies. IMHO, C++ with some suitable operator overloading does a fairly nice job of formula translation, and it is a good fit for fixed size arithmetic. If Cog can make the above optional, so much the better. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of John B Thiel [jbthiel(a)gmail.com] Sent: Thursday, February 17, 2011 9:21 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions Cog VM -- Thanks and Performance / Optimization Questions To Everyone, thanks for your great work on Pharo and Squeak, and to Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks for the Squeak VM Cog and its precursors, which I was keenly anticipating for a decade or so, and is really going into stride with the latest builds. I like to code with awareness of performance issues. Can you tell or point me to some performance and efficiency tips for Cog and the Squeak compiler -- detail on which methods are inlined, best among alternatives, etc. For example, I understand #to:do: is inlined -- what about #to:do:by: and #timesRepeat and #repeat ? Basically, I would like to read a full overview of which core methods are specially optimized (or planned). I know about the list of NoLookup primitives, as per Object class>>howToModifyPrimitives, supposing that is still valid? What do you think is a reasonable speed factor for number-crunching Squeak code vs C ? I am seeing about 20x slower in the semi-large scale, which surprised me a bit because I got about 10x on smaller tests, and a simple fib: with beautiful Cog is now about 3x (wow!). That range, 3x tiny tight loop, to 20x for general multi-class computation, seems a bit wide -- is it about expected? My profiling does not reveal any hotspots, as such -- it's basically 2, 3, 5% scattered around, so I envision this is just the general vm/jit overhead as you scale up -- referencing distant objects, slots, dispatch lookups, more cache misses, etc. But maybe I am generally using some backwater loop/control methods, techniques, etc. that could be tuned up. e.g. I seem to recall a trace at some point showing #timesRepeat taking 10% of the time (?!). Also, I recall reading about an anomaly with BlockClosures -- something like being rebuilt every time thru the loop - has that been fixed? Any other gotchas to watch for currently? (Also, any notoriously slow subsystems? For example, Transcript writing is glacial.) The Squeak bytecode compiler looks fairly straightforward and non-optimizing - just statement by statement translation. So it misses e.g. chances to store and reuse, instead of pop, etc. I see lots of redundant sequences emitted. Are those kind of things now optimized out by Cog, or would tighter bytecode be another potential optimization path. (Is that what the Opal project is targetting?) -- jbthiel

Feb. 17, 2011

[Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by John B Thiel

Cog VM -- Thanks and Performance / Optimization Questions To Everyone, thanks for your great work on Pharo and Squeak, and to Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks for the Squeak VM Cog and its precursors, which I was keenly anticipating for a decade or so, and is really going into stride with the latest builds. I like to code with awareness of performance issues. Can you tell or point me to some performance and efficiency tips for Cog and the Squeak compiler -- detail on which methods are inlined, best among alternatives, etc. For example, I understand #to:do: is inlined -- what about #to:do:by: and #timesRepeat and #repeat ? Basically, I would like to read a full overview of which core methods are specially optimized (or planned). I know about the list of NoLookup primitives, as per Object class>>howToModifyPrimitives, supposing that is still valid? What do you think is a reasonable speed factor for number-crunching Squeak code vs C ? I am seeing about 20x slower in the semi-large scale, which surprised me a bit because I got about 10x on smaller tests, and a simple fib: with beautiful Cog is now about 3x (wow!). That range, 3x tiny tight loop, to 20x for general multi-class computation, seems a bit wide -- is it about expected? My profiling does not reveal any hotspots, as such -- it's basically 2, 3, 5% scattered around, so I envision this is just the general vm/jit overhead as you scale up -- referencing distant objects, slots, dispatch lookups, more cache misses, etc. But maybe I am generally using some backwater loop/control methods, techniques, etc. that could be tuned up. e.g. I seem to recall a trace at some point showing #timesRepeat taking 10% of the time (?!). Also, I recall reading about an anomaly with BlockClosures -- something like being rebuilt every time thru the loop - has that been fixed? Any other gotchas to watch for currently? (Also, any notoriously slow subsystems? For example, Transcript writing is glacial.) The Squeak bytecode compiler looks fairly straightforward and non-optimizing - just statement by statement translation. So it misses e.g. chances to store and reuse, instead of pop, etc. I see lots of redundant sequences emitted. Are those kind of things now optimized out by Cog, or would tighter bytecode be another potential optimization path. (Is that what the Opal project is targetting?) -- jbthiel

Feb. 17, 2011

[Pharo-project] Continuous Delivery

by Alexandre Bergel

Hi! The excitement Hudson triggered makes me think that you may be interested in the review of the book "Continuous delivery" that I just wrote: http://alexandrebergel.blogspot.com/ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 17, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson

by Guillermo Polito

So, the problem is that FixSHWorkspaceToFixMenu.1.cs must be integrated into SHWorkspace, is it? :) On Thu, Feb 17, 2011 at 10:35 AM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > It;s because of FixWorkspaceMenu.2.cs > Normally the cs PrepareFixWorkspaceMenu.2.cs have to be applied before to > avoid this problem > > > Ben > > > On Feb 17, 2011, at 1:52 PM, Guillermo Polito wrote: > > Ok, I fixed OB, but now is failing because: > > DuplicatedVariableError: stylingActive is already defined in Workspace > > > :( > > > > On Wed, Feb 16, 2011 at 9:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Pharo 1.2. is broken on Hudson. >> >> The ConfigurationOfPharo is not loadable on a core image due >> to changes on OmniBrowser. >> >> Reason: >> ======= >> ConfigurationOfOmniBrowser-GuillermoPolito.102.mcz in >> http://www.squeaksource.com/MetacelloRepository >> references "OB-Shout-JohanBrichau.13" in spec for: #pharo in its >> version 1.2.4 >> >> But OB-Shout-JohanBrichau.13 is not in >> http://www.squeaksource.com/PharoOB >> Should we use "OB-Shout-GuillermoPolito.13.mcz" instead? >> >> Guillermo: can you give me access to PharoOB too? >> >> Thx >> T. >> >> >> -- >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> > > >

Feb. 17, 2011