March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Levente Uzonyi

On Mon, 29 Mar 2010, John M McIntosh wrote: > Actually one *can* make the linux VM faster than the MacOS one on the same hardware using just the right version of GCC. > > But frankly the *easiest* way of doing that is for Pharo to fund the yearly license for using the Intel Compiler and provide a > one-click Intel compiler based VM. For Intel CPUs that's a good solution, but those binaries would be really slow on AMD and VIA CPUs. Levente > > > On 2010-03-29, at 11:33 AM, Mariano Martinez Peck wrote: >> http://n4.nabble.com/Pharo-apparently-slow-on-linux-td1304643.html#a1304643 >> >> but there are more. >> The MacOS VM is faster than the rest, even with the same PC. >> I have no idea how to improve Linux's one, thus. >> >> Cheers >> >> Mariano > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > >

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Levente Uzonyi

On Mon, 29 Mar 2010, Mariano Martinez Peck wrote: > 2010/3/29 laurent laffont <laurent.laffont(a)gmail.com> > >> >> On Mon, Mar 29, 2010 at 2:09 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Mon, 29 Mar 2010, laurent laffont wrote: >>> >>> On Mon, Mar 29, 2010 at 1:19 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> On Mon, 29 Mar 2010, laurent laffont wrote: >>>>> >>>>> 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> >>>>> >>>>>> >>>>>> So what Ghz is this machine? >>>>>> >>>>>>> >>>>>>> >>>>>>> model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz >>>>>> cpu MHz : 1994.987 >>>>>> cache size : 4096 KB >>>>>> >>>>>> >>>>> There must be something wrong. My T8300 notebook had about 550M >>>>> bytecodes/sec and 15M sends/sec on linux. With the stock windows vm I >>>>> have >>>>> 500M bytecodes/sec and 14.5M sends/sec. >>>>> >>>>> >>>> With the source I have provided ? 32bits ? >>>> >>> >>> My linux vm was 32-bit with some older sources. Since I don't have linux >>> on my notebook anymore I can't tell which version it was. >>> >>> >>> >> >> On MacOSX, same laptop, with Squeak VM 4.2.2 beta 1U from pharo website >> >> 449122807 bytecodes/sec; 9649554 sends/sec >> 405384006 bytecodes/sec; 9584683 sends/sec >> 445604873 bytecodes/sec; 10138464 sends/sec >> 445993031 bytecodes/sec; 10102544 sends/sec >> 446381865 bytecodes/sec; 10174641 sends/sec >> >> compared to Linux >> >> >> Squeak VM 3.11.3 -r 2135 + FT2Plugin + --CFLAGS="-O3 -fomit-frame-pointer >> -mfpmath=sse -march=native -s -mtune=generic" >> ========================================== >> 339072847 bytecodes/sec; 9560580 sends/sec >> 338848444 bytecodes/sec; 9552573 sends/sec >> 338177014 bytecodes/sec; 9473233 sends/sec >> 337953795 bytecodes/sec; 9496896 sends/sec >> 338848444 bytecodes/sec; 9496896 sends/sec >> >> so it seems there's improvements that can be done on Linux VM, but there's >> not so much difference. >> >> > I think everybody know this and that your results is the expected. I even > remember some threads were we discussed the same. For example, I found this > one: > > http://n4.nabble.com/Pharo-apparently-slow-on-linux-td1304643.html#a1304643 > > but there are more. > The MacOS VM is faster than the rest, even with the same PC. You know that's simply bullshit, do you? Levente > I have no idea how to improve Linux's one, thus. > > Cheers > > Mariano > > > > >> Laurent Laffont >> >> >> >>> Levente >>> >>> >>> >>>> Laurent Laffont >>>> >>>> >>>> >>>> >>>>> >>>>> Levente >>>>> >>>>> >>>>> >>>>> Laurent Laffont >>>>>> >>>>>> >>>>>> >>>>>> On 2010-03-28, at 10:42 AM, laurent laffont wrote: >>>>>>> >>>>>>> Thank you ! >>>>>>> >>>>>>> Here the result: >>>>>>> >>>>>>> Squeak VM 3.11.3 -r 2135 + FT2Plugin + --CFLAGS="-O3 >>>>>>> -fomit-frame-pointer >>>>>>> -mfpmath=sse -march=native -s -mtune=generic" >>>>>>> ========================================== >>>>>>> 339072847 bytecodes/sec; 9560580 sends/sec >>>>>>> 338848444 bytecodes/sec; 9552573 sends/sec >>>>>>> 338177014 bytecodes/sec; 9473233 sends/sec >>>>>>> 337953795 bytecodes/sec; 9496896 sends/sec >>>>>>> 338848444 bytecodes/sec; 9496896 sends/sec >>>>>>> >>>>>>> so the best performance I have so far. >>>>>>> >>>>>>> Laurent Laffont >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> =========================================================================== >>>>>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>>>>>> squeaker68882 >>>>>>> Corporate Smalltalk Consulting Ltd. >>>>>>> http://www.smalltalkconsulting.com >>>>>>> >>>>>>> >>>>>>> =========================================================================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

March 29, 2010

[Pharo-project] theme menuFont

by Hilaire Fernandes

Gary, I read from you Polymorph example (toolbar and menu), your are forcing the menu font to theme menuFont. Is it still necessary to do so ? win := StandardWindow new. fileMenu := win newMenu. fileMenu addToggle: 'Open' translated target: nil "would be model" selector: #openFile. fileMenu lastItem font: win theme menuFont; icon: MenuIcons smallOpenIcon; Hilaire

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by John M McIntosh

On 2010-03-29, at 1:30 PM, laurent laffont wrote: > 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Actually one *can* make the linux VM faster than the MacOS one on the same hardware using just the right version of GCC. > > > Which GCC do you use ? Mine is 4.4.3 > > Laurent Laffont Those numbers come from 4.4.1, I can't speak for what 4.4.3 might/could/would do to affect performance good/bad. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by John M McIntosh

On 2010-03-29, at 1:16 PM, laurent laffont wrote: > > 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Ok, fyi on a 2.33 Ghz intel core 2 duo machine a *correctly tuned* VM gives > > 582,148,948 bytescodes/sec; 14,497,194 sends/sec > > How do you tune your VM ? Well the linux VM build process is so complicated, fraught with issues, and requires such careful tool usage I currently have clients who pay for the results like above so it's not fair to them to disclose the information. I can say I think the VM you are building doesn't appear to be using the gunified version of interp.c you should carefully log and check the output from the build to confirm what source being compiled and how it's be compiled is what you think is going on. Lastly what version of GCC are you using? There can be clue there that I've talked about in the past. As mentioned in the earlier note perhaps the easiest path is to invest in the Intel compiler for Linux. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Actually one *can* make the linux VM faster than the MacOS one on the same > hardware using just the right version of GCC. > > Which GCC do you use ? Mine is 4.4.3 Laurent Laffont > But frankly the *easiest* way of doing that is for Pharo to fund the yearly > license for using the Intel Compiler and provide a > one-click Intel compiler based VM. > > > On 2010-03-29, at 11:33 AM, Mariano Martinez Peck wrote: > > http://n4.nabble.com/Pharo-apparently-slow-on-linux-td1304643.html#a1304643 > > but there are more. > The MacOS VM is faster than the rest, even with the same PC. > I have no idea how to improve Linux's one, thus. > > Cheers > > Mariano > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 29, 2010

Re: [Pharo-project] The Pharo Linux Vm [WAS] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Mariano Martinez Peck

On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote: > > > 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > > > >> Also this week I will ship a 4.2.4b1 VM which is the result of some > Squeak > >> 4.0 base VM merge processing and contains the fix to enable the loading > of > >> old image segments used I guess by squeakmap? > >> > >> > > > > I am not sure. ImageSegment is a full of c...and maybe it will be even > > removed. It was not working since a lot of time and nobody says anything. > > Mariano, I know you know image segments, but I think this is may be > confusing for others. So I like to say something ;) > > Image segments work very well; both from a reliability and performance > point of view. We are using them for hundreds of customers. DabbleDB uses > images segments as well AFAIK. > > There are two parts, the primitives implemented by the VM in C and the > image-side code. The code in the image consists of support code to load and > store a segment and on top of this there is code for swapping in/out > classes, projects etc. Especially the latter is a mess and we already > started cleaning it. As images segments are not used by core code we also > consider moving it into a separate, external package (of course, the > primitives should stay in the VM). > > Thanks for the remark Adrian :) I know you know more for ImageSegments than all of us. As you said, it works pretty well for a piece of the domain. For example, in your case, you just export the segment, but did you try to swap them out (but letting the segment inside) and load it again ? it was broken. Exporting a segment, and bring them back again but where classes were modified or removed in the image, was broken also. If you load segments from older versions, it was broken too (this was what they fixed now). The symbols, you explained me that problem. In your case it works perfect because, as you say, almost only use the primitives, no more. But that's a very limited piece of ImageSegment. That piece, in that way, it works. For big segments, I am not sure if it works well neither. The segment allocates more than 2 times what needed. In DabbleDB I read they had that problem. The segments were too big, that having to allocate 2 or 3 times, crash everything. Cheers Mariano > > We > > even started to remove part of it in Pharo. And SqueakMap was completely > > removed. > > Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not > critical for us. > > Cheers, > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by John M McIntosh

Actually one *can* make the linux VM faster than the MacOS one on the same hardware using just the right version of GCC. But frankly the *easiest* way of doing that is for Pharo to fund the yearly license for using the Intel Compiler and provide a one-click Intel compiler based VM. On 2010-03-29, at 11:33 AM, Mariano Martinez Peck wrote: > http://n4.nabble.com/Pharo-apparently-slow-on-linux-td1304643.html#a1304643 > > but there are more. > The MacOS VM is faster than the rest, even with the same PC. > I have no idea how to improve Linux's one, thus. > > Cheers > > Mariano -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 29, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by laurent laffont

2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > Ok, fyi on a 2.33 Ghz intel core 2 duo machine a *correctly tuned* VM > gives > > 582,148,948 bytescodes/sec; 14,497,194 sends/sec > How do you tune your VM ? I've tried the Smalltalk version of Gnuification, but results are worse. So far the best I have is: -O2 -fomit-frame-pointer -mfpmath=sse -march=native -s -mtune=generic ========================================== 345479082 bytecodes/sec; 9815639 sends/sec 348536419 bytecodes/sec; 9970081 sends/sec 348299319 bytecodes/sec; 9978804 sends/sec 345013477 bytecodes/sec; 9690546 sends/sec 348299319 bytecodes/sec; 9970081 sends/sec Laurent Laffont > > > On 2010-03-28, at 10:21 PM, laurent laffont wrote: > > 2010/3/29 John M McIntosh <johnmci(a)smalltalkconsulting.com> > >> So what Ghz is this machine? >> > > model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz > cpu MHz : 1994.987 > cache size : 4096 KB > > Laurent Laffont > > >> >> On 2010-03-28, at 10:42 AM, laurent laffont wrote: >> >> Thank you ! >> >> Here the result: >> >> Squeak VM 3.11.3 -r 2135 + FT2Plugin + --CFLAGS="-O3 -fomit-frame-pointer >> -mfpmath=sse -march=native -s -mtune=generic" >> ========================================== >> 339072847 bytecodes/sec; 9560580 sends/sec >> 338848444 bytecodes/sec; 9552573 sends/sec >> 338177014 bytecodes/sec; 9473233 sends/sec >> 337953795 bytecodes/sec; 9496896 sends/sec >> 338848444 bytecodes/sec; 9496896 sends/sec >> >> so the best performance I have so far. >> >> Laurent Laffont >> >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 29, 2010

Re: [Pharo-project] squeakToUTF-8 and related?

by John M McIntosh

On 2010-03-29, at 6:54 AM, Henrik Johansen wrote: > >> Maybe with a bit more clean-up (Character euro is answering the >> MacRoman code for example, > The keyboardinput handling in Squeak does strange things, at least on a Mac... > Alt - Â§ (which gives a euro symbol on my keyboard layout) is read as a WideChar with the correct unicode value on Pharo, but as Char 164 in Squeak. > Alt- 5 (â) does a similar thing, reads as correct widechar on Pharo, but on Squeak turns into char 129. No doubt this is because the InputSensor logic in that image "Squeak" you are using pulls the MacRoman value out of the keyboard event array and passes that unchanged to Morphic. To summarize then I think all current VM (last couple of years) provide unicode values on the keychar event. Now the murky underpinnings, and I"ll only talk about the macintosh VM. The macintosh carbon 4.x VM receives the unicode value, macroman value, and keycode value for each input character, this is after text services has mucked with the keystrokes to deal with characters that require multi-keystroke to create. For the case where a text input widget is used to enter data we convert the unicode values to macroman and have no keycode data. In both cases we use CFStringGetCString() with kCFStringEncodingMacRoman to get the MacRoman value. In the Smalltalk Image the code must then take the combination of key down, key char, key up events (there are three events), and decide what to do. Depending on the frame work that might take data from key up, or key char and work with the macroman value, the unicode value, or even do take just the keycode and lookup the macroman & unicode in the image! In general all VMs attempt to supply the unicode and macroman values, the key code are a platform specific values. In the Cocoa based V5 VM the unicode and keycode is supplied by the event data, however some keyboard usage, oh say the HOME key result in a message send, versus keystroke so we have to create a synthetic keyboard event and build the unicode & keycode data to match the Carbon based VM's behaviour. The MacRoman data comes from NSMacOSRomanStringEncoding via getBytes: from the unicode char. For the iPhone we don't offer keyboard input (*yet*) The more attentive of you folks might wonder about keyboard input and the iPhone/iPad and Scratch.app. Er yes obviously we feed keyboard input to the Squeak VM. For that we have the unicode, and then calculate the rest, the MacRoman data comes from NSMacOSRomanStringEncoding, and we build the KeyCode data using a unicode to keycode table we built from KCHR carbon data. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 29, 2010