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

Reply via email to