August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can forking speed up anything?

by Frank Shearar

On 4 August 2014 09:38, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > 2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >> Hi guys, >> >> I have a script that runs very slow and does a lot of non dependent >> operation of a collection. I wander if I can speed it up by making it run in >> another process, because as far as I understand everything runs on a single >> thread, so I guess this wonât save me. >> > I don't think forking can speed up anything. But that's only because we're single-threaded, hence single-cored. If we had a VM that handle multiple threads (like if we resuscitated Andreas' and Igor's Hydra work), then forking _would_ speed things up. But that would raise another huge issue, namely the shared state nature of the image. So perhaps forking _would_ help if your computations were big enough to justify the cost of spinning up a clone image, like David Lewis' recent work. frank > Usually the best solution is to profile your operation with the Profiler, > then implement differently costly operations, either by removing > object/block creations in smalltalk if this is possible, else by > implementing costly operations in C and bind them like that: > http://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wit… > > > > >> >> Uko > >

Aug. 4, 2014

No projects on StHub?

by Yuriy Tymchuk

Hi, I was on vacation last weak, have I missed anything? Because my SmaltalkHub user does not have any projects http://smalltalkhub.com/#!/~YuriyTymchuk (and I had a bunch of them). Uko

Aug. 4, 2014

Re: [Pharo-dev] Can forking speed up anything?

by ClÃ©ment Bera

2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, > > I have a script that runs very slow and does a lot of non dependent > operation of a collection. I wander if I can speed it up by making it run > in another process, because as far as I understand everything runs on a > single thread, so I guess this wonât save me. > > I don't think forking can speed up anything. Usually the best solution is to profile your operation with the Profiler, then implement differently costly operations, either by removing object/block creations in smalltalk if this is possible, else by implementing costly operations in C and bind them like that: http://clementbera.wordpress.com/2013/06/19/optimizing-pharo-to-c-speed-wit… > Uko >

Aug. 4, 2014

Re: [Pharo-dev] About https://pharo.fogbugz.com/f/cases/2489

by stepharo

Ok so I added the missing exception and we can use the system again.... but the fix is just a patch. I will try to get some time this week to fix it but this is in character scanner...... stringIndex: anInteger text: aText topLeft: topLeft extent: extent stringIndex := anInteger. text := aText. super setOrigin: topLeft ------> (11@0) corner: topLeft ------>(11@0) + extent------> (-1@21) leads to a problem Stef On 4/8/14 09:54, stepharo wrote: > So apparently if I introduce the missing exception (that we should > have removed) the system works. > I will try to do a new integration and after we will fix the problem > with igor. > If I cannot integrate them I will see tomorrow with esteban. > > Stef > >

Aug. 4, 2014

Can forking speed up anything?

by Yuriy Tymchuk

Hi guys, I have a script that runs very slow and does a lot of non dependent operation of a collection. I wander if I can speed it up by making it run in another process, because as far as I understand everything runs on a single thread, so I guess this wonât save me. Uko

Aug. 4, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40151 Home: https://github.com/pharo-project/pharo-core

Aug. 4, 2014

[pharo-project/pharo-core] 59f46a: 40151

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 59f46ae2e98655799a7c05db47e39ac8f911a55c https://github.com/pharo-project/pharo-core/commit/59f46ae2e98655799a7c05db… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-04 (Mon, 04 Aug 2014) Changed paths: A Kernel.package/DegeneratedRectangle.class/README.md A Kernel.package/DegeneratedRectangle.class/definition.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script151.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40151.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40151 2489 Strange behavior of Rectangle https://pharo.fogbugz.com/f/cases/2489 Little fix to continue moving. http://files.pharo.org/image/40/40151.zip

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Nicolai Hess

2014-08-04 9:57 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 04 Aug 2014, at 9:31 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-08-04 8:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> >> On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > >> > >> > Right, current hash is bad and long to compute. >> > >> > I think we should use instead >> > BasicIndexedEyeElement >> hash >> > ^ index hashMultiply >> > >> > host identityHash and index hash may lead to many collisions... >> > What do you think ? >> > >> >> I agree thereâs not much value in including host in the hash for the use >> case of the icon lookup cache, since those were per host anyways (iirc). >> Index hash will be a sequential number, I havenât checked the usage >> closely to see if itâll be a problem wrt. collisions, but removal at least >> might be slow (if thatâs ever done) due to lots of scanning needed to find >> the nil slot. Using hashMultiply seems a good precaution. >> >> Cheers, >> Henry >> > > > And as far as I know, the icon lookup isn't needed for the inspector, as > it does not show any icons at all! > > > Well, it still needs to figure out there is no icon to be displayed for > the entryâ¦ > In that process, it caches the result (nil), and that cache is too > expensive to query later on, due to the expensive hash calculation needed > to find an entry. > > Cheers, > Henry > Thats the reason I created the issue 13315 NewList without icons (13315 <https://pharo.fogbugz.com/default.asp?13315>) We need a way to tell NewList to not use and therefore don't try to lookup icons, if the client (the inspector) don't provide any icons at all. Maybe NewList should not hold an icon cache at all, but rely on the icon provider for proper caching. Nicolai

Aug. 4, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Henrik Johansen

On 04 Aug 2014, at 9:31 , Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-04 8:50 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 03 Aug 2014, at 5:55 , ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > > > > Right, current hash is bad and long to compute. > > > > I think we should use instead > > BasicIndexedEyeElement >> hash > > ^ index hashMultiply > > > > host identityHash and index hash may lead to many collisions... > > What do you think ? > > > > I agree thereâs not much value in including host in the hash for the use case of the icon lookup cache, since those were per host anyways (iirc). > Index hash will be a sequential number, I havenât checked the usage closely to see if itâll be a problem wrt. collisions, but removal at least might be slow (if thatâs ever done) due to lots of scanning needed to find the nil slot. Using hashMultiply seems a good precaution. > > Cheers, > Henry > > > And as far as I know, the icon lookup isn't needed for the inspector, as it does not show any icons at all! Well, it still needs to figure out there is no icon to be displayed for the entryâ¦ In that process, it caches the result (nil), and that cache is too expensive to query later on, due to the expensive hash calculation needed to find an entry. Cheers, Henry

Aug. 4, 2014

Re: [Pharo-dev] About https://pharo.fogbugz.com/f/cases/2489

by stepharo

So apparently if I introduce the missing exception (that we should have removed) the system works. I will try to do a new integration and after we will fix the problem with igor. If I cannot integrate them I will see tomorrow with esteban. Stef

Aug. 4, 2014