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

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

by John M McIntosh

On 2010-03-29, at 11:39 PM, Adrian Lienhard wrote: > > What's the yearly costs for the Intel Compiler license? > > Adrian non-academic it's $599 & then $240 academic license is $160 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 30, 2010

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

by Adrian Lienhard

On Mar 29, 2010, at 22:23 , Mariano Martinez Peck wrote: > 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. Yes, exactly. And I think that's the most important piece and the one valuable to maintain. We just create a segment, write it to disc, and read it back from there into a fresh image. The only problem we had was with the symbols you mentioned above. We do migrations with scripts inside the image so that the segment's instances are always in sync with the code of the image we load them into. > 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. Depends on what you think is big. Most of our segments are smaller than 50MB but I have seen larger ones that worked too. Cheers, Adrian > 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 >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010

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

by Adrian Lienhard

On Mar 30, 2010, at 01:09 , Levente Uzonyi wrote: > On Mon, 29 Mar 2010, John M McIntosh wrote: > >> >> On 2010-03-29, at 2:11 PM, Levente Uzonyi wrote: >> >>> 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 >> >> Maybe, assuming someone runs some numbers, and/or you think that intel purposely trashes performance on those machines if you >> use their compilers? > > http://www.agner.org/optimize/blog/read.php?i=49 > >> >> Also is the linux crowd 100% AMD/VIA? If it's only 20% as per the Intel CPU market share, then maybe the 80% of linux > > Definitely not. > >> intel CPU based users would enjoy better performance versus a muddled offering in order to keep in line with the slowest 20% of the user base? > > I'm not against the use of icc, but it's not a silver bullet. The question is: how much better performance can be achieved with it? Having 2% better performance for 80% of the users, while -50% performance for the rest doesn't worth it IMHO. What's the yearly costs for the Intel Compiler license? Adrian

March 30, 2010

Re: [Pharo-project] The Windows VM

by GermÃ¡n Arduino

Sorry, correct me if I'm wrong, but Pharo don't have its own Win VM right? Then if Pharo relies on the Squeak Windows VM I think that a good policy is use the latest. Just my opinion. Cheers. GermÃ¡n. 2010/3/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. I have just tested the Windows VM availables and tested the 1 > tinyBenchmarks and running all tests of PharoDev RC3. > > I tested with this Windows VMs: > > 1) The one that it is in pharo website (PharoVM-Win32-3.11.8): > 2) The other one from pharo website (exupery-vm-0.15-win32): > 3) THe new one that Andreas released today (SqueakVM-Win32-4.0.1-bin) > > > 1) vm\SqueakVM-Win32-4.0.1-bin\ > > Â has freetype > > 1 tinyBenchmarks > Â '404104183 bytecodes/sec; 11914092 sends/sec' > Â '363120567 bytecodes/sec; 10946039 sends/sec' > Â '390839694 bytecodes/sec; 12597221 sends/sec' > Â '346179851 bytecodes/sec; 9996295 sends/sec' > > 1 gofer test fails > > > 2)Â exupery-vm-0.15-win32 > > doesnt have freetype. Unacceptable for Pharo. > > 1 tinyBenchmarks > Â '365714285 bytecodes/sec; 9935342 sends/sec' > Â '365975696 bytecodes/sec; 10435290 sends/sec' > Â '349011588 bytecodes/sec; 16777208 sends/sec' > Â '339973439 bytecodes/sec; 11292844 sends/sec' > > Two RB test with errors > > > 3) Â SqueakVM-Win32-4.0.1-bin > > has freetype > > 1 tinyBenchmarks > Â '353835521 bytecodes/sec; 11294326 sends/sec' > Â '415922014 bytecodes/sec; 12319712 sends/sec' > Â '369675090 bytecodes/sec; 11149338 sends/sec' > Â '373177842 bytecodes/sec; 9858402 sends/sec' > > all tests geen > > > We suggestion is to remove the Exupery Vm from the pharo website. > The new version 4.1 doesn't seem to be improvements in speed and from what I > read about Andreas comment, it only fixes problems for SqueakMap, which was > removed in Pharo, and a change in the close event of the windows. > I would only let for download the PharoVM-Win32-3.11.8 > > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 30, 2010

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: > > On 2010-03-29, at 2:11 PM, Levente Uzonyi wrote: > >> 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 > > Maybe, assuming someone runs some numbers, and/or you think that intel purposely trashes performance on those machines if you > use their compilers? http://www.agner.org/optimize/blog/read.php?i=49 > > Also is the linux crowd 100% AMD/VIA? If it's only 20% as per the Intel CPU market share, then maybe the 80% of linux Definitely not. > intel CPU based users would enjoy better performance versus a muddled offering in order to keep in line with the slowest 20% of the user base? I'm not against the use of icc, but it's not a silver bullet. The question is: how much better performance can be achieved with it? Having 2% better performance for 80% of the users, while -50% performance for the rest doesn't worth it IMHO. Levente > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > >

March 29, 2010

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

by Bryce Kampjes

On Sun, 2010-03-28 at 18:21 -0300, Mariano Martinez Peck wrote: > > - It has to be a Standard VM, not Exupery. Exupery without the exupery > package, has no sense at all. It is in Pharo download just because of > history reasons. Bryce was very helpful and was the first in put > closures in the VM. So, we used that. Now, it has no sense anymore. If you're not using Exupery it should make no difference if you're using an Exupery VM or not. It's just a regular VM with a few small hooks in it. That said, I'd prefer to put my Squeak/Pharo time into Exupery so am very happy that other people are maintaining the general purpose VMs. Bryce

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: > On Mon, Mar 29, 2010 at 6:03 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> 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? >> >> > Maybe I express wrongly myself. I said several times (even in this thread) I > was a newbie. I said that all the VMs I have tried for Linux are slower than > the one I tried for Mac OS. At least the ones that are available for us > without needing to be a VM guru. And it seems I was not the only to notice > that. That's normal. Mac VMs can be optimized for Intel Core processors, since all Intel based Macs use those, while prebuilt Linux VMs are usually optimized for i686. That means it's compatible with Pentium Pro (from 1995), so it doesn't use newer instructions and doesn't optimize for a specific CPU architecture. If you compile your own VM from source, it can be significantly faster. Levente > > > > >> >> 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 >>>> >>>> >>> >> _______________________________________________ >> 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 Alexandre Bergel

Thanks Adrian and Mariano for this interesting discussion. Alexandre On 29 Mar 2010, at 16:23, Mariano Martinez Peck wrote: > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

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 2:11 PM, Levente Uzonyi wrote: > 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 Maybe, assuming someone runs some numbers, and/or you think that intel purposely trashes performance on those machines if you use their compilers? Also is the linux crowd 100% AMD/VIA? If it's only 20% as per the Intel CPU market share, then maybe the 80% of linux intel CPU based users would enjoy better performance versus a muddled offering in order to keep in line with the slowest 20% of the user base? -- =========================================================================== 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 Mariano Martinez Peck

On Mon, Mar 29, 2010 at 6:03 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > 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? > > Maybe I express wrongly myself. I said several times (even in this thread) I was a newbie. I said that all the VMs I have tried for Linux are slower than the one I tried for Mac OS. At least the ones that are available for us without needing to be a VM guru. And it seems I was not the only to notice that. > > 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 >>> >>> >> > _______________________________________________ > 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