May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-fuel] (Identity)Dictionary benchmarks
by Max Leske May 21, 2013

May 21, 2013

On 21.05.2013, at 10:58, Camillo Bruni <camillobruni(a)gmail.com> wrote: > my random pessimistic comments > > a) your benchmarking script sucks! => use SMARK!! http://smalltalkhub.com/#!/~StefanMarr/SMark We're fully aware of that :) > b) check my master thesis for a more thorough testing of dictionary, including a cleaner implementation that defaults to something like a small dictionary without a special class: http://scg.unibe.ch/archive/masters/Brun11a.pdf > > the optimistic version: > > > On 2013-05-21, at 09:47, Max Leske <m.leske(a)netstyle.ch> wrote: > >> My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: >> 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. > > yes their usage is not always justified, but be careful what you measure: as far as I see you only measure addition, no? (sorry again, but that benchmark brutally sucks, it's so damn hard to read... :P). Iteration and retrieval have to measure as well, also how the dictionaries behave under key hash collisions (though I am definitely not defending the small dicts.. :). > >> 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections > > THere is the pluggable key dictionary for that reason already, no? The main problem is the limited hashes which results in quite some hash collisions for very large dictionaries. > >> 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). > > that is really strange :/ > >> 4. Arrays are cool :) >> >> Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. >> >> You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. >> >> Cheers, >> Max >> >>> >> <performance.xlsx> >>> >>> >> <performance.xls> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> >>> ( comments are variations) >>> >>> sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). >>> "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." >>> "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." >>> batches := sizes collect: [ :size | size -> 10000 ]. >>> alphabet := Character alphabet. >>> >>> batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. >>> batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. >>> "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " >>> { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } >>> "{ Array }" >>> do: [ :class | >>> Smalltalk garbageCollect. >>> Transcript show: class name. >>> batches >>> do: [ :a | >>> | struct strings iterations | >>> "strings := (1 to: a key) collect: [ :i | i asString ]." >>> strings := (1 to: a key) collect: [ :i | >>> String streamContents: [ :s | >>> 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. >>> struct := class new. >>> "struct := (class = FLLargeIdentityDictionary >>> ifTrue: [ class new ] >>> ifFalse: [ class new: a key ])." >>> Transcript tab; show: ([ >>> a value timesRepeat: [ >>> 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). >>> strings := nil ] >>> displayingProgress: class name asString. >>> Transcript cr. ] >>> displayingProgress: 'Processing ...' >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

3 3

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31
by Stephan Eggermont May 21, 2013

May 21, 2013

Hi, I've worked a bit with Dusty & Diego on LightHouse, the Distributed Issue Tracker. Here is a short video of the current state of the project: http://www.youtube.com/watch?v=g_Q1DeeEiAQ Source can be found on Smalltalkhub, DiegoLont/LightHouse Stephan

1 0

[update 3.0] #30152
by Esteban Lorenzano May 21, 2013

May 21, 2013

30152 ----- 10478 Add Symbol >> #asClass https://pharo.fogbugz.com/f/cases/10478 10705 Safer NativeBoost usage https://pharo.fogbugz.com/f/cases/10705 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-EstebanLorenza… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-EstebanLorenzano… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-EstebanLorenz…

1 0

[Fuel] [FuelMetaLevel] Help
by roberto.minelli＠usi.ch May 21, 2013

May 21, 2013

Hi, I am using Fuel to serialize/deserialize some objects. As part as the objects I need to serialize there are some classes, class definitions (i.e., Ring) and some CompiledMethod. It's not always the case that I serialize and materialize in the same image, thus sometimes I experience FLClassNotFound and FLMerthodChanged exceptions. I discovered FuelMetaLevel, as far as I can understand, it can solve many problems. Now my questions are (1) am I correct that it can help? and (2) from which repository should I load FuelMetaLevel? As far as I understood not Fuel is developed as part of Pharo so it's pre-installed in every fresh image. I tried to get FuelMetaLevel from ss3 (both Pharo20 and PharoInbox) but when I run FLSerializer newFull serialize: 'whatever' toFileNamed: 'whatever.fuel' I got a MNU on FLFullGlobalMapper>>#initializeWithInternalBehaviors:internalMethods:globalSymbols: since the class FLGlobalAssociationCluster is not part of my image. I'm attaching the stack trace of the error I'm getting. Thanks in advance, RM > UndefinedObject(Object)>>doesNotUnderstand: #newAnalyzing > FLFullGlobalMapper>>initializeWithInternalBehaviors:internalMethods:globalSymbols: > FLFullGlobalMapper class>>newWithInternalBehaviors:internalMethods:globalSymbols: > FLAnalyzer>>fullGlobalMappers > FLAnalyzer>>useFullMappers in Block: [self fullGlobalMappers] > FLAnalyzer>>globalMappers > FLAnalyzer>>mappers > FLAnalyzer>>firstInMapperChain > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... > FLAnalyzer>>analysisFor: > FLSerialization>>analysisStep > FLSerialization>>run > FLSerializer>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... > FLSerializer>>serialize:on: in Block: [:anEncoder | ... > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] > BlockClosure>>ensure: > FLEncoder class>>on:globalEnvironment:do: > FLSerializer>>serialize:on: > FLSerializer>>serialize:toFileNamed: in Block: [:aFileStream | ... > StandardFileStream class(FileStream class)>>detectFile:do: in Block: [anotherBlock value: file] > BlockClosure>>ensure: > StandardFileStream class(FileStream class)>>detectFile:do: > StandardFileStream class(FileStream class)>>forceNewFileNamed:do: > FLSerializer>>serialize:toFileNamed: > UndefinedObject>>DoIt > Compiler>>evaluate:in:to:notifying:ifFail:logged: > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... > BlockClosure>>on:do: > SmalltalkEditor>>evaluateSelectionAndDo: > SmalltalkEditor>>evaluateSelection >

3 3

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31
by Gareth Cox May 21, 2013

May 21, 2013

It is a new project to help with workflow for developers in Pharo. The idea is a Distributed Issue Tracker, so you can keep track of your own issues, for your own projects, in your own image. The link is to the proposal for the GSoC 2013! So go vote! -Dusty >What is LightHouse? :) >Doru >On Tue, May 21, 2013 at 2:14 PM, Gareth Cox <gareth(a)inspired.org> wrote: > ### Here's what I've been up to since the last WhatsUp: > > LightHouse > -Learning Glamour > -Started new project with Stephan Eggermont and Diego Lont as part of GSoC. > Project is a Distributed Issue Tracker built in Pharo for Pharo! > ( > https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/riv… > ) > > > ### What's next, until 2013-05-31 (*): > > LightHouse > -More Learning Glamour > -More working on LightHouse UI > > Dusty >

1 0

Removing a package from Smalltalkhub
by Roberto Minelli May 21, 2013

May 21, 2013

Hi, I was wondering if and how can I delete a package from Smalltalkhub. Thanks in avance, R

3 2

Re: [Pharo-dev] WhatsUp from: 2013-05-20 until: 2013-05-31
by Gareth Cox May 21, 2013

May 21, 2013

### Here's what I've been up to since the last WhatsUp: LightHouse -Learning Glamour -Started new project with Stephan Eggermont and Diego Lont as part of GSoC. Project is a Distributed Issue Tracker built in Pharo for Pharo! (https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/riv…) ### What's next, until 2013-05-31 (*): LightHouse -More Learning Glamour -More working on LightHouse UI Dusty

2 1

[update 3.0] #30151
by Esteban Lorenzano May 21, 2013

May 21, 2013

30151 ----- 5562 rename Morphic package to Morphic-Base https://pharo.fogbugz.com/f/cases/5562 old one, hard one :)

1 0

Printing of BlockClosures
by Sven Van Caekenberghe May 21, 2013

May 21, 2013

Hi, One of the things that always positively surprised me about Smalltalk was the fact that BlockClosures are printing showing their actual source code, you don't get that in many languages. But now this seems to be gone, maybe temporarily, from 3.0 [ :n | n + 1 ] => [â¦] Was this intentional ? Sven

3 4

Fwd: [Pharo-fuel] (Identity)Dictionary benchmarks
by Max Leske May 21, 2013

May 21, 2013

Begin forwarded message: > From: Camillo Bruni <camillobruni(a)gmail.com> > Subject: Re: [Pharo-fuel] (Identity)Dictionary benchmarks > Date: 21. Mai 2013 10:58:29 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > my random pessimistic comments > > a) your benchmarking script sucks! => use SMARK!! http://smalltalkhub.com/#!/~StefanMarr/SMark > b) check my master thesis for a more thorough testing of dictionary, including a cleaner implementation that defaults to something like a small dictionary without a special class: http://scg.unibe.ch/archive/masters/Brun11a.pdf > > the optimistic version: > > > On 2013-05-21, at 09:47, Max Leske <m.leske(a)netstyle.ch> wrote: > >> My coworker performed some interesting benchmarks on the various dictionary types in Pharo. If you look at the attachments you'll see four things: >> 1. SmallDictionary and SmallIdentityDictionary are totally useless when it comes to performance. Unless their existence is somehow justified by saving space (which might be important for embedded systems) I don't see why we should keep them around. > > yes their usage is not always justified, but be careful what you measure: as far as I see you only measure addition, no? (sorry again, but that benchmark brutally sucks, it's so damn hard to read... :P). Iteration and retrieval have to measure as well, also how the dictionaries behave under key hash collisions (though I am definitely not defending the small dicts.. :). > >> 2. The special Fuel collections for large numbers of elements could be a valuable addition to the basic collections > > THere is the pluggable key dictionary for that reason already, no? The main problem is the limited hashes which results in quite some hash collisions for very large dictionaries. > >> 3. SmallInteger>>identityHash is really slow. Using SmallInteger as keys in IdentityDictionary is significantly slower than using them in a regular Dictionary because the identity check is done via #identityHash (#hash simply answers self). > > that is really strange :/ > >> 4. Arrays are cool :) >> >> Should I open issues on FogBugz for any of these points? Especially point 3 bothers me because I feel that using a "primitive" type should be fast under all circumstances. >> >> You'll find below the benchmark data (collected in 1.4, verified in 2.0) and the code to run it. >> >> Cheers, >> Max >> >>> >> <performance.xlsx> >>> >>> >> <performance.xls> >>> >>> >>> >>> >>> >>> -------------------------------------------------------------- >>> >>> ( comments are variations) >>> >>> sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 ). >>> "sizes := #( 10 20 30 40 50 60 70 80 90 100 120 130 140 150 160 170 180 190 200 300 400 500 600 700 800 900 1000 1500 2000 2500 3000 3500 4000 4500 5000 6000 7000 8000 9000 10000 )." >>> "batches := sizes collect: [ :size | size -> ((10000000 / size) asFloat // 10) ]." >>> batches := sizes collect: [ :size | size -> 10000 ]. >>> alphabet := Character alphabet. >>> >>> batches do: [ :a | Transcript tab; show: a key asString ]. Transcript cr. >>> batches do: [ :a | Transcript tab; show: a value asString ]. Transcript cr. >>> "{ Dictionary. SmallDictionary. IdentityDictionary. SmallIdentityDictionary. FLLargeIdentityDictionary } " >>> { Dictionary. IdentityDictionary. FLLargeIdentityDictionary } >>> "{ Array }" >>> do: [ :class | >>> Smalltalk garbageCollect. >>> Transcript show: class name. >>> batches >>> do: [ :a | >>> | struct strings iterations | >>> "strings := (1 to: a key) collect: [ :i | i asString ]." >>> strings := (1 to: a key) collect: [ :i | >>> String streamContents: [ :s | >>> 20 atRandom timesRepeat: [ s nextPut: alphabet atRandom ] ] ]. >>> struct := class new. >>> "struct := (class = FLLargeIdentityDictionary >>> ifTrue: [ class new ] >>> ifFalse: [ class new: a key ])." >>> Transcript tab; show: ([ >>> a value timesRepeat: [ >>> 1 to: a key do: [ :i | struct at: (strings at: i)" i" put: i ] ] ] timeToRun). >>> strings := nil ] >>> displayingProgress: class name asString. >>> Transcript cr. ] >>> displayingProgress: 'Processing ...' >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

1 0