November 2018 - Pharo-dev - lists.pharo.org

Pharo 7 speed compared to VW

by Shaping

(Second try in 6 days. Does anyone have recent performance data for Pharo 7 relative to VW 7.10 or later?) From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Shaping Sent: Tuesday, November 13, 2018 00:33 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Pharo 7 speed compared to VW (was: The STON Specification, Cog speed, and namespaces/modules) Does anyone know whether Pharo 7 is as fast as VW 7.10 or later? Do we have recent comparative benchmarks? The comparison should ignore potential GPU-based improvement in my algo; that will happen later. The test should involve some math, file streaming, and the parsing that entailsâan ordinary mix of macrobenchmarks. The comparison should be based on both Pharo 7 and VW each running a single Smalltalk Process (one time-slice of one OS thread in one OS process). I need Pharo 7 speed to be comparable or better to justify the port. Pharo is definitely looking and working better. Iâve spend more time with it last few weeks than during the previous decade. Thanks to everyone for the effort and improvements. Shaping From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, November 7, 2018 00:41 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: RE: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules Hi Eliot. Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder whether there is any issue here. STON would use the print strings for (PSC) Float / (VW) Double, and so deseerialization on Pharo would automatically produce the right class. Going in the other direction might need some help. APF needs support in PSC before one can port, but are representable as suitably-sized word arrays. There is no support for __float128 anywhere in the VM (e.g. not even in the FFI) on PSC as yet. I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. Iâm using APFs in VW in the 300-bit range, and want to reduce the needed precision to 64 bits, to save space and time on large (5 million+) scalar time-series, both on the heap and during BOSSing (25 m save-time now). The problem is not so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). Other calculations need the more extreme precision. I think I can make 128-bit floats work, and would really like to see a small, fast, boxed 128-bit float implementation in Pharo or VW. The APFs are big and slow. Where in the queue of planned improvements to Pharo does such a task lie? I suspect itâs not a very popular item. Broadening the issue somewhat, Iâm trying to find as many good reasons as possible to justify the work needed to port all my VW stuff to Pharo. Iâve seen the references to Cogâs speed and coming speed-up. Are there recent (say, in the last year) benchmarks comparing VW and Pharo? Any details here would be very much appreciated. Having no namespaces in Pharo is, I think, the biggest impediment. I prefer not to prefix class names, but there may be fewer name-collisions than I suppose--maybe none. Still, I need to know how VW and Pharo classes map in order to place overrides and extensions correctly. Besides the mentioned float-class mappings is there a reference on this? Object allSubclasses in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than it used to be. I suppose I donât need to check all unloaded packages because all classes in each of those will have the same unique prefix. Is that correct? Or, I could just load every package I can find, before I check names. But that little experiment has never gone well in the past. Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more fitting idea than what VW currently offers? Shaping On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: STON is able to serialise Pharoâs Floats, what do you mean by double ? Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with a range between =10^307 and 10^307. Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). APFs are binary representations that can be arbitrarily large, using Integers (LargePositiveIntegers for example) to model the bits of the mantissa. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. â¦.. Number subclass: #Float instanceVariableNames: '' classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree Sqrt2 ThreePi Twopi' poolDictionaries: '' category: 'Kernel-Numbers' My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307. Some valid examples are: 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 â¦. I see that Pharoâs Float is VWâs Double. So then I just need to be able to serialize APF. â¦. FIFloatType subclass: #FFIFloat128 instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'UnifiedFFI-Types' I'm a 128bits (cuadruple precision) float. It is usually not used, but some compiler modes support it (__float128 in gcc) THIS IS NOT YET SUPPORTED â¦. The class above is also from the Pharo 7 image. This is the largest of the c-type FFIFloats. Any Float classes of this size and larger for the Smalltalk heap on 64-bit Pharo? Cheers, Shaping Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > a Ã©crit : (Having domain problems recently. Please excuse this posting if you have seen it twice. I've not seen it appear yet on the list.) Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Shaping -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of David T. Lewis Sent: Wednesday, October 31, 2018 14:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification This is very clear and well written. Dave Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc cessfulBuild/artifact/book-result/STON/STON.html Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,,,^..^,,,_ best, Eliot

Nov. 19, 2018

[Pharo 7.0-dev] Build #1405: 22643-Image-not-opening---portability-

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

There is a new Pharo build available! The status of the build #1405 was: SUCCESS. The Pull Request #1996 was integrated: "22643-Image-not-opening---portability-" Pull request url: https://github.com/pharo-project/pharo/pull/1996 Issue Url: https://pharo.fogbugz.com/f/cases/22643 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2018

Esteban's ChangeLog week of 12 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 12 November 2018 to 18 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=12/11/2018&to=18/11/2018 ChangeLog ========= 16 November 2018: ----------------- * I made a [pull request](https://github.com/pharo-project/pharo/pull/1998) to update Calypso to [version 0.13.0](https://github.com/pharo-ide/Calypso/releases/tag/v0.13.0) 14 November 2018: ----------------- * I needed to revisit [case: 22659](https://pharo.fogbugz.com/f/cases/22659) (and it took last two days to fix it properly :P) But well, now we should be having correct file names for all versions. 13 November 2018: ----------------- * I fixed [case: 22659](https://pharo.fogbugz.com/f/cases/22659), with this [pull request](https://github.com/pharo-project/pharo/pull/1975). Problem was that tagging system was correctly naming version inside the image, but it was not doing anything with file names (then the filenames were hardcoded to Pharo7.0-alpha). cheers! Esteban

Nov. 19, 2018

Re: [Pharo-dev] [ANN] Camp Smalltalk 2019 in Charlotte, NC

by Mariano Martinez Peck

Itâs in the same state as the organizers (us) and we already did one in Raleigh Durham. This is also a location with an international airport. Hope you can attend.. On Sun, Nov 18, 2018, 17:29 Sean P. DeNigris <sean(a)clipperadams.com wrote: > Mariano Martinez Peck wrote > > Camp Smalltalk, March 29th... in Charlotte, North Carolina > > Cool! Out of curiosity, why Charlotte? (Not that it's not a great city!) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 18, 2018

Re: [Pharo-dev] [ANN] Camp Smalltalk 2019 in Charlotte, NC

by Sean P. DeNigris

Mariano Martinez Peck wrote > Camp Smalltalk, March 29th... in Charlotte, North Carolina Cool! Out of curiosity, why Charlotte? (Not that it's not a great city!) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 18, 2018

Re: [Pharo-dev] Windows lack of ssh-agent versus Default Custom SSH Keys

by Esteban Lorenzano

Hi, > On 18 Nov 2018, at 16:30, Ben Coman <btc(a)openinworld.com> wrote: > > For Iceberg. what is the likely hood that soon something like ssh-agent will be working on Windows? So that "Custom SSH Keys" doesn't need to be set every time a new image is started? Well, for âsomething like ssh-agentâ, we believe in fact we will need to implement the proper ssh provider for each platform. Means ssh-agent for linux. âSecurity Frameworkâ for Mac. And I donât know the name for Windows :S In theory, libgit2 allows to be compiled against this different ssh frameworks, but it will require some time and effort to get there (and to be honest, right no one who worked with iceberg has the time to do it). Butâ¦ since we are trying to improve support for windows platforms, it has to be there at some point. Esteban > > If "Custom SSH Keys" will be the main option for the foreseeable future, > would it make sense to enabled it by default to make one less thing to trip up newcomers? > > cheers -ben

Nov. 18, 2018

Windows lack of ssh-agent versus Default Custom SSH Keys

by Ben Coman

For Iceberg. what is the likely hood that soon something like ssh-agent will be working on Windows? So that "Custom SSH Keys" doesn't need to be set every time a new image is started? If "Custom SSH Keys" will be the main option for the foreseeable future, would it make sense to enabled it by default to make one less thing to trip up newcomers? cheers -ben

Nov. 18, 2018

[Pharo 7.0-dev] Build #1404: 22680-add-support-for-operation-types-assignment-return-Some-cleanups

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

There is a new Pharo build available! The status of the build #1404 was: SUCCESS. The Pull Request #2000 was integrated: "22680-add-support-for-operation-types-assignment-return-Some-cleanups" Pull request url: https://github.com/pharo-project/pharo/pull/2000 Issue Url: https://pharo.fogbugz.com/f/cases/22680 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 18, 2018

[Pharo 7.0-dev] Build #1403: Add pattern to #expandMacros supporting line feeds

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

There is a new Pharo build available! The status of the build #1403 was: SUCCESS. The Pull Request #1997 was integrated: "Add pattern to #expandMacros supporting line feeds" Pull request url: https://github.com/pharo-project/pharo/pull/1997 Issue Url: https://pharo.fogbugz.com/f/cases/22674 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 16, 2018

[Pharo 7.0-dev] Build #1402: 22673-OCNewCompilerWithChangesFunctionalTeststestBlockReturning-is-failing

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

There is a new Pharo build available! The status of the build #1402 was: FAILURE. The Pull Request #1995 was integrated: "22673-OCNewCompilerWithChangesFunctionalTeststestBlockReturning-is-failing" Pull request url: https://github.com/pharo-project/pharo/pull/1995 Issue Url: https://pharo.fogbugz.com/f/cases/22673 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2018