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

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Sebastian Sastre

> On Jan 16, 2015, at 7:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > We have no intention to insult anyone. At the same time, we also take the freedom to choose the goals we want. We started from Smalltalk but our goal is not to be a Smalltalk. We might end up being one for a while, but we might as well not. Our goal is to reinvent software engineering. This implies that we want to get to novel things that were not invented yet, hence difficult to plan or predict. For example, we already have indications of novel language models (like the new compiler, slots, new debugger model), novel IDE (GT), novel VM (Spur and the up-and-coming Sista) and more will come. > > So, when you read "Smalltalk inspired" please interpret it as saying that while we honor the giants on the shoulders of which we build now, we want to invent the future. > > Cheers, > Doru This is probably the best thing Iâve read so far about the Pharo not being Smalltalk subject. I suggest you create a blog post or try to get it published somewhere, potentially as Pharo FAQ answer Success!

Jan. 16, 2015

Any Deep Learning Algorithm related lib in Pharo ?

by CÃ©drick BÃ©ler

Hi all, The question is in the title. Iâm just journeying in this field and was wandering if it exists something on deep learning algorithms. Some refs an introduction: http://www.toptal.com/machine-learning/an-introduction-to-deep-learning-fro… Python lib: http://www.pyimagesearch.com/2014/09/22/getting-started-deep-learning-pytho… http://deeplearning.net/tutorial/ Java lib (link in the tutorial) ... Cheers and best wishes all for 2015, CÃ©drick

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by kilon alios

"I think we *really* need a smalltalk-talk mailing listâ¦" I definetly not need it, I am far more interested into coding with pharo and understanding pharo libraries and tools than generally debating smalltalk. But if you want such list to discuss smalltalk be my guest. "Hi, This topic was discussed before and I do not want to elaborate more, but given that you seem to not have been involved in that thread, I will write one single comment. We have no intention to insult anyone. At the same time, we also take the freedom to choose the goals we want. We started from Smalltalk but our goal is not to be a Smalltalk. We might end up being one for a while, but we might as well not. Our goal is to reinvent software engineering. This implies that we want to get to novel things that were not invented yet, hence difficult to plan or predict. For example, we already have indications of novel language models (like the new compiler, slots, new debugger model), novel IDE (GT), novel VM (Spur and the up-and-coming Sista) and more will come. So, when you read "Smalltalk inspired" please interpret it as saying that while we honor the giants on the shoulders of which we build now, we want to invent the future. Cheers," I understand your (plural) position on this because I have read that thread , and like you I dont want to elaborate more on this since I don't want to create a very long thread of people agreeing that they disagree which what that thread ended up being. I merely stated my opinion you are more than welcome to disagree.

Jan. 16, 2015

[ANN] Pharo Consortium New Academic Partner: Ecole des Mines de Douai

by Marcus Denker

The Pharo Consortium is very happy to announce that the Ecole des Mines de Douai has joined the Consortium as an Academic Partner. About - Ecole des Mines de Douai: http://www.mines-douai.fr - Ecole des Mines de Douai, IA: http://ia.mines-douai.fr - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Sven Van Caekenberghe

> On 16 Jan 2015, at 10:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I think we *really* need a smalltalk-talk mailing listâ¦ +1024 These discussions have nothing to do with developing or using Pharo. >> On 16 Jan 2015, at 05:44, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> >> "I would like to remind people that the aim of the Pharo project is more ambitious than the Smalltalk one" >> >> I would like to hear this grand plan of Pharo, where is it ? Where is the official roadmap ? What are the goals that the core development team agree on ? Why are such a secret and I have never seen them discussed here or anywhere on the internet. >> >> I would not call Pharo odd, Pharo is diffirent but not that diffirent. It offers me a way to code that I prefer over python , but I would not call my experience coding with pharo radically different compared to python coding. Smalltalk used to be the Purple Cow no doubt when it first came out , so many new concepts and ideas that were far apart from anything remotely similar. But nowdays the smalltalk paradigm has been embraced in several fronts , languages and IDEs are moving closer and closer. >> >> It took python 24 years to get as popular as it is nowdays, the most popular languages have a similar lifespan if not more in some cases. Its a really long process and its full of compromises and ugly truths. >> >> I also dont like the fact that Pharo calls itself "Smalltalk inspired" its an insult to people who put an effort into Smalltalk by spending hours making code. You cannot be "Smalltalk inspired" by forking code , your at best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed mentality inside the heads of those Pharoers that believe this, its shows me fear , its shows me embarrassment, it shows me weakness. >> >> I would prefer it if Pharo was advertising itself as a modern Smalltalk implementation as a project that lives true to the Smalltalk philosophy and moves forward. Instead here we are calling Smalltalk "less ambitious" , why ? Innovativing more than any other language have done so , is not ambitious enough for you ? >> >> I do believe in Pharo If I did not I would not contribute but I would prefer it without all the hype. Innovate all you want , code whatever makes you happy, live your dream but also respect the dreams of others, especially when you base your success on their success. And yes I will dare say it , Smalltalk has been extremely succesful in many fronts , far more than Pharo currently is. >> >> PS: Just a clarification because people love to put words on other people mouths, I never said that languages like Clojure and Scheme has been miserable failures generally, but based on the hype of how popular they will become. Both Clojure and Sceme are great language with continuously expanding communities . I was merely wanted to point out how hype does not help and there was tons of hype when Java allowed for the creation of those languages. Jython for example is one of the oldest Java languages (2001), and there was tons of hype when the project started that Jython could become at worst an equal to Cpython on terms of popularity and even more popular than Java at best. Sun even funded the development of Jython back in 2008. >> >> I admire what the creator of Redline done as I admire the effort that has been invested on both Pharo and Squeak. Its really hard to make a competitive product in a world so complex and so demanding as the one we live now. I do believe in Pharo and I hope the best for it but even Pharo never makes it to the top 20 most popular languages even in 30 years I wont lose my sleep over it. I love Pharo for what it is, and not what it may become. >> >> >

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Marcus Denker

I think we *really* need a smalltalk-talk mailing listâ¦ > On 16 Jan 2015, at 05:44, kilon alios <kilon.alios(a)gmail.com> wrote: > > > "I would like to remind people that the aim of the Pharo project is more ambitious than the Smalltalk one" > > I would like to hear this grand plan of Pharo, where is it ? Where is the official roadmap ? What are the goals that the core development team agree on ? Why are such a secret and I have never seen them discussed here or anywhere on the internet. > > I would not call Pharo odd, Pharo is diffirent but not that diffirent. It offers me a way to code that I prefer over python , but I would not call my experience coding with pharo radically different compared to python coding. Smalltalk used to be the Purple Cow no doubt when it first came out , so many new concepts and ideas that were far apart from anything remotely similar. But nowdays the smalltalk paradigm has been embraced in several fronts , languages and IDEs are moving closer and closer. > > It took python 24 years to get as popular as it is nowdays, the most popular languages have a similar lifespan if not more in some cases. Its a really long process and its full of compromises and ugly truths. > > I also dont like the fact that Pharo calls itself "Smalltalk inspired" its an insult to people who put an effort into Smalltalk by spending hours making code. You cannot be "Smalltalk inspired" by forking code , your at best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed mentality inside the heads of those Pharoers that believe this, its shows me fear , its shows me embarrassment, it shows me weakness. > > I would prefer it if Pharo was advertising itself as a modern Smalltalk implementation as a project that lives true to the Smalltalk philosophy and moves forward. Instead here we are calling Smalltalk "less ambitious" , why ? Innovativing more than any other language have done so , is not ambitious enough for you ? > > I do believe in Pharo If I did not I would not contribute but I would prefer it without all the hype. Innovate all you want , code whatever makes you happy, live your dream but also respect the dreams of others, especially when you base your success on their success. And yes I will dare say it , Smalltalk has been extremely succesful in many fronts , far more than Pharo currently is. > > PS: Just a clarification because people love to put words on other people mouths, I never said that languages like Clojure and Scheme has been miserable failures generally, but based on the hype of how popular they will become. Both Clojure and Sceme are great language with continuously expanding communities . I was merely wanted to point out how hype does not help and there was tons of hype when Java allowed for the creation of those languages. Jython for example is one of the oldest Java languages (2001), and there was tons of hype when the project started that Jython could become at worst an equal to Cpython on terms of popularity and even more popular than Java at best. Sun even funded the development of Jython back in 2008. > > I admire what the creator of Redline done as I admire the effort that has been invested on both Pharo and Squeak. Its really hard to make a competitive product in a world so complex and so demanding as the one we live now. I do believe in Pharo and I hope the best for it but even Pharo never makes it to the top 20 most popular languages even in 30 years I wont lose my sleep over it. I love Pharo for what it is, and not what it may become. > >

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Tudor Girba

Hi, This topic was discussed before and I do not want to elaborate more, but given that you seem to not have been involved in that thread, I will write one single comment. We have no intention to insult anyone. At the same time, we also take the freedom to choose the goals we want. We started from Smalltalk but our goal is not to be a Smalltalk. We might end up being one for a while, but we might as well not. Our goal is to reinvent software engineering. This implies that we want to get to novel things that were not invented yet, hence difficult to plan or predict. For example, we already have indications of novel language models (like the new compiler, slots, new debugger model), novel IDE (GT), novel VM (Spur and the up-and-coming Sista) and more will come. So, when you read "Smalltalk inspired" please interpret it as saying that while we honor the giants on the shoulders of which we build now, we want to invent the future. Cheers, Doru On Fri, Jan 16, 2015 at 9:44 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > "I would like to remind people that the aim of the Pharo project is more > ambitious than the Smalltalk one" > > I would like to hear this grand plan of Pharo, where is it ? Where is the > official roadmap ? What are the goals that the core development team agree > on ? Why are such a secret and I have never seen them discussed here or > anywhere on the internet. > > I would not call Pharo odd, Pharo is diffirent but not that diffirent. It > offers me a way to code that I prefer over python , but I would not call my > experience coding with pharo radically different compared to python coding. > Smalltalk used to be the Purple Cow no doubt when it first came out , so > many new concepts and ideas that were far apart from anything remotely > similar. But nowdays the smalltalk paradigm has been embraced in several > fronts , languages and IDEs are moving closer and closer. > > It took python 24 years to get as popular as it is nowdays, the most > popular languages have a similar lifespan if not more in some cases. Its a > really long process and its full of compromises and ugly truths. > > I also dont like the fact that Pharo calls itself "Smalltalk inspired" its > an insult to people who put an effort into Smalltalk by spending hours > making code. You cannot be "Smalltalk inspired" by forking code , your at > best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself > "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed > mentality inside the heads of those Pharoers that believe this, its shows > me fear , its shows me embarrassment, it shows me weakness. > > I would prefer it if Pharo was advertising itself as a modern Smalltalk > implementation as a project that lives true to the Smalltalk philosophy and > moves forward. Instead here we are calling Smalltalk "less ambitious" , why > ? Innovativing more than any other language have done so , is not > ambitious enough for you ? > > I do believe in Pharo If I did not I would not contribute but I would > prefer it without all the hype. Innovate all you want , code whatever makes > you happy, live your dream but also respect the dreams of others, > especially when you base your success on their success. And yes I will dare > say it , Smalltalk has been extremely succesful in many fronts , far more > than Pharo currently is. > > PS: Just a clarification because people love to put words on other people > mouths, I never said that languages like Clojure and Scheme has been > miserable failures generally, but based on the hype of how popular they > will become. Both Clojure and Sceme are great language with continuously > expanding communities . I was merely wanted to point out how hype does not > help and there was tons of hype when Java allowed for the creation of those > languages. Jython for example is one of the oldest Java languages (2001), > and there was tons of hype when the project started that Jython could > become at worst an equal to Cpython on terms of popularity and even more > popular than Java at best. Sun even funded the development of Jython back > in 2008. > > I admire what the creator of Redline done as I admire the effort that has > been invested on both Pharo and Squeak. Its really hard to make a > competitive product in a world so complex and so demanding as the one we > live now. I do believe in Pharo and I hope the best for it but even Pharo > never makes it to the top 20 most popular languages even in 30 years I wont > lose my sleep over it. I love Pharo for what it is, and not what it may > become. > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 16, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by kilon alios

"I would like to remind people that the aim of the Pharo project is more ambitious than the Smalltalk one" I would like to hear this grand plan of Pharo, where is it ? Where is the official roadmap ? What are the goals that the core development team agree on ? Why are such a secret and I have never seen them discussed here or anywhere on the internet. I would not call Pharo odd, Pharo is diffirent but not that diffirent. It offers me a way to code that I prefer over python , but I would not call my experience coding with pharo radically different compared to python coding. Smalltalk used to be the Purple Cow no doubt when it first came out , so many new concepts and ideas that were far apart from anything remotely similar. But nowdays the smalltalk paradigm has been embraced in several fronts , languages and IDEs are moving closer and closer. It took python 24 years to get as popular as it is nowdays, the most popular languages have a similar lifespan if not more in some cases. Its a really long process and its full of compromises and ugly truths. I also dont like the fact that Pharo calls itself "Smalltalk inspired" its an insult to people who put an effort into Smalltalk by spending hours making code. You cannot be "Smalltalk inspired" by forking code , your at best "Smalltalk based" and that makes you Smalltalk. Ruby can call itself "Smalltalk inspired" , Pharo cannot. This shows to me a very flawed mentality inside the heads of those Pharoers that believe this, its shows me fear , its shows me embarrassment, it shows me weakness. I would prefer it if Pharo was advertising itself as a modern Smalltalk implementation as a project that lives true to the Smalltalk philosophy and moves forward. Instead here we are calling Smalltalk "less ambitious" , why ? Innovativing more than any other language have done so , is not ambitious enough for you ? I do believe in Pharo If I did not I would not contribute but I would prefer it without all the hype. Innovate all you want , code whatever makes you happy, live your dream but also respect the dreams of others, especially when you base your success on their success. And yes I will dare say it , Smalltalk has been extremely succesful in many fronts , far more than Pharo currently is. PS: Just a clarification because people love to put words on other people mouths, I never said that languages like Clojure and Scheme has been miserable failures generally, but based on the hype of how popular they will become. Both Clojure and Sceme are great language with continuously expanding communities . I was merely wanted to point out how hype does not help and there was tons of hype when Java allowed for the creation of those languages. Jython for example is one of the oldest Java languages (2001), and there was tons of hype when the project started that Jython could become at worst an equal to Cpython on terms of popularity and even more popular than Java at best. Sun even funded the development of Jython back in 2008. I admire what the creator of Redline done as I admire the effort that has been invested on both Pharo and Squeak. Its really hard to make a competitive product in a world so complex and so demanding as the one we live now. I do believe in Pharo and I hope the best for it but even Pharo never makes it to the top 20 most popular languages even in 30 years I wont lose my sleep over it. I love Pharo for what it is, and not what it may become.

Jan. 16, 2015

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

by Norbert Hartl

> Am 16.01.2015 um 00:50 schrieb Ben Coman <btc(a)openInWorld.com>: > > 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" :) > But you could use it if it would be there. Having it on pharo-users could lead to a lot of people showing their interest in using it. And it definetely is a use case :) Norbert >> 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. 16, 2015

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

by Max Leske

> On 16 Jan 2015, at 00:48, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > 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. 1. memory is preallocated 2. no grow operation is necessary until youâve maxed out the private array (of the preallocated size) (at least in Pharo 4 that is true) > > 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. You are right. The wording is problematic. > > 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. Phew! ;) > > 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. 16, 2015