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

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Alain Rastoul

Le 16/01/2015 07:26, Tudor Girba a Ã©crit : > It is always tempting to go where others are. Yet, once we get there you > might notice that many other people are there as well, and all of a > sudden we are less remarkable and we get less attention than we hoped for. > > In the meantime, I will continue working with people to make Pharo the > thing that others will envy. I do want Pharo to be the odd one out, the > Purple Cow. It is exactly by doing something radically different that we > have a chance of reinventing software engineering. > > Some might think that it is not possible. That we are too small. That we > have no funding. That ... there are many reasons to be found for giving > up and doing what others are doing. But, I think we are closer to > reaching the Purple Cow than we think. We are on an ascending trend and > the most important features are not yet out. We still have a hard road > ahead of us, but I believe we are approaching a very interesting period > in the Pharo history. > > I would like to remind people that the aim of the Pharo project is more > ambitious than the Smalltalk one. Please rally and focus on the larger > goal. Together, we will get there. > > Doru > Nice thought I like Purple Cows me too, green and yellow ones with squared wheel are nice too. squared wheels give good vibrations :) Redline smalltalk is more about marketing and surfing on the java/jvm hype than innovation see also http://arstechnica.com/business/2015/01/intel-pledges-300-million-to-improv… > On Fri, Jan 16, 2015 at 5:15 AM, horrido > <horrido.hobbies(a)gmail.com > <mailto:horrido.hobbies@gmail.com>> wrote: > > I believe in Redline. I think it's a very important project, > strategically. > On Twitter and elsewhere, I am urging contributors to join Redline. > It would > be something of a tragedy if Redline failed to reach version 1.0. > *We need > Smalltalk on the JVM.* > > > jamesl wrote > > Hi Smalltalkers, > > > > Redline Smalltalk is not dead although it looks like it. > > I recently made the grammar much cleaner and moved to using > Antlr4 as well > > as cleaning up the > > internals. Yes - what is in the core project in github is dormant > and I > > have spun off 'stc' to contain > > the the work Im doing until an appropriate time to merge back > into that > > main. > > > > I'd love some help but right now you would be limited to copying > across > > the runtime library and writing > > tests around it as I concentrate on the bytecode generation and > underlying > > code - which is hard to have too many people helping with. > > > > I'm *very* busy in my life right now with a startup > (http://mywave.me) and > > personal life but I really > > am trying to find the time to push this along. > > > > I've set myself some fitness, work and Smalltalk goals for this > year and > > all going well Redline will be > > out in September. BUT - Please don't hate me. > > > > This is the Year of Smalltalk and we can change the world - one > JVM at a > > time ;) > > > > - James. > > Redline Smalltalk > > > > > > -- > View this message in context: > http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799830.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" -- Regards, Alain

Jan. 16, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Alain Rastoul

Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a Ã©crit : > Hi > > I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2. > http://www.openmirage.org/ > http://queue.acm.org/detail.cfm?id=2566628 > http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for… > > It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts: > * A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application. http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/. > * Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/. > * These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot. > * The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing. > > I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.h…. Assuming we understood each other it seems the answer is "yes that should be possible". > > My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this? > > Best regards > > Joerg > > > > > Given that the openmirage kernel is written mostly in ocaml, I think that the "port" of the vm could imply quite some work, like rewriting the plugins (socket at first), dealing with Ocaml bindings etc. and not easy at all. Digging into that, I went across the rump kernel, and think that it may be much simpler to deal with than openmirage, with some nice other features (micro or dedicated kernels) that could make the pharo system a pharo os. see http://rumpkernel.org/ and http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf It is still a unix kernel (NetBDS) written in C so more friendly to lot of developers and much simpler for pharo vm port integrates well in xen and other hypervisors can be run without the hypervisor platform can be tailored at will, and give very lean systems. Extremely interesting -- Regards, Alain

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Tudor Girba

It is always tempting to go where others are. Yet, once we get there you might notice that many other people are there as well, and all of a sudden we are less remarkable and we get less attention than we hoped for. In the meantime, I will continue working with people to make Pharo the thing that others will envy. I do want Pharo to be the odd one out, the Purple Cow. It is exactly by doing something radically different that we have a chance of reinventing software engineering. Some might think that it is not possible. That we are too small. That we have no funding. That ... there are many reasons to be found for giving up and doing what others are doing. But, I think we are closer to reaching the Purple Cow than we think. We are on an ascending trend and the most important features are not yet out. We still have a hard road ahead of us, but I believe we are approaching a very interesting period in the Pharo history. I would like to remind people that the aim of the Pharo project is more ambitious than the Smalltalk one. Please rally and focus on the larger goal. Together, we will get there. Doru On Fri, Jan 16, 2015 at 5:15 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > I believe in Redline. I think it's a very important project, strategically. > On Twitter and elsewhere, I am urging contributors to join Redline. It > would > be something of a tragedy if Redline failed to reach version 1.0. *We need > Smalltalk on the JVM.* > > > jamesl wrote > > Hi Smalltalkers, > > > > Redline Smalltalk is not dead although it looks like it. > > I recently made the grammar much cleaner and moved to using Antlr4 as > well > > as cleaning up the > > internals. Yes - what is in the core project in github is dormant and I > > have spun off 'stc' to contain > > the the work Im doing until an appropriate time to merge back into that > > main. > > > > I'd love some help but right now you would be limited to copying across > > the runtime library and writing > > tests around it as I concentrate on the bytecode generation and > underlying > > code - which is hard to have too many people helping with. > > > > I'm *very* busy in my life right now with a startup (http://mywave.me) > and > > personal life but I really > > am trying to find the time to push this along. > > > > I've set myself some fitness, work and Smalltalk goals for this year and > > all going well Redline will be > > out in September. BUT - Please don't hate me. > > > > This is the Year of Smalltalk and we can change the world - one JVM at a > > time ;) > > > > - James. > > Redline Smalltalk > > > > > > -- > View this message in context: > http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799830.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 16, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Alain Rastoul

Le 16/01/2015 00:50, Ben Coman a Ã©crit : > Actually, the requirements to modify/link the vm make it more a [vm-dev] > topic, but still interesting for [pharo-dev]s. that's how I understand it, but the distinction is not allways clear: standard frameworks devel (not use) who are part of the system should go here too IMHO, but that's an opinion. May be a private list for the pharo-devs would be better for them not to be disturbed (that I can understand) , keeping the two lists open to everybody: users for general and use of the system and devel for vm or system related stuff. Or only one list open to every body and one private. For now, I don't want to ask myself if people will be diturbed or not or if they will answer or not, or to ask myself is it really pharodev or pharo use ? I think I will allways post questions on pharo-users, I will not disturb anybody, no problem :) > It wouldn't be [pharo-users] until there was something to "use" :) > > On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> wrote: > > Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a Ã©crit : > > > > > -----Original Message----- > From: Pharo-dev > [mailto:pharo-dev-bounces@__lists.pharo.org > <mailto:pharo-dev-bounces@lists.pharo.org>] > On Behalf > Of Alain Rastoul > Sent: Wednesday, January 14, 2015 10:39 PM > To: pharo-dev(a)lists.pharo.org > <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Hosting the Pharo VM on > MirageOS > > Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a > Ã©crit : > > > I was not planning specializing the VM for the > image. But rather > link in a VM with everything needed to run a > range of images. The > dependencies are handled by creating an OCAML > module that expresses > > these and the VM code then lives in the module. The > OCAML dependence > analyser (a sat solver) then ensures those are > satisfied. > > > But if you don't have a specialized smalltalk vm and > image, you will > have to embed full system dependencies, in order to > build a full > working smalltalk system (having most part not > working could be a > very bad thing), and then you loose the unikernel > approach benefits > (very lean dedicated system, small attack surface etc.). > > My implicit assumption was that these VM would be > designed for running > > headless web-services on smaller EC2 instances. And perhaps > naively was > thinking that the number of system dependencies would be > quite low: > > > - memory > - CPU > - networking stack > - http/https > > - no file system but access to block storage (or perhaps > even link > image in so no storage at all) > - mirage is single threaded with green threads so no > multithreading/processing > > > Honestly, the VM is not that large. There are not many > variation points on that > level. > Where you want specialization is the *image*. > > > Thanks Marcus - good to know > > > Marcus > > > > > Yes, the vm is not so big, and specialization has to be done in the > image. > But there is a key point to mention about openmirage : if it started > as unix (or linux, don't know), it is not linux at all as I > understand it See chapter 3 > http://queue.acm.org/detail.__cfm?id=2566628 > <http://queue.acm.org/detail.cfm?id=2566628> > " ... The last compilation strategy drops the dependency on Unix > entirely and recompiles the MirNet module to link directly to a Xen > network driver, which in turn pulls in all the dependencies it needs > to boot on Xen. This progressive recompilation is key to the > usability of MirageOS, ... etc" > > The compilation process produce a single compiled unit that includes > your application linked with the needed libraries, ie: the > kernel+application, there is no linux kernel and no processes at all. > Even driver's code is linked to you application. > It can be booted in a Xen guest vm like PharoNOS, Linux tiny core > or others linux but ... > I see a completely different animal is here :) > if I'm wrong, please correct me > > NB: Is this thread about pharo devel ? > or should it be moved to pharo-users ? > > -- > Regards, > > Alain > > > -- Regards, Alain

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by horrido

I believe in Redline. I think it's a very important project, strategically. On Twitter and elsewhere, I am urging contributors to join Redline. It would be something of a tragedy if Redline failed to reach version 1.0. *We need Smalltalk on the JVM.* jamesl wrote > Hi Smalltalkers, > > Redline Smalltalk is not dead although it looks like it. > I recently made the grammar much cleaner and moved to using Antlr4 as well > as cleaning up the > internals. Yes - what is in the core project in github is dormant and I > have spun off 'stc' to contain > the the work Im doing until an appropriate time to merge back into that > main. > > I'd love some help but right now you would be limited to copying across > the runtime library and writing > tests around it as I concentrate on the bytecode generation and underlying > code - which is hard to have too many people helping with. > > I'm *very* busy in my life right now with a startup (http://mywave.me) and > personal life but I really > am trying to find the time to push this along. > > I've set myself some fitness, work and Smalltalk goals for this year and > all going well Redline will be > out in September. BUT - Please don't hate me. > > This is the Year of Smalltalk and we can change the world - one JVM at a > time ;) > > - James. > Redline Smalltalk -- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799830.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Sean P. DeNigris

horrido wrote > Langpop.corger.nl <http://langpop.corger.nl/> > is my "go to" website for language rankings. It's not perfect, but it > makes a whole lot more sense to me. Maybe better than the garbage TIOBE, but suffers from the same problem - namely, that the greatest environments and communities least often force users to resort to a site like SO (see http://seandenigris.com/blog/?p=911) I get my questions answered by: exploring the image, reading a great free book, or asking on the mailing list (in that order). Of course, we have the additional "handicap" (score-wise) that so much of our code is stored outside of git. ----- Cheers, Sean -- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799824.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 16, 2015

Re: [Pharo-dev] Finish one thing today

by phil＠highoctane.be

On Fri, Jan 16, 2015 at 12:46 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 15 Jan 2015, at 20:32, Sebastian Sastre <sebastian(a)flowingconcept.com> > wrote: > > > > Silly is to be tricked by the normal bias of your brain. > > > > The point of the text is that you have two gazillion unfinished things > and what matters is what you finished instead. > > > I think it has lots and lots of meaningâ¦ > > e.g. one can read it as a description how to tackle really large and > complex projects: by breaking them into small > steps. > Or, a lot of the really great people are so good that they never release > (or even finish) *anything*, because they know > that they could do better. > Or, there are people doing absolutely great stuff and then they never show > it to anyone. âItâs nothing specialâ. > Or there are people who would have the time to contribute a little, but > they think that whatever they could do would > not be worth it (purely from a time perspective). > > Or there are those who canât do anything that is not âreinventing > everythingâ. Leading to not having anything. > > Lots of interpretations. > At a very basic level, it made me move my ass and get things done. Must read once a day, the earliest, the best. Phil > > Marcus >

Jan. 16, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Ben Coman

Actually, the requirements to modify/link the vm make it more a [vm-dev] topic, but still interesting for [pharo-dev]s. It wouldn't be [pharo-users] until there was something to "use" :) On Fri, Jan 16, 2015 at 5:18 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 15/01/2015 20:58, Joerg Beekmann, DeepCove Labs a Ã©crit : > > >> >> >>>> -----Original Message----- >>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf >>>>> Of Alain Rastoul >>>>> Sent: Wednesday, January 14, 2015 10:39 PM >>>>> To: pharo-dev(a)lists.pharo.org >>>>> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS >>>>> >>>>> Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a Ã©crit : >>>>> >>>>>> >>>>>> I was not planning specializing the VM for the image. But rather >>>>>> link in a VM with everything needed to run a range of images. The >>>>>> dependencies are handled by creating an OCAML module that expresses >>>>>> >>>>> these and the VM code then lives in the module. The OCAML dependence >>>>> analyser (a sat solver) then ensures those are satisfied. >>>>> >>>>>> >>>>>> But if you don't have a specialized smalltalk vm and image, you will >>>>> have to embed full system dependencies, in order to build a full >>>>> working smalltalk system (having most part not working could be a >>>>> very bad thing), and then you loose the unikernel approach benefits >>>>> (very lean dedicated system, small attack surface etc.). >>>>> >>>> My implicit assumption was that these VM would be designed for running >>>> >>> headless web-services on smaller EC2 instances. And perhaps naively was >>> thinking that the number of system dependencies would be quite low: >>> >>>> >>>> - memory >>>> - CPU >>>> - networking stack >>>> - http/https >>>> >>>> - no file system but access to block storage (or perhaps even link >>>> image in so no storage at all) >>>> - mirage is single threaded with green threads so no >>>> multithreading/processing >>>> >>> >>> Honestly, the VM is not that large. There are not many variation points >>> on that >>> level. >>> Where you want specialization is the *image*. >>> >> >> Thanks Marcus - good to know >> >> >>> Marcus >>> >> >> >> >> Yes, the vm is not so big, and specialization has to be done in the > image. > But there is a key point to mention about openmirage : if it started as > unix (or linux, don't know), it is not linux at all as I understand it See > chapter 3 > http://queue.acm.org/detail.cfm?id=2566628 > " ... The last compilation strategy drops the dependency on Unix entirely > and recompiles the MirNet module to link directly to a Xen network driver, > which in turn pulls in all the dependencies it needs to boot on Xen. This > progressive recompilation is key to the usability of MirageOS, ... etc" > > The compilation process produce a single compiled unit that includes your > application linked with the needed libraries, ie: the kernel+application, > there is no linux kernel and no processes at all. > Even driver's code is linked to you application. > It can be booted in a Xen guest vm like PharoNOS, Linux tiny core > or others linux but ... > I see a completely different animal is here :) > if I'm wrong, please correct me > > NB: Is this thread about pharo devel ? > or should it be moved to pharo-users ? > > -- > Regards, > > Alain > > >

Jan. 15, 2015

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)

by Jimmie Houchin

Hello, Yes, I understand this is a micro-benchmark. And yes I know that micro-benchmarks can be dangerous and sometimes worthless. However, financial trading, which is the app I am working on, does this a lot. This is precisely where most of the time is spent. Adding data (numbers) or accessing data in arrays or matrices. This is where my app lives. And performance is important. Regarding my running of the test and the variety of loop sizes. From what I see in the test there is only one loop size. 10000 There are differing initial OrderedCollection sizes. Unless I am misreading the code. OrderedCollection new: 100. (capacity 100). I don't understand how this could be a capacity of 100 by what seems to me to be a normal understanding when its initial size is 0 and it can grow infinitely beyond 100. To me if it has a capacity of 100, immediately after creation its size should be 100 and its initial 100 elements should be accessible. oc at: 1 put: 1 should work. So I do not understand where this supposed capacity enters into anything. It is neither immediately accessible, nor does it limit. When I create an Array, it has a capacity with an understanding that I have. a := Array new: 100. size a. "100" a at: 1. "nil" "works" a at: 1 put: 1. "works" I naively expect the same from another Collection which looks like oc := OrderedCollection new: 100. Since it is a collection with an initial size (capacity). But because it is an OrderedCollection and not an Array, it is not limited by its initial capacity. Apparently my understanding faulty. I just wanted to express how this would potentially/probably be understood by someone who does not know this peculiarity of OrderedCollection. Regarding the comparison to Python and Julia. Mea Culpa, mea culpa, maxima mea culpa. While I thought I duplicated the Pharo code. I did not. I duplicated the inner loop which created and populated the array. I completely left off the outer loop which ran the inner loop 10000 times. The Python code is simple. def t(n): s = time.time() for x in range(0,10000): l = [] for i in range(1,10001): l.append(i) e = time.time() print(e-s, len(l)) return l list_test(10000) # == 15.5 seconds Julia function test_array(asize) for i = 1:10000 a = Array(Int64, asize) for i = 1:asize a[i]=i end end end @time(test_array(10000)) # 0.9 seconds So Pharo at 1.6 seconds (Array time) is respectable compared to Julia's highly optimized preallocated arrays and thoroughly keeps Python in its place. And if I start Julia off with an Array(Int64,0) and do append!(a,[i,]). Julia's time plummets to 19seconds. I feel much better. Thanks for challenging my numbers and insuring my comparisons were correct. Jimmie On 1/15/2015 1:13 PM, Sven Van Caekenberghe wrote: > Jimmy, > >> On 15 Jan 2015, at 19:46, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> >> I do not understand what is happening here. >> >> oc := OrderedCollection new: 10000. >> oc size. "0" >> >> a := Array new: 10000. >> a size. "10000" >> >> So it seems that the #new: isn't creating an OrderedCollection of the size we pass in. >> >> I discovered this when I attempted to do the identical test but with an Array instead of an OrderedCollection. Since the Array doesn't #add: I had to change the code to #at:put:. > This is all normal and by design. > > OrderedCollection is a growable collection, designed so you can add elements at either end. The thread's discussion is about growing strategies. > > Consider, > > (OrderedCollection new: 100) capacity = 100 > > it means it has preallocated room for a 100 elements, but the way it is managed is tricky, as people discovered. >> When I noticed all of the OC code did #add: even if supposedly setting its size to 10000(0). I tried to use #at:put: in the OrderedCollection but it failed because their was no index 1, because the size was still 0. >> >> I naively would have thought that OrderedCollection new: 10000 would return an OrderedCollection of 10000 empty/nil elements and that I could #at:put: into any of those 10000 slots and #add if I needed to go beyond those 10000. >> >> Tests done on a laptop with Windows 7, Pharo 4 latest image, latest stable vm, 3rd gen i7 processor, 12gb ram. >> >> I did all of the tests in Pharo 4 and added my Array test. >> 0:00:00:04.37 >> 0:00:00:03.183 >> 0:00:00:03.674 >> 0:00:00:03.753 >> 0:00:00:01.647 and with an Array instead of OrderedCollection >> >> So we can see if we know the max size and create the collection with that size it should improve performance. >> >> I also do not understand why Pharo is so slow on this? >> >> With the preallocated Array above it took 1.647 seconds. >> >> Python 3.4.2, 0.003 seconds with 10,000 ints, and 0.17 with 1,000,000 ints. >> Julia 3.5, 0.005 seconds with 1,000,000 Int64. >> >> Now I don't expect Pharo to keep up with Julia. But we aren't even in the neighborhood with Python. >> >> I really would like to use Pharo. It really is my favorite language and environment. But these performance numbers give me pause. > There are differently sized loops in this thread, what exactly did you try ? > > What is the Python code that you ran ? > > Benchmarking is always dangerous, you must make absolutely clear what you are running and comparing. > > Sven > >> Jimmie >> >> >> On 1/14/2015 3:53 AM, Max Leske wrote: >>> Hi Alex >>> >>> I thought the following little experiment might interest you. >>> >>> I was trying to find out (as per your suggestion) how big the difference would be between: >>> - setting the array in OrderedCollection to nil and initializing it to size 10 on first access >>> - initializing the array in OrderedCollection to size 0. >>> >>> Expectation: #grow will take time, ergo, using an empty array should be slower than using >>> a preallocated array. >>> >>> Experiment (Pharo 1.3 on SqueakVM): >>> >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >>> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17566 >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >>> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 19717 >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >>> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17598 >>> >>> >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000. >>> 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 18084 >>> >>> >>> >>> Result: growing a collection is always faster (or at least nearly equally fast)! >>> >>> Explanation: What makes preinitialized collections so slow is the fact the the firstIndex variable will be set to >>> the first third of the array (3333 in this case). When the last position in the array is reached, all elements >>> are copied to the beginning of the array (2n operations). This copy operation is really slow (which can be seen >>> from the first example with an oversized collection that does not require copying because the last position >>> of the array is never reached). >>> >>> >>> Experiment (Pharo 4 on PharoVM): >>> (Iâm using bigger numbers here to compensate for the faster VM :) ) >>> >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000000. >>> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:01:09.225" >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. >>> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:37.653" >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. >>> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:40.152" >>> >>> >>> >>> [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. >>> 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:42.121â >>> >>> >>> >>> Result: growing a collection is easily fast enough, although minute performance gains are possible with preinitialized collections. >>> >>> Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to the beginning of the array, preventing the copy >>> operation that made the former measurements so slow. >>> The run with the oversized collection is only so slow because it apparently takes a lot of time to assign the large array (?). >>> >>> >>> Consequence of my little experiment: My initial implementation of the idea in you paper set the array in OrderedCollection to nil >>> under the assumption that grow operations are very costly. That choice leads to many changes in methods of OrderedCollection >>> where it is necessary to check if the array has been initialized yet. This introduces overhead and makes the code more error prone. >>> I see now that it makes much more sense to use an empty array, the performance lost by growing ist neglectable. >>> >>> It is also interesting to note that there almost never seems to be a good reason to initialize an OrderedCollection with a large array. >>> >>> >>> Cheers, >>> Max >> >

Jan. 15, 2015

Re: [Pharo-dev] Finish one thing today

by Marcus Denker

> On 15 Jan 2015, at 20:32, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > Silly is to be tricked by the normal bias of your brain. > > The point of the text is that you have two gazillion unfinished things and what matters is what you finished instead. > I think it has lots and lots of meaningâ¦ e.g. one can read it as a description how to tackle really large and complex projects: by breaking them into small steps. Or, a lot of the really great people are so good that they never release (or even finish) *anything*, because they know that they could do better. Or, there are people doing absolutely great stuff and then they never show it to anyone. âItâs nothing specialâ. Or there are people who would have the time to contribute a little, but they think that whatever they could do would not be worth it (purely from a time perspective). Or there are those who canât do anything that is not âreinventing everythingâ. Leading to not having anything. Lots of interpretations. Marcus

Jan. 15, 2015