November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by phil＠highoctane.be

Tudor, Igor still has a point here. I was talking yesterday with a data science guy and he was indeed more interested in lamenting than working out solutions for his problems. Which weren't that hard to begin with as all it took is an hour of work to get his results. But I think he felt better complaining and self aggrandizing than actually making things work and move on to the next challenge. Example of his "issues": Him:"I have a looooot of data" Me: "Like what, more or less than 1TB?" Him: "Less than that" Me: "kay, can you give me a sample set of this hard disk?" Him: "Yeah, but no, well, I need to get it first" Me: "Let's sit tomorrow over lunch so that we can ingest it all and work it out" Him: "Let me come back to you..." I think he was more interested in uttering things like "Spark 2.0" "Lots of data" "Star schema" (and saying it loud so that people could hear it) than solving anything real. Overgeneralizing yes, speaking down, heh, not so much. There are indeed super smart/efficient/effective people in data science. But there is also a crowd that is quite, how to say... more interested in the Egyptian-style grand priest status than in the actual problems. Phil On Thu, Nov 10, 2016 at 7:27 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Please refrain from speaking down on people. > > If you have a concrete solution for how to do things, please feel free to > share it with us. We would be happy to learn from it. > > Cheers, > Tudor > > > > On Nov 10, 2016, at 4:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > Nice progress, indeed. > > Now i hope at the end of the day, the guys who doing data > mining/statistical analysis will finally shut up and happily be able > > to work with more bloat without need of learning a ways to properly > manage memory & resources, and implement them finally. > > But i guess, that won't be long silence, before they again start > screaming in despair: please help, my bloat doesn't fits into memory... :) > > > > On 9 November 2016 at 12:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > OK, I am quite excited about the future possibilities of 64-bit Pharo. > So I played a bit more with the current test version [1], trying to push > the limits. In the past, it was only possible to safely allocate about > 1.5GB of memory even though a 32-bit process' limit is theoretically 4GB > (the OS and the VM need space too). > > > > Allocating a couple of 1GB ByteArrays is one way to push memory use, but > it feels a bit silly. So I loaded a bunch of projects (including Seaside) > to push the class/method counts (7K classes, 100K methods) and wrote a > script [2] that basically copies part of the class/method metadata > including 2 copies of each's methods source code as well as its AST > (bypassing the cache of course). This feels more like a real object graph. > > > > I had to create no less than 7 (SEVEN) copies (each kept open in an > inspector) to break through the mythical 4GB limit (real allocated & used > memory). > > > > <Screen Shot 2016-11-09 at 11.25.28.png> > > > > I also have the impression that the image shrinking problem is gone > (closing everything frees memory, saving the image has it return to its > original size, 100MB in this case). > > > > Great work, thank you. Bright future again. > > > > Sven > > > > PS: Yes, GC is slower; No, I did not yet try to save such a large image. > > > > [1] > > > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > > > > [2] > > > > | meta | > > ASTCache reset. > > meta := Dictionary new. > > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > > (classMeta := Dictionary new) > > at: #name put: each name asSymbol; > > at: #comment put: each comment; > > at: #definition put: each definition; > > at: #object put: each. > > methods := Dictionary new. > > classMeta at: #methods put: methods. > > each methodsDo: [ :method | | methodMeta | > > (methodMeta := Dictionary new) > > at: #name put: method selector; > > at: #source put: method sourceCode; > > at: #ast put: method ast; > > at: #args put: method argumentNames asArray; > > at: #formatted put: method ast formattedCode; > > at: #comment put: (method comment ifNotNil: [ :str | str > withoutQuoting ]); > > at: #object put: method. > > methods at: method selector put: methodMeta ]. > > meta at: each name asSymbol put: classMeta ]. > > meta. > > > > > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of > reality." > > >

Nov. 10, 2016

Re: [Pharo-dev] macOS Sierra support

by Esteban Lorenzano

the regular download by zeroconf should give you an usable VM. Those CI jobs are not the official place where to take VMsâ¦ and they do not build the actual branch for the moment. In fact, I will disable the jobs because there is no point on keep then running atm and people got confused. Esteban > On 10 Nov 2016, at 00:56, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Max Leske wrote >> on Sierra... If you need a Cog VM > > Do we have a Cog VM that works on Sierra yet? I downloaded 547 from > https://ci.inria.fr/pharo/view/5.0-VM-Legacy/job/PharoVM/Architecture=32,Sl… > . The application window opened, but the contents were all white (e.g. the > World never appeared) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/macOS-Sierra-support-tp4917181p4922435.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

On 10 November 2016 at 07:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Igor, > > Please refrain from speaking down on people. > > Hi, Doru! I just wanted to hear you :) > If you have a concrete solution for how to do things, please feel free to > share it with us. We would be happy to learn from it. > > Well, there's so many solutions, that i even don't know what to offer, and given the potential of smalltalk, i wonder why you are not employing any. But in overall it is a quesition of storing most of your data on disk, and only small portion of it in image (in most optimal cases - only the portion that user sees/operates with). As i said to you before, you will hit this wall inevitably, no matter how much memory is available. So, what stops you from digging in that direction? Because even if you can fit all data in memory, consider how much time it takes for GC to scan 4+ Gb of memory, comparing to 100 MB or less. I don't think you'll find it convenient to work in environment where you'll have 2-3 seconds pauses between mouse clicks. So, of course, my tone is not acceptable, but its pain to see how people remain helpless without even thinking about doing what they need. We have Fuel for how many years now? So it can't be as easy as it is, just serialize the data and purge it from image, till it will be required again. Sure it will require some effort, but it is nothing comparing to day to day pain that you have to tolerate because of lack of solution. > Cheers, > Tudor > > > > On Nov 10, 2016, at 4:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > Nice progress, indeed. > > Now i hope at the end of the day, the guys who doing data > mining/statistical analysis will finally shut up and happily be able > > to work with more bloat without need of learning a ways to properly > manage memory & resources, and implement them finally. > > But i guess, that won't be long silence, before they again start > screaming in despair: please help, my bloat doesn't fits into memory... :) > > > > On 9 November 2016 at 12:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > OK, I am quite excited about the future possibilities of 64-bit Pharo. > So I played a bit more with the current test version [1], trying to push > the limits. In the past, it was only possible to safely allocate about > 1.5GB of memory even though a 32-bit process' limit is theoretically 4GB > (the OS and the VM need space too). > > > > Allocating a couple of 1GB ByteArrays is one way to push memory use, but > it feels a bit silly. So I loaded a bunch of projects (including Seaside) > to push the class/method counts (7K classes, 100K methods) and wrote a > script [2] that basically copies part of the class/method metadata > including 2 copies of each's methods source code as well as its AST > (bypassing the cache of course). This feels more like a real object graph. > > > > I had to create no less than 7 (SEVEN) copies (each kept open in an > inspector) to break through the mythical 4GB limit (real allocated & used > memory). > > > > <Screen Shot 2016-11-09 at 11.25.28.png> > > > > I also have the impression that the image shrinking problem is gone > (closing everything frees memory, saving the image has it return to its > original size, 100MB in this case). > > > > Great work, thank you. Bright future again. > > > > Sven > > > > PS: Yes, GC is slower; No, I did not yet try to save such a large image. > > > > [1] > > > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > > > > [2] > > > > | meta | > > ASTCache reset. > > meta := Dictionary new. > > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > > (classMeta := Dictionary new) > > at: #name put: each name asSymbol; > > at: #comment put: each comment; > > at: #definition put: each definition; > > at: #object put: each. > > methods := Dictionary new. > > classMeta at: #methods put: methods. > > each methodsDo: [ :method | | methodMeta | > > (methodMeta := Dictionary new) > > at: #name put: method selector; > > at: #source put: method sourceCode; > > at: #ast put: method ast; > > at: #args put: method argumentNames asArray; > > at: #formatted put: method ast formattedCode; > > at: #comment put: (method comment ifNotNil: [ :str | str > withoutQuoting ]); > > at: #object put: method. > > methods at: method selector put: methodMeta ]. > > meta at: each name asSymbol put: classMeta ]. > > meta. > > > > > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of > reality." > > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Norbert Hartl

> Am 10.11.2016 um 07:27 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Igor, > > Please refrain from speaking down on people. +1 > If you have a concrete solution for how to do things, please feel free to share it with us. We would be happy to learn from it. > +10 Norbert > Cheers, > Tudor > > >> On Nov 10, 2016, at 4:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Nice progress, indeed. >> Now i hope at the end of the day, the guys who doing data mining/statistical analysis will finally shut up and happily be able >> to work with more bloat without need of learning a ways to properly manage memory & resources, and implement them finally. >> But i guess, that won't be long silence, before they again start screaming in despair: please help, my bloat doesn't fits into memory... :) >> >> On 9 November 2016 at 12:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> OK, I am quite excited about the future possibilities of 64-bit Pharo. So I played a bit more with the current test version [1], trying to push the limits. In the past, it was only possible to safely allocate about 1.5GB of memory even though a 32-bit process' limit is theoretically 4GB (the OS and the VM need space too). >> >> Allocating a couple of 1GB ByteArrays is one way to push memory use, but it feels a bit silly. So I loaded a bunch of projects (including Seaside) to push the class/method counts (7K classes, 100K methods) and wrote a script [2] that basically copies part of the class/method metadata including 2 copies of each's methods source code as well as its AST (bypassing the cache of course). This feels more like a real object graph. >> >> I had to create no less than 7 (SEVEN) copies (each kept open in an inspector) to break through the mythical 4GB limit (real allocated & used memory). >> >> <Screen Shot 2016-11-09 at 11.25.28.png> >> >> I also have the impression that the image shrinking problem is gone (closing everything frees memory, saving the image has it return to its original size, 100MB in this case). >> >> Great work, thank you. Bright future again. >> >> Sven >> >> PS: Yes, GC is slower; No, I did not yet try to save such a large image. >> >> [1] >> >> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ >> Image here: http://files.pharo.org/get-files/60/pharo-64.zip >> >> [2] >> >> | meta | >> ASTCache reset. >> meta := Dictionary new. >> Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | >> (classMeta := Dictionary new) >> at: #name put: each name asSymbol; >> at: #comment put: each comment; >> at: #definition put: each definition; >> at: #object put: each. >> methods := Dictionary new. >> classMeta at: #methods put: methods. >> each methodsDo: [ :method | | methodMeta | >> (methodMeta := Dictionary new) >> at: #name put: method selector; >> at: #source put: method sourceCode; >> at: #ast put: method ast; >> at: #args put: method argumentNames asArray; >> at: #formatted put: method ast formattedCode; >> at: #comment put: (method comment ifNotNil: [ :str | str withoutQuoting ]); >> at: #object put: method. >> methods at: method selector put: methodMeta ]. >> meta at: each name asSymbol put: classMeta ]. >> meta. >> >> >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > >

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Tudor Girba

Hi Igor, Please refrain from speaking down on people. If you have a concrete solution for how to do things, please feel free to share it with us. We would be happy to learn from it. Cheers, Tudor > On Nov 10, 2016, at 4:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Nice progress, indeed. > Now i hope at the end of the day, the guys who doing data mining/statistical analysis will finally shut up and happily be able > to work with more bloat without need of learning a ways to properly manage memory & resources, and implement them finally. > But i guess, that won't be long silence, before they again start screaming in despair: please help, my bloat doesn't fits into memory... :) > > On 9 November 2016 at 12:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > OK, I am quite excited about the future possibilities of 64-bit Pharo. So I played a bit more with the current test version [1], trying to push the limits. In the past, it was only possible to safely allocate about 1.5GB of memory even though a 32-bit process' limit is theoretically 4GB (the OS and the VM need space too). > > Allocating a couple of 1GB ByteArrays is one way to push memory use, but it feels a bit silly. So I loaded a bunch of projects (including Seaside) to push the class/method counts (7K classes, 100K methods) and wrote a script [2] that basically copies part of the class/method metadata including 2 copies of each's methods source code as well as its AST (bypassing the cache of course). This feels more like a real object graph. > > I had to create no less than 7 (SEVEN) copies (each kept open in an inspector) to break through the mythical 4GB limit (real allocated & used memory). > > <Screen Shot 2016-11-09 at 11.25.28.png> > > I also have the impression that the image shrinking problem is gone (closing everything frees memory, saving the image has it return to its original size, 100MB in this case). > > Great work, thank you. Bright future again. > > Sven > > PS: Yes, GC is slower; No, I did not yet try to save such a large image. > > [1] > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > > [2] > > | meta | > ASTCache reset. > meta := Dictionary new. > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > (classMeta := Dictionary new) > at: #name put: each name asSymbol; > at: #comment put: each comment; > at: #definition put: each definition; > at: #object put: each. > methods := Dictionary new. > classMeta at: #methods put: methods. > each methodsDo: [ :method | | methodMeta | > (methodMeta := Dictionary new) > at: #name put: method selector; > at: #source put: method sourceCode; > at: #ast put: method ast; > at: #args put: method argumentNames asArray; > at: #formatted put: method ast formattedCode; > at: #comment put: (method comment ifNotNil: [ :str | str withoutQuoting ]); > at: #object put: method. > methods at: method selector put: methodMeta ]. > meta at: each name asSymbol put: classMeta ]. > meta. > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Nov. 10, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Igor Stasenko

Nice progress, indeed. Now i hope at the end of the day, the guys who doing data mining/statistical analysis will finally shut up and happily be able to work with more bloat without need of learning a ways to properly manage memory & resources, and implement them finally. But i guess, that won't be long silence, before they again start screaming in despair: please help, my bloat doesn't fits into memory... :) On 9 November 2016 at 12:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > OK, I am quite excited about the future possibilities of 64-bit Pharo. So > I played a bit more with the current test version [1], trying to push the > limits. In the past, it was only possible to safely allocate about 1.5GB of > memory even though a 32-bit process' limit is theoretically 4GB (the OS and > the VM need space too). > > Allocating a couple of 1GB ByteArrays is one way to push memory use, but > it feels a bit silly. So I loaded a bunch of projects (including Seaside) > to push the class/method counts (7K classes, 100K methods) and wrote a > script [2] that basically copies part of the class/method metadata > including 2 copies of each's methods source code as well as its AST > (bypassing the cache of course). This feels more like a real object graph. > > I had to create no less than 7 (SEVEN) copies (each kept open in an > inspector) to break through the mythical 4GB limit (real allocated & used > memory). > > > I also have the impression that the image shrinking problem is gone > (closing everything frees memory, saving the image has it return to its > original size, 100MB in this case). > > Great work, thank you. Bright future again. > > Sven > > PS: Yes, GC is slower; No, I did not yet try to save such a large image. > > [1] > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > > [2] > > | meta | > ASTCache reset. > meta := Dictionary new. > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > (classMeta := Dictionary new) > at: #name put: each name asSymbol; > at: #comment put: each comment; > at: #definition put: each definition; > at: #object put: each. > methods := Dictionary new. > classMeta at: #methods put: methods. > each methodsDo: [ :method | | methodMeta | > (methodMeta := Dictionary new) > at: #name put: method selector; > at: #source put: method sourceCode; > at: #ast put: method ast; > at: #args put: method argumentNames asArray; > at: #formatted put: method ast formattedCode; > at: #comment put: (method comment ifNotNil: [ :str | str > withoutQuoting ]); > at: #object put: method. > methods at: method selector put: methodMeta ]. > meta at: each name asSymbol put: classMeta ]. > meta. > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-dev] macOS Sierra support

by Sean P. DeNigris

Max Leske wrote > on Sierra... If you need a Cog VM Do we have a Cog VM that works on Sierra yet? I downloaded 547 from https://ci.inria.fr/pharo/view/5.0-VM-Legacy/job/PharoVM/Architecture=32,Sl… . The application window opened, but the contents were all white (e.g. the World never appeared) ----- Cheers, Sean -- View this message in context: http://forum.world.st/macOS-Sierra-support-tp4917181p4922435.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 9, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Nicolas Cellier

2016-11-09 23:20 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I ran a similar test [1] on a 16GB Ubuntu box: > > # uname -a > Linux ubuntu-m-16gb-nyc3-01 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 > 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > # cat /etc/issue > Ubuntu 16.04.1 LTS > > # history | grep wget > 5 wget http://files.pharo.org/get-files/60/pharo-64.zip > 6 wget http://files.pharo.org/sources/PharoV50.sources.zip > 7 wget https://bintray.com/estebanlm/pharo-vm/download_file?file_ > path=pharo-linux-x86_64threaded.0a4ccdf.zip > > # ./bin/pharo -vm-display-null pharo-64.image st --quit memtest.st >& > out.log & > > Which gave the following (abbreviated) output: > > uptime 0h0m0s > memory 70,918,144 bytes > old 61,966,112 bytes (87.4%) > young 2,781,608 bytes (3.9000000000000004%) > I see yet another bad usage of round:/roundTo: --------------^ Ah, but it was another thread ;) > used 46,301,016 bytes (65.3%) > free 18,446,704 bytes (26.0%) > GCs 1 (207ms between GCs) > full 0 totalling 0ms (0.0% uptime) > incr 1 totalling 0ms (0.0% uptime), avg 0.0ms > tenures 0 > > > Iteration 1 > ... > > Iteration 8 > ... > > uptime 0h12m44s > memory 5,238,300,672 bytes > old 5,229,348,640 bytes (99.80000000000001%) > young 1,054,128 bytes (0.0%) > used 5,207,806,800 bytes (99.4%) > free 22,595,968 bytes (0.4%) > GCs 23,509 (33ms between GCs) > full 19 totalling 147,969ms > (19.400000000000002% uptime), avg 7787.8ms > incr 23490 totalling 143,396ms (18.8% uptime), avg > 6.1000000000000005ms > tenures 107,267,532 (avg 0 GCs/tenure) > Since last view 23,508 (33ms between GCs) > uptime 764.4000000000001s > full 19 totalling 147,969ms > (19.400000000000002% uptime), avg 7787.8ms > incr 23489 totalling 143,396ms (18.8% uptime), avg > 6.1000000000000005ms > tenures 107,267,532 (avg 0 GCs/tenure) > > # free -m > total used free shared buff/cache > available > Mem: 16047 4632 10647 3 768 > 11129 > Swap: 0 0 0 > > > So, yes, it works on Linux too. > > Sven > > [1] > > | meta hold | > > NonInteractiveTranscript stdout install. > > Transcript crShow: SmalltalkImage current vm statisticsReport; cr. > > hold := (1 to: 8) collect: [ :i | > > Transcript crShow: 'Iteration ', i asString. > > ASTCache reset. > meta := Dictionary new. > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > (classMeta := Dictionary new) > at: #name put: each name asSymbol; > at: #comment put: each comment; > at: #definition put: each definition; > at: #object put: each. > methods := Dictionary new. > classMeta at: #methods put: methods. > each methodsDo: [ :method | | methodMeta | > (methodMeta := Dictionary new) > at: #name put: method selector; > at: #source put: method sourceCode; > at: #ast put: method ast; > at: #args put: method argumentNames asArray; > at: #formatted put: method ast formattedCode; > at: #comment put: (method comment ifNotNil: [ :str | str withoutQuoting ]); > at: #object put: method. > methods at: method selector put: methodMeta ]. > meta at: each name asSymbol put: classMeta ]. > meta. > > ]. > > 3 timesRepeat: [ Smalltalk garbageCollect ]. > > Transcript crShow: SmalltalkImage current vm statisticsReport; cr. > > > On 9 Nov 2016, at 17:18, phil(a)highoctane.be wrote: > > Ok, I'll try that in the coming days on my desktop box. > I've got 32GB on that box, so it will be interesting. > > What would be a good way to stress test the GC? > > Phil > > On Wed, Nov 9, 2016 at 3:59 PM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > > > 2016-11-09 15:23 GMT+01:00 philippe.back(a)highoctane.be <philippe.back@ > gmail.com>: > Anyone having tested such 64 bit goodness on a Linux box? > > Only as a professional demo for code developped up to the very last moment > on Pharo 32 bits. So I didn't try to explose the available RAM on my laptop > (yet). > > Thierry > > > Phil > > > > >

Nov. 9, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Sven Van Caekenberghe

I ran a similar test [1] on a 16GB Ubuntu box: # uname -a Linux ubuntu-m-16gb-nyc3-01 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/issue Ubuntu 16.04.1 LTS # history | grep wget 5 wget http://files.pharo.org/get-files/60/pharo-64.zip 6 wget http://files.pharo.org/sources/PharoV50.sources.zip 7 wget https://bintray.com/estebanlm/pharo-vm/download_file?file_path=pharo-linux-… # ./bin/pharo -vm-display-null pharo-64.image st --quit memtest.st >& out.log & Which gave the following (abbreviated) output: uptime 0h0m0s memory 70,918,144 bytes old 61,966,112 bytes (87.4%) young 2,781,608 bytes (3.9000000000000004%) used 46,301,016 bytes (65.3%) free 18,446,704 bytes (26.0%) GCs 1 (207ms between GCs) full 0 totalling 0ms (0.0% uptime) incr 1 totalling 0ms (0.0% uptime), avg 0.0ms tenures 0 Iteration 1 ... Iteration 8 ... uptime 0h12m44s memory 5,238,300,672 bytes old 5,229,348,640 bytes (99.80000000000001%) young 1,054,128 bytes (0.0%) used 5,207,806,800 bytes (99.4%) free 22,595,968 bytes (0.4%) GCs 23,509 (33ms between GCs) full 19 totalling 147,969ms (19.400000000000002% uptime), avg 7787.8ms incr 23490 totalling 143,396ms (18.8% uptime), avg 6.1000000000000005ms tenures 107,267,532 (avg 0 GCs/tenure) Since last view 23,508 (33ms between GCs) uptime 764.4000000000001s full 19 totalling 147,969ms (19.400000000000002% uptime), avg 7787.8ms incr 23489 totalling 143,396ms (18.8% uptime), avg 6.1000000000000005ms tenures 107,267,532 (avg 0 GCs/tenure) # free -m total used free shared buff/cache available Mem: 16047 4632 10647 3 768 11129 Swap: 0 0 0 So, yes, it works on Linux too. Sven [1] | meta hold | NonInteractiveTranscript stdout install. Transcript crShow: SmalltalkImage current vm statisticsReport; cr. hold := (1 to: 8) collect: [ :i | Transcript crShow: 'Iteration ', i asString. ASTCache reset. meta := Dictionary new. Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | (classMeta := Dictionary new) at: #name put: each name asSymbol; at: #comment put: each comment; at: #definition put: each definition; at: #object put: each. methods := Dictionary new. classMeta at: #methods put: methods. each methodsDo: [ :method | | methodMeta | (methodMeta := Dictionary new) at: #name put: method selector; at: #source put: method sourceCode; at: #ast put: method ast; at: #args put: method argumentNames asArray; at: #formatted put: method ast formattedCode; at: #comment put: (method comment ifNotNil: [ :str | str withoutQuoting ]); at: #object put: method. methods at: method selector put: methodMeta ]. meta at: each name asSymbol put: classMeta ]. meta. ]. 3 timesRepeat: [ Smalltalk garbageCollect ]. Transcript crShow: SmalltalkImage current vm statisticsReport; cr. > On 9 Nov 2016, at 17:18, phil(a)highoctane.be wrote: > > Ok, I'll try that in the coming days on my desktop box. > I've got 32GB on that box, so it will be interesting. > > What would be a good way to stress test the GC? > > Phil > > On Wed, Nov 9, 2016 at 3:59 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2016-11-09 15:23 GMT+01:00 philippe.back(a)highoctane.be <philippe.back(a)gmail.com>: > Anyone having tested such 64 bit goodness on a Linux box? > > Only as a professional demo for code developped up to the very last moment on Pharo 32 bits. So I didn't try to explose the available RAM on my laptop (yet). > > Thierry > > > Phil > > >

Nov. 9, 2016

[pharo-project/pharo-core] f8e7f7: 60287

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: f8e7f7671624be4847cf026b607aa965dd0eb387 https://github.com/pharo-project/pharo-core/commit/f8e7f7671624be4847cf026b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-09 (Wed, 09 Nov 2016) Changed paths: M Nautilus.package/AbstractNautilusUI.class/instance/source code area/acceptSourceCodeFromView.st M Nautilus.package/AbstractNautilusUI.class/instance/source text events/whenTextAcceptedInView_.st M Nautilus.package/NautilusUI.class/instance/source code area/compileAMethodFromCategory_withSource_notifying_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60286.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60287.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60286.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60287.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60287 14376 Make Nautilus to automatically categorize new methods (if needed) and remove empty protocols https://pharo.fogbugz.com/f/cases/14376 http://files.pharo.org/image/60/60287.zip

Nov. 9, 2016