Hi Shaping, On Mon, Nov 19, 2018 at 5:04 AM Shaping <shap...@uurda.org> wrote:
> (Second try in 6 days. Does anyone have recent performance data for Pharo > 7 relative to VW 7.10 or later?) > I don't have access to recent vnc versions beyond 7.7. If you have access perhaps you could run the computer language shootout benchmarks ( https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/smalltalk.html) and report the results. > > > *From:* Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] *On Behalf > Of *Shaping > *Sent:* Tuesday, November 13, 2018 00:33 > *To:* 'Pharo Development List' <pharo-dev@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:shap...@uurda.org <shap...@uurda.org>] > *Sent:* Wednesday, November 7, 2018 00:41 > *To:* 'Pharo Development List' <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 <shap...@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 <shap...@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-boun...@lists.pharo.org > <pharo-dev-boun...@lists.pharo.org>] On Behalf Of > David T. Lewis > Sent: Wednesday, October 31, 2018 14:58 > To: Pharo Development List <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 > -- _,,,^..^,,,_ best, Eliot
