March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] software update again

by stepharo

-> GT is loaded via a Configuration. -> this load from the GT repo, *not* Pharo40. So this means that it looks in the wrong place I wonder why. Maybe we should copy the mcz files? This would be good anyway: all code of Pharo40 is in the Pharo40 repo. Marcus Yes!

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Nicolas Anquetil

On 17/03/2015 17:59, Stephan Eggermont wrote: > On 17/03/15 17:13, Eliot Miranda wrote: >> Hi Nicolas, >> Indeed it is. But remember that Java VMs are typically extremely >> efficient, employing aggressive optimization. What Java VM are you >> using? > > I was using an OpenSDK-7 on latest Ubuntu > same here: java-7-openjdk-amd64 >> >> But do not despair! We are working on it. Let me boil down your >> benchmark and measure it in Cog (the current standard VM) and Spur (the >> in-development improvement that should become the standard Pharo VM by >> Pharo 5). ClÃ©ment and I are also working on Sista, which is an adaptive >> optimizer for Cog/Spur that should further increase performance. > I am not despairing :-) I will look into the suggestion of Sven and Phil with Binary Stream nicolas > I tried the code with the latest pharo-spur image and vm: > from 17 seconds down to 10.5 > > Stephan > > >

March 17, 2015

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

by stepharo

Could you Create an issue on the Pharo bugtracker Publish your changes in a slice in the inbox of Pharo so that we check if we can integrate them or not in Pharo 40? I'm sorry about what happened around Spec. We did not want to have a look a the github com because we did not want to fuel the nastiness of Ben. We are still insulted on the web page but I asked the lawyers not to react and let the story die. Stef Le 16/3/15 22:50, webwarrior a Ã©crit : > I made several commits to Spec > (https://github.com/spec-framework/spec/pull/15) shortly before the license > change. > I thought these changes would be merged into Pharo. However, they are not in > Pahro 4 as for now. Are there any problems? > > > > -- > View this message in context: http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

March 17, 2015

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

by Peter UhnÃ¡k

I am assuming requiring SpecTableLayout after it is incorporated into Spec? There is currently no configuration for spec since it is inside the image, so the only way would be to specify version of Pharo (i.e. it's incorporated in version X, so the user needs at least Pharo X) or testing whether the class already exists. As for overriding behavior - loading a package would rewrite existing code. There may be some issues if you were to concurrently update both Spec and your package, and then the latest would win; but there may be better solution. Peter On Tue, Mar 17, 2015 at 5:24 PM, webwarrior <reg(a)webwarrior.ws> wrote: > Created issue in fogbugz. > > Also, if I decide to distribute a library that requires SpecTableLayout, > how > to do it properly? Basically most of changes are new classes (so may be > shipped in any package), but there is also a modification to existing > method > in SpecInterpreter. > > > > -- > View this message in context: > http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Stephan Eggermont

On 17/03/15 17:13, Eliot Miranda wrote: > Hi Nicolas, > Indeed it is. But remember that Java VMs are typically extremely > efficient, employing aggressive optimization. What Java VM are you using? I was using an OpenSDK-7 on latest Ubuntu > > But do not despair! We are working on it. Let me boil down your > benchmark and measure it in Cog (the current standard VM) and Spur (the > in-development improvement that should become the standard Pharo VM by > Pharo 5). ClÃ©ment and I are also working on Sista, which is an adaptive > optimizer for Cog/Spur that should further increase performance. I tried the code with the latest pharo-spur image and vm: from 17 seconds down to 10.5 Stephan

March 17, 2015

Re: [Pharo-dev] SpecTableLayout not in Pahro 4

by webwarrior

Created issue in fogbugz. Also, if I decide to distribute a library that requires SpecTableLayout, how to do it properly? Basically most of changes are new classes (so may be shipped in any package), but there is also a modification to existing method in SpecInterpreter. -- View this message in context: http://forum.world.st/SpecTableLayout-not-in-Pahro-4-tp4812428p4812633.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Thierry Goubier

2015-03-17 17:07 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > >> (ah, and that the comment is stored on the organisation is of course >> strange too...) >> > > Oh well... It has to be somewhere. Where would you put it? In the class > itself? > > > Maybe in some source code manager... that has the responsibility to hide the > whole > sources/changes stuff (and those direct reference to SourceFiles). > Good idea. With an indirection to make use of packages as well. > > But simple is often the best. why not just in the class? > I'd be ok with that solution too. > > What is clear is that the whole organziation is not needed anymore since > we have > Protocol. We can simplify a lot... > And clean all users of that stuff :) Thierry

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Eliot Miranda

Hi Nicolas, On Tue, Mar 17, 2015 at 2:19 AM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr > wrote: > > Eliot, Sven, Stephan, > > thank you for your answers. > > As you noticed I am not an expert in profiling :-) > > it seems now I might have goofed up and the time taken by pharo in my > initial program (compared to java) is due to some other extra compilation I > was doing. > > So the "macro benchmark" might be wrong > > Still the "micro benchmark" still holds > I tested the code proposed by Elliot and the result is .... > > --- > [1 to: 10 do: [:j || a length | > length:=0. > a := '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' > asFileReference readStream contents. > 1 to: a size do: [ :i| | c | c:= a at: i. length:= length+1]]] > timeToRunWithoutGC > --- > > 12.723 sec. > > [reminder] For java it is: 1.482 sec. > > so it is still a factor 8 or 9 > it seems a lot for such a simple thing, no? > (or maybe not, I don't know) Indeed it is. But remember that Java VMs are typically extremely efficient, employing aggressive optimization. What Java VM are you using? But do not despair! We are working on it. Let me boil down your benchmark and measure it in Cog (the current standard VM) and Spur (the in-development improvement that should become the standard Pharo VM by Pharo 5). ClÃ©ment and I are also working on Sista, which is an adaptive optimizer for Cog/Spur that should further increase performance. [| a n | a := String new: 10 * 1024 * 1024. n := 0. 1 to: a size do: [:i| | c | c := a at: i. n := n + 1]] bench Cog: '1.99 per second. 502 milliseconds per run.' Spur: '12.2 per second. 82.1 milliseconds per run.' [| a n | a := String new: 10 * 1024 * 1024. n := 0. 1 to: a size do: [:i| n := n + 1]] bench Cog: '2.93 per second. 341 milliseconds per run.' Spur: '23.8 per second. 42.1 milliseconds per run.' Now the Java VM's optimizer is probably able to eliminate the at:, so we would expect it to run "| c | c := a at: i. n := n + 1" at the same speed as it runs "n := n + 1". We expect Sista will be able to perform the same optimization. P.S. Of course, a programmer is able to realise that the above computation is equivalent to a := String new: 10 * 1024 * 1024. a size + 1 * (a size / 2) ;-) > > nicolas > > > On 16/03/2015 09:49, Nicolas Anquetil wrote: > >> I have been doing some file intensive activities and found my program to >> be VERY slow (see at the end). >> Just to be sure I ran them in Java and found it was much faster >> >> So I did a small test: >> --- >> [10 timesRepeat: [i := 0. >> '/home/anquetil/Documents/RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse' >> asFileReference readStream contents do: [ :c | i:= i+1]. >> ] ] timeToRunWithoutGC. >> --- >> >> result = 12.932 sec >> >> similar thing (as far as I can tell) 10 times in java: 1.482 sec. >> --- >> public static void main(String[] args) { >> int length =0; >> try { >> String filename = "/home/anquetil/Documents/ >> RMod/Tools/workspace/Blocks/jfreechart-0_9_0.mse"; >> String content = new String(Files.readAllBytes(Paths.get(filename)), >> "UTF8"); >> for (int i=0; i < content.length(); i++) { >> content.charAt(i); >> length = length+1; >> } >> } catch (IOException e) { >> e.printStackTrace(); >> } >> System.out.println(length); >> } >> --- >> >> Because my program is MUCH slower (see at the end) in Smalltalk than in >> Java, I did another experiment: >> >> --- >> [1 to: 10 do: [:i| 1 to: 100000000 do: [:j | String new] ] ] >> timeToRunWithoutGC. >> --- >> >> result = 33.063 sec >> >> and in java: 4.382 sec. >> ---[10 runs of] >> public static void main(String[] args) { >> for (int i=0; i < 100000000; i++) { >> new String(); >> } >> } >> --- >> >> >> >> >> Concretly, my need was: >> Take 2600 methods in a Moose model, take their source code (therefore >> reading files), for methods longer than 100 lines (there are 29 of them), >> go through there code to find the blocks (matching {}). >> In smalltalk it ran > 12hours and I had processed 5 methods of the 29 >> long ones >> I reimplemented in Java (basically, just changing from pharo to java >> syntax) and it took 1 minutes to compute everything ... >> >> :-( >> >> On the good side, it was much easier to program it in smalltalk (about >> half a day to think about the algorithm, experiement, implement, test) than >> in Java (another 1/2 day, just to recode the algorithm that already worked). >> >> nicolas >> >> > > -- best, Eliot

March 17, 2015

Re: [Pharo-dev] pharo vs. java

by Sven Van Caekenberghe

> On 17 Mar 2015, at 16:29, phil(a)highoctane.be wrote: > > Still, your implementation isn't loading the whole contents as the Java version does. Well, your third piece of code, which uses StandardFileStream, does not do any UTF-8 decoding either. It uses FileStream>>#contents, like my binary stream (ByteArray and ByteString are interchangeable at this level). Anyway, our conclusion is the same.

March 17, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] c2785a: 40562

by Marcus Denker

> > > (ah, and that the comment is stored on the organisation is of course strange tooâ¦) > > Oh well... It has to be somewhere. Where would you put it? In the class itself? > Maybe in some source code managerâ¦ that has the responsibility to hide the whole sources/changes stuff (and those direct reference to SourceFiles). But simple is often the best. why not just in the class? What is clear is that the whole organziation is not needed anymore since we have Protocol. We can simplify a lot... Marcus

March 17, 2015