- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can we make this fast ?

by phil＠highoctane.be

Le 18 nov. 2014 22:52, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > > On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > >> See > >> https://news.ycombinator.com/item?id=8625280 > >> > >> [ (1 to: 100000000) sum ] timeToRun > >> > >> Here we get out of the SmallInteger range... > >> > >> Apart FFI'ing the thing, do we have other options? > >> > >> Phil > > Choose a better algorithm: > > [100000000 * 10000001 / 2] timeToRun > > should beat yours by several orders of magnitude. > > > > Andreas > > Haha, great ! > > Sure cool. Now Pharo is slow on these loops with arithmetics and it is painful. Eliot, why is a class variable faster? Alex, I'll a look at OpenCL. Also, I tried with a whileTrue: loop which was 3 times faster than the sum on Collection. How to profile these kinds of tight loops? The standard profiler is kind of useless. Is AndreasProfiler the way to go? Phil

Nov. 18, 2014

Re: [Pharo-dev] Merge conflict for "META Case: restructure Tests and test packages"

by Nicolai Hess

2014-11-18 23:00 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Nicolai, > > For https://pharo.fogbugz.com/f/cases/14427 (renaming CompressionTests) > and https://pharo.fogbugz.com/f/cases/14426 (BaloonTests) it worked > without a problem. > yes? there are still merge conflicts (for the monkey). > > For others I got the mentioned merge conflict now from the monkey > validation. > > I tried manually using Monticello tools and it seems that the manual merge > fails in 40374 because PSMCChangesGrouper #visitClassTraitDefinition: gives > a DNU which another problem. > But not for all. (I saw this on other slices too, some time ago.) > > I opened a new issue for this: > > https://pharo.fogbugz.com/f/cases/14494/PSMCChangesGrouper-is-missing-visit… > > and I provide a naive fix. > > If possible someone should review #14494 or help with the others. Anyone > some Banana to feed to the monkey? > > Thx > T. > > > Gesendet: Dienstag, 18. November 2014 um 22:50 Uhr > Von: "Nicolai Hess" <nicolaihess(a)web.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: "Torsten Bergmann" <astares(a)gmx.de> > Betreff: Merge conflict for "META Case: restructure Tests and test > packages" > > for example : > https://pharo.fogbugz.com/default.asp?14433[https://pharo.fogbugz.com/defau… > I don't why there is a merge conflict, maybe it is how the slice is > created.I think the restructuring (moving all classes from > XXXTest to XXX-Tests) would work if we delete the empty XXXTests package > before > creating the slice. > > nicolai >

Nov. 18, 2014

Re: [Pharo-dev] Merge conflict for "META Case: restructure Tests and test packages"

by Torsten Bergmann

Hi Nicolai, ForÂ https://pharo.fogbugz.com/f/cases/14427Â (renaming CompressionTests) and https://pharo.fogbugz.com/f/cases/14426 (BaloonTests)Â it worked without a problem. For others I got the mentioned merge conflict now from the monkey validation.Â I tried manually using Monticello tools and it seems that the manual merge fails in 40374 because PSMCChangesGrouper #visitClassTraitDefinition: gives a DNU which another problem. I opened a new issue for this: https://pharo.fogbugz.com/f/cases/14494/PSMCChangesGrouper-is-missing-visit… and I provide a naive fix.Â If possible someone should review #14494 or help with the others. Anyone some Banana to feed to the monkey? Â Thx T. Â Gesendet:Â Dienstag, 18. November 2014 um 22:50 Uhr Von:Â "Nicolai Hess" <nicolaihess(a)web.de> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Cc:Â "Torsten Bergmann" <astares(a)gmx.de> Betreff:Â Merge conflict for "META Case: restructure Tests and test packages" for example : https://pharo.fogbugz.com/default.asp?14433[https://pharo.fogbugz.com/defau… Â I don't why there is a merge conflict, maybe it is how the slice is created.I think the restructuring (moving all classes from XXXTest to XXX-Tests) would work if we delete the empty XXXTests package before creating the slice. nicolai

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Sven Van Caekenberghe

> On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: >> See >> https://news.ycombinator.com/item?id=8625280 >> >> [ (1 to: 100000000) sum ] timeToRun >> >> Here we get out of the SmallInteger range... >> >> Apart FFI'ing the thing, do we have other options? >> >> Phil > Choose a better algorithm: > [100000000 * 10000001 / 2] timeToRun > should beat yours by several orders of magnitude. > > Andreas Haha, great !

Nov. 18, 2014

Merge conflict for "META Case: restructure Tests and test packages"

by Nicolai Hess

for example : https://pharo.fogbugz.com/default.asp?14433 I don't why there is a merge conflict, maybe it is how the slice is created. I think the restructuring (moving all classes from XXXTest to XXX-Tests) would work if we delete the empty XXXTests package before creating the slice. nicolai

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Eliot Miranda

On Tue, Nov 18, 2014 at 1:12 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > See > https://news.ycombinator.com/item?id=8625280 > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > We're planning to have a Spur 64-bit system next year. Sista will inline the block in sum. But it's hardly representative. It's a constant. If performance is important, put it in a class variable. What do you really want to go fast? -- best, Eliot

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Andreas Wacknitz

Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > See > https://news.ycombinator.com/item?id=8625280 > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > > Phil Choose a better algorithm: [100000000 * 10000001 / 2] timeToRun should beat yours by several orders of magnitude. Andreas

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Alexandre Bergel

Yes, you can use OpenCL. There is a bridge Pharo<â> OpenCL made by Ronie, available on smalltalkhub. Ronie has also been working on a DSL to easily write OpenCL applications. This is cool stuff! Have a look! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 18, 2014, at 6:12 PM, phil(a)highoctane.be wrote: > > See > https://news.ycombinator.com/item?id=8625280 <https://news.ycombinator.com/item?id=8625280> > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > > Phil

Nov. 18, 2014

Can we make this fast ?

by phil＠highoctane.be

See https://news.ycombinator.com/item?id=8625280 [ (1 to: 100000000) sum ] timeToRun Here we get out of the SmallInteger range... Apart FFI'ing the thing, do we have other options? Phil

Nov. 18, 2014

Pharo contributions server gone

by Torsten Bergmann

https://ci.inria.fr/pharo-contribution Restart?

Nov. 18, 2014