(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@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@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@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@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@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