- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?

by Esteban Lorenzano

AFAIK the armv7 is in the works, being the limitant now the FFI support? But not sure :) Esteban > On 9 Apr 2019, at 22:48, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > Hi, I'd like to play around with pharo on ARM devices (like a > HummingBoard, the ones from ODROID or one of the beagleboards). But I am > not sure if I have to take care of the ARM architecture version (ARMv6 / > ARMv7 / ARMv8) when choosing my toy. > > I found this vm: > http://files.pharo.org/vm/pharo-spur32/linux/armv6/ <http://files.pharo.org/vm/pharo-spur32/linux/armv6/> > Is it only for armv6 like the folder name says or is ARMv7 and ARMv8 > working too? > > Are there any limitations I should know before choosing a ARM device? > > Is there a vm for 64bit (aarch64)? > > Hi Albrecht, > > I am also interested in this answer. In general, I am interested in IoT support for Smalltalk. > > The only thing I found aside from ARMv6 is this: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM… <https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM…> > But I don't know what's the status of it. > > You may have more chances to get an answer with the vm list: > <vm-dev(a)lists.squeakfoundation.org <mailto:vm-dev@lists.squeakfoundation.org>> > Or maybe Pharo dev list. > > Cheers, > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com <mailto:marianopeck@gmail.com> > Twitter: @MartinezPeck > LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/ <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>

April 10, 2019

Re: [Pharo-dev] Performance Issues

by Mariano Martinez Peck

Hola Pablito :) That sounds amazing. Great job!! About "Automation and CI in the future.", do you know if Smalltalk CI supports something for this? Thanks! On Tue, Apr 2, 2019 at 11:22 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, this will be a long mail. I have organized it in different sections. > > Resume: > ====== > > - There are performance issues in Pharo 7. > - I have made benchmarks. > - With Guille we made an improvement in saving source code in methods. > - More improvements to come. > - Automation and CI in the future. > > > Background > ========= > > Since the release of Pharo 7 (and before it), it was notorious that > there exists a performance regression in the normal execution of the > image. By checking the usual operations, we have seen ( and many have > also detected) that there was an issue with the loading, compilation, > and unloading of code. Also with the creation of classes, traits and > the use of slots. > > Benchmarks > ========= > > Although we were sure that there is a performance regression, we have > to show it in a way we can test it and measure it. If we cannot > measure it or repeat its execution it is worthless. > For doing so, I have created an initial set of micro-benchmarks to > cover normal operations of the image. > > The set of benchmarks is available here: > https://github.com/tesonep/pharo-benchmarks > > These benchmarks are developed on top of SMark, only adding a command > line tool and the ability to generate a CSV file. > > The idea is to run the benchmarks in different versions of Pharo an > assert that we are not breaking anything. > > The first results were basically a nightmare, some operations take > almost 20 times more in Pharo 7. Especially, the ones that are > compiling methods. > > In the attached document, there is the detail of all the benchmarks, > the different results and the analysis of the improvements and > regressions (Positive percentages are regressions (more time), > negative are improvements (less time)). > > I have checked the results in OSX with 64 bits images. But as the > problem is in pure Smalltalk implementations the problems are (and the > solutions) cross platforms. > > First Improvement > ============== > > Having the benchmarks, it was easy to start looking for the problems. > Thanks to the help of Guille we have detected some problems in the > implementation of SourceFile. Objects of this class have the > responsibility to handle the save of the source code when a method is > modified. > > Improving this implementation we have gotten to results similar to > Pharo 6 in the compilation of methods. > > Comparing a stock Pharo8 image with the one with the fix, we have the > following improvements: > > AddingAnInstanceVariableToAClassWithASubclass -3.96% > AddingAnInstanceVariableToAClassWithoutASubclassAndInstances -15.91% > AddingAnInstanceVariableToAClassWithoutSubclasses -28.50% > ClassAndSubclassCreation -25.67% > ClassUsingATrait -90.05% > SimpleClassCreation -26.55% > TraitCreation -92.95% > TraitCreationUsingOtherTrait -91.68% > CompileAMethodAndModifyIt -32.92% > CompileAMethodInAClassUsingATrait -83.28% > CompileAMethodInATraitNotUsed -85.12% > CompileAMethodInATraitUsed -88.16% > CompileANewMethod -40.73% > CompileANewMethodUsingInstanceVariable -33.93% > MethodAccessingAGlobal -47.57% > > Again there are more details in the attached file. > > Also, we have ported this fix to Pharo 7. > > Next Steps > ======== > > - Making it a part of the CI infrastructure: making it run in each PR > and build to detect regressions in the changes. > > - Adding more micro and macro benchmarks. I have a list of things to > test, but I am open to more: > > # Micro > > - Slot Implementation > - Process handling > - Refactorings > - Files (open / write / read) > > # Macro > > - Loading: Moose / Seaside > - Recompile All > - Condense Sources > - Startup > - Shutdown > > We also know that there are platform related issues (especially > Windows), so the idea it will be the same, build a benchmark, measure > it, improve it. > > The idea is to have a more robust way of detecting and handling the > performance of Pharo. > > Of course, I am open to all your comments. > > Cheers, > Pablo > -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 9, 2019

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?

by Mariano Martinez Peck

On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi, I'd like to play around with pharo on ARM devices (like a > HummingBoard, the ones from ODROID or one of the beagleboards). But I am > not sure if I have to take care of the ARM architecture version (ARMv6 / > ARMv7 / ARMv8) when choosing my toy. > > I found this vm: > http://files.pharo.org/vm/pharo-spur32/linux/armv6/ > Is it only for armv6 like the folder name says or is ARMv7 and ARMv8 > working too? > > Are there any limitations I should know before choosing a ARM device? > > Is there a vm for 64bit (aarch64)? > Hi Albrecht, I am also interested in this answer. In general, I am interested in IoT support for Smalltalk. The only thing I found aside from ARMv6 is this: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM… But I don't know what's the status of it. You may have more chances to get an answer with the vm list: <vm-dev(a)lists.squeakfoundation.org> Or maybe Pharo dev list. Cheers, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 9, 2019

Re: [Pharo-dev] Performance Issues

by Francisco Ortiz PeÃ±aloza

This is great news! Thanks, Francisco On Wed, 3 Apr 2019 at 09:47 Ben Coman <btc(a)openinworld.com> wrote: > Thanks for this great initiative Pablo. > cheers -ben > > On Tue, 2 Apr 2019 at 22:23, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > >> Hi, this will be a long mail. I have organized it in different sections. >> >> Resume: >> ====== >> >> - There are performance issues in Pharo 7. >> - I have made benchmarks. >> - With Guille we made an improvement in saving source code in methods. >> - More improvements to come. >> - Automation and CI in the future. >> >> -- Sent from the past

April 8, 2019

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

by Guillermo Polito

Hi, On Mon, Apr 1, 2019 at 9:26 PM Torsten Bergmann <astares(a)gmx.de> wrote: > If one downloads images with Launcher on Windows and accepts default names > like "Pharo 7.0 - 32bit (stable)" this will end up in path names like > > "C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)" > > The dot and space combination in such files can later make trouble when > downloading projects (like Seaside) using Iceberg and libgit and leading > later to the "IceGenericError: failed to stat file ... The filename or > extension is too long" problem. > > I guess the dot in combination with spaces in the name is sometimes seen > as the path element on current directory. > > If one gives an own name like "LatestPharo7" in Launcher (having > C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads > even from the FileTree format. > Wow, this is weird :) Would this be related too to this: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e8f235ef313990acae… ? > As many people prefer to use Launcher now these days they might easily hit > this problem. > > I opened an issue already for Launcher so this discussion here on ML is > watched: > https://github.com/pharo-project/pharo-launcher/issues/327 > > Feedback and tests from Windows users are welcomed. > > But still, the bug looks like a libgit bug, doesn't it? I have in my hyper long TODO list to try to enhance libgit's windows support and contribute it back to libgit...

April 4, 2019

[Pharo 8.0] Build #215: 3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #215 was: SUCCESS. The Pull Request #3052 was integrated: "3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size" Pull request url: https://github.com/pharo-project/pharo/pull/3052 Issue Url: https://github.com/pharo-project/pharo/issues/3049 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 4, 2019

Re: [Pharo-dev] Green tests

by David T. Lewis

Also useful for "quick and dirty" debugging with concurrent processes: OSProcess trace: 'my debugging note' This prints to console, identifying the process, receiver, method, and whatever additional notes you may want to add. Dave On Wed, Apr 03, 2019 at 07:34:22AM +0200, Tudor Girba wrote: > Instead of printing, you can also use Beacon. We actually developed Beacon specifically to be able to debug a parallel distributed system. > > Cheers, > Doru > > > On Apr 2, 2019, at 11:56 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > > > > > On Tue, 2 Apr 2019 at 23:36, ducasse <stepharo(a)netcourrier.com> wrote: > > I???m inherently race condition incompatible and just avoid concurrent programming because I???m too dull on this. > > > > I've solved a few Pharo race conditions before, so just a tip (that you maybe already know). > > You can't troubleshoot a race condition by standard debugging, because it alters the timing. > > Best that I've done before is resorting to plain old print-line tracing between every line of the suspect code, > > or the equivalent threadsafe collection if its not a hard crash. > > e.g.... > > someMethod > > threadsafeCollection add: "methodname-A" , testCondition > > original method line 1 > > threadsafeCollection add: "methodname-B", testCondition > > original method line 2 > > threadsafeCollection add: "methodname-C", testCondition > > > > and then looking for cyclic patterns in that data and breaks in those patterns. > > > > I can have a look in a few weeks. Right now working 13 hour days to the end of the week > > and then vacationing in China for 10 days. > > > > -- > www.feenk.com > > "Sometimes the best solution is not the best solution." >

April 3, 2019

Re: [Pharo-dev] Performance Issues

by Ben Coman

Thanks for this great initiative Pablo. cheers -ben On Tue, 2 Apr 2019 at 22:23, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi, this will be a long mail. I have organized it in different sections. > > Resume: > ====== > > - There are performance issues in Pharo 7. > - I have made benchmarks. > - With Guille we made an improvement in saving source code in methods. > - More improvements to come. > - Automation and CI in the future. > >

April 3, 2019

[Pharo 8.0] Build #214: [test] added a regression test for RBProgramNode >> #propertyAt:ifPresent:ifAbsent:.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #214 was: FAILURE. The Pull Request #3134 was integrated: "[test] added a regression test for RBProgramNode >> #propertyAt:ifPresent:ifAbsent:. " Pull request url: https://github.com/pharo-project/pharo/pull/3134 Issue Url: https://github.com/pharo-project/pharo/issues/temp Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2019

[Pharo 8.0] Build #213: Simplifying DebugSession>>isContextPostMortem:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #213 was: FAILURE. The Pull Request #2928 was integrated: "Simplifying DebugSession>>isContextPostMortem:" Pull request url: https://github.com/pharo-project/pharo/pull/2928 Issue Url: https://github.com/pharo-project/pharo/issues/2927 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 3, 2019