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

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by phil＠highoctane.be

On Thu, Mar 5, 2015 at 12:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Phil, > >> On 05 Mar 2015, at 11:44, phil(a)highoctane.be wrote: >> >> Images are starting slow, that's my experience. Here, a Pharo3 on >> Windows with quite a bunch of things in it takes six seconds to load >> on first launch and three after that. >> >> And that's on a i7 4770K clocked 3.85GHz with SSD drives. >> >> It takes less time to revive a VMWare VM :-( > > Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times. > > (This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD) > > root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 > Downloading the latest 40 Image: > http://files.pharo.org/image/40/latest.zip > Pharo.image > Downloading the latest pharoVM: > http://files.pharo.org/vm/pharo/linux/stable.zip > pharo-vm/pharo > Downloading PharoV10.sources: > http://files.pharo.org/sources//PharoV10.sources.zip > Downloading PharoV20.sources: > http://files.pharo.org/sources//PharoV20.sources.zip > Downloading PharoV30.sources: > http://files.pharo.org/sources//PharoV30.sources.zip > Creating starter scripts pharo and pharo-ui > > root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion > [version] 4.0 #40535 > > root@stfx:~/experiments/pharo4# ls -lah Pharo.image > -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.386s > user 0m0.184s > sys 0m0.028s > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.422s > user 0m0.192s > sys 0m0.032s > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.863s > user 0m0.404s > sys 0m0.064s > > It is the latest (smaller) image, but that should not make much difference. On my CentOS Linux, headless tests are fast as well. Granted, my Windows image was super large. 300Megs or something. I cleaned the Monticello things with flush cache, which removed 41 megs. I can't test the CLI version on Windows, as I do get a window opening. There are a ton of windows and morphs open in there and I've run a couple of experiments. Now, the Linux image was large too. 200Megs or so. And the window showed immediately, then it took a second and a half or so to show the images back. There is a black background before. Maybe the system is processing its startUp list, unhibernating forms, I don't know what's going on but it takes that 1.5 secs. The image gets large because of Monticello caches, and TWM (Tiling Window Manager) keeping a handle on browsers etc over time. So, I cleaned the caches, closed TWM, gc'ed a time or two and then got the image back to 90 megs. Then the image opens in like 0.5 sec. It is hard to measure as what I want is the time between issuing the pharo-ui XYZ.image and the fact that I can actually see the UI. How would one do that? Sorry for the rant but generally speaking, the Pharo UI seems slower than the Squeak 4.5 ui. Or the EToys UI for that matter. I am using those for little educational programs and they feel faster. I'd like to know why. Both systems have morphic. Is it because of aliased fonts? Squeak 4.5 also has that. Is there any way to monitor what's going on during image startup? Phil > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > >

March 5, 2015

Re: [Pharo-dev] PharoLauncher fails to download build 40536

by Marcus Denker

> On 05 Mar 2015, at 13:31, Ben Coman <btc(a)openInWorld.com> wrote: > > I just noticed that build 40536 doesn't download using PharoLauncher. It returns too quickly with the error "Error: can't find EOCD position". Build 40535 downloads fine. > cheers -ben yes, 40536 is broken. I will remove the broken file. Marcus

March 5, 2015

PharoLauncher fails to download build 40536

by Ben Coman

I just noticed that build 40536 doesn't download using PharoLauncher. It returns too quickly with the error "Error: can't find EOCD position". Build 40535 downloads fine. cheers -ben

March 5, 2015

Re: [Pharo-dev] DNS change files.pharo.org

by Marcus Denker

> On 05 Mar 2015, at 10:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > We will switch the DNS entry from an A type to a CNAME that points to a different server (for caching) > this afternoon at 1pm local time. > > It should all continue to work (and hopefully faster) > DNS changes for files.pharo.org <http://files.pharo.org/> get.pharo.org <http://get.pharo.org/> will stay (for now) unchanged. Marcus

March 5, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Sven Van Caekenberghe

Phil, > On 05 Mar 2015, at 11:44, phil(a)highoctane.be wrote: > > Images are starting slow, that's my experience. Here, a Pharo3 on > Windows with quite a bunch of things in it takes six seconds to load > on first launch and three after that. > > And that's on a i7 4770K clocked 3.85GHz with SSD drives. > > It takes less time to revive a VMWare VM :-( Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times. (This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD) root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion [version] 4.0 #40535 root@stfx:~/experiments/pharo4# ls -lah Pharo.image -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.386s user 0m0.184s sys 0m0.028s root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.422s user 0m0.192s sys 0m0.032s root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.863s user 0m0.404s sys 0m0.064s It is the latest (smaller) image, but that should not make much difference. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

March 5, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by phil＠highoctane.be

On Thu, Mar 5, 2015 at 10:55 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Thu, Mar 5, 2015 at 2:08 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: >> >> >> Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : >> > >> > On 04/03/15 14:19, phil(a)highoctane.be wrote: >> > >> >> Interesting but not sure I'd like to have images going through >> >> decompression everytime I spin them up. >> >> Especially if there are a lot of the in a server. >> > >> > >> > 2GB/s is twice as fast as you can get from a fast SSD atm. >> > And as that is per core, that puts a boundary of starting >> > 2200 pharo images/s on a modern dual socket server. >> > After half a minute of that you run out of ram with a >> > 1.5TB ram machine. The bottlenecks might be elsewhere. >> >> There is no way an image starts that fast today. >> >> There is the delay thing that slows things down. > > > Is this the code Eliot advised would not be needed when we've moved to the > microsecond clock? Can you point me at the code? > cheers -ben Hi ben I've been following your Delay related work (sorry for the lack of feedback, still, I read it all). I will review where these things are and send you what I do find. t Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that. And that's on a i7 4770K clocked 3.85GHz with SSD drives. It takes less time to revive a VMWare VM :-( Phil > >> >> > >> > >> > Norbert wrote: >> > > To be sure if you want that you have to test it. You have always take >> > > > into account that a smaller file will have less I/O to read from disk. >> > >> > +1 >> >> Ok. >> >> > >> > Stephan >> > >> > >> > >> > >> > > >

March 5, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Ben Coman

On Thu, Mar 5, 2015 at 2:08 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan(a)stack.nl> a Ã©crit : > > > > On 04/03/15 14:19, phil(a)highoctane.be wrote: > > > >> Interesting but not sure I'd like to have images going through > >> decompression everytime I spin them up. > >> Especially if there are a lot of the in a server. > > > > > > 2GB/s is twice as fast as you can get from a fast SSD atm. > > And as that is per core, that puts a boundary of starting > > 2200 pharo images/s on a modern dual socket server. > > After half a minute of that you run out of ram with a > > 1.5TB ram machine. The bottlenecks might be elsewhere. > > There is no way an image starts that fast today. > > There is the delay thing that slows things down. > Is this the code Eliot advised would not be needed when we've moved to the microsecond clock? Can you point me at the code? cheers -ben > > > > > > Norbert wrote: > > > To be sure if you want that you have to test it. You have always take > > into account that a smaller file will have less I/O to read from disk. > > > > +1 > > Ok. > > > > > Stephan > > > > > > > > > > >

March 5, 2015

Re: [Pharo-dev] Validation failur ZnImageExampleDelegateTests>>#testDefaultImage

by Sven Van Caekenberghe

All Zn tests that run local servers work like that, using a random port from a range of 32. With fixed ports, we would get many more conflicts because tests and/or CI jobs are running concurrently on slaves. We could increase the range. We could pass some small unique ID to each image and use that to compute a unique port. Testing if a port is available is a total mess because the different socket plugins behave slightly different. Maybe starting servers and letting the OS give out a next available port could work, I should try that. In any case, unless this is a persistent problem I would not do it now. > On 05 Mar 2015, at 10:29, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Anyone has an idea why this test fails so often? > > In > ZnImageExampleDelegateTests>>withServerDo: block > we use > ZnServer on: 1700 + 32 atRandom. > > I don't know if this is related to the validation failure, but > the randomly generated portnumber makes it hard get reliable results. > > > > nicolai

March 5, 2015

Validation failur ZnImageExampleDelegateTests>>#testDefaultImage

by Nicolai Hess

Anyone has an idea why this test fails so often? In ZnImageExampleDelegateTests>>withServerDo: block we use ZnServer on: 1700 + 32 atRandom. I don't know if this is related to the validation failure, but the randomly generated portnumber makes it hard get reliable results. nicolai

March 5, 2015

DNS change files.pharo.org

by Marcus Denker

Hello, We will switch the DNS entry from an A type to a CNAME that points to a different server (for caching) this afternoon at 1pm local time. It should all continue to work (and hopefully faster) Marcus

March 5, 2015