April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

On 29 Apr 2011, at 01:07, Nicolas Cellier wrote: >>> However, as I understand it, it's entirely up to user to write code >>> exploiting parallel Process explicitly right ? >> Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. >> >> I don't belief in holy grails or silver bullets. >> Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... > > Unless your hobby is oriented toward functional languages maybe... > But I just know enough of it to now shut up ;) Would be nice, but that is also a fairy tale. The best we have today, in terms of being 'easily' automatically scheduleable are data-flow/stream languages. Things like StreamIT or Lucid have interesting properties, but well, its still a search for the holly grail. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Nicolas Cellier

2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: > > On 29 Apr 2011, at 00:32, Nicolas Cellier wrote: > >> >> However, as I understand it, it's entirely up to user to write code >> exploiting parallel Process explicitly right ? > Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. > > I don't belief in holy grails or silver bullets. > Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... > > > Best regards > Stefan > Unless your hobby is oriented toward functional languages maybe... But I just know enough of it to now shut up ;) Nicolas > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > >

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

On 29 Apr 2011, at 00:32, Nicolas Cellier wrote: > > However, as I understand it, it's entirely up to user to write code > exploiting parallel Process explicitly right ? Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. I don't belief in holy grails or silver bullets. Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

> One silly idea while reading this thread (not the paper): > For single core, the idea makes sense. > It may even extend easily to multicore VM (just forget about Smalltalk > for a while) by counting message sent per core and taking the max. But you are here assuming that all the CPU have the same speed (#messages/sec) right? Alexandre > > Nicolas > > 2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: >> +1 >> >> Alexandre >> >> >> On 28 Apr 2011, at 17:35, Michael Haupt wrote: >> >>> Hi Alex, >>> >>> On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>> I think you're being a bit harsh on stack sampling there. It is exact >>>>> enough to drive optimisation in some really high-performance VMs. It >>>>> is also deterministic enough to yield data leading to very good >>>>> performance results in those VMs. Whether focusing on counting >>>>> messages instead of taking samples is more beneficial would have to be >>>>> determined by experiment ... >>>> >>>> Yes, 25 pages of experiment :-) >>> >>> oh, I was not referring to your paper. I was referring to the general >>> applicability of message counting as opposed to sampling. The latter >>> is true-and-tried in many high performance VMs. For the former, an >>> experiment has yielded good results (from what I take from this thread >>> - I still haven't read your paper, sorry, it's on top of the pile) in >>> a constrained setting. All I was saying is that it is not possible to >>> conclude anything for the broader area from the experiments you >>> conducted. But we're probably of the same opinion here. >>> >>>>> What you mean with "non-portable" I do not understand. >>>> >>>> The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. >>> >>> That is correct, but the approach itself is portable - may I quote >>> you: "Most profilers, including MessageTally, count stack frames at a >>> regular interval. This is doomed to be inexact, non-deterministic and >>> non-portable". You weren't talking about the results. Those are >>> obviously specific to the platform, clock frequency, L1/L2/L3 cache >>> and memory sizes, application input (!) and other factors. >>> >>> Best, >>> >>> Michael >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

Re: [Pharo-project] [TODO] 1.2.2

by Mariano Martinez Peck

BTW...do we need a Pharo 1.2.2 ? can't we directly release Pharo 1.3 ? On Fri, Apr 29, 2011 at 12:43 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Apr 28, 2011 at 10:50 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> - Is it possible to revert to last successful build ? >> >> - Seems related to OB, but I see >> http://code.google.com/p/pharo/issues/detail?id=3842 , so I suppose >> Hudson scripts should be updated but few people have access ? >> >> > I have already done that for PharoDev 1.3. Maybe, it also works in > Pharo1.2.2, hence we can use the copy the Metacello version for pharo 1.2.2. > ConfigurationOfOmnibrowser version '1.3'. > Try it and let me know. > > > >> - Indeed OB maintenance process looks really problematic >> >> - Which mailing-list the mail is sent ? Haven't seen it on pharo-dev (but >> inbox full of mails ahhhhhhh) >> >> >> Laurent >> >> >> On Thu, Apr 28, 2011 at 9:17 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: >> >>> >>> Core: >>> >>> Failing Tests: NONE >>> Open Issues: NONE >>> >>> Full: >>> >>> - Issues: 4. Related to OB: 3 OB2: 1. >>> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2.2-DevImage >>> - the build of Full is broken since April, 14th (2 weeks). >>> A Mail is sent automatically on each failiing build (minimum >>> 1/day) >>> Result: No action. >>> >>> Most important next step: >>> - Fix Build of Full. >>> >>> I really woner why we have the Full image... >>> >>> Marcus >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

April 28, 2011

Re: [Pharo-project] [TODO] 1.2.2

by Mariano Martinez Peck

On Thu, Apr 28, 2011 at 10:50 PM, laurent laffont <laurent.laffont(a)gmail.com > wrote: > - Is it possible to revert to last successful build ? > > - Seems related to OB, but I see > http://code.google.com/p/pharo/issues/detail?id=3842 , so I suppose Hudson > scripts should be updated but few people have access ? > > I have already done that for PharoDev 1.3. Maybe, it also works in Pharo1.2.2, hence we can use the copy the Metacello version for pharo 1.2.2. ConfigurationOfOmnibrowser version '1.3'. Try it and let me know. > - Indeed OB maintenance process looks really problematic > > - Which mailing-list the mail is sent ? Haven't seen it on pharo-dev (but > inbox full of mails ahhhhhhh) > > > Laurent > > > On Thu, Apr 28, 2011 at 9:17 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> Core: >> >> Failing Tests: NONE >> Open Issues: NONE >> >> Full: >> >> - Issues: 4. Related to OB: 3 OB2: 1. >> http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2.2-DevImage >> - the build of Full is broken since April, 14th (2 weeks). >> A Mail is sent automatically on each failiing build (minimum >> 1/day) >> Result: No action. >> >> Most important next step: >> - Fix Build of Full. >> >> I really woner why we have the Full image... >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> > -- Mariano http://marianopeck.wordpress.com

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Alexandre Bergel

+1 Alexandre On 28 Apr 2011, at 17:35, Michael Haupt wrote: > Hi Alex, > > On 29 April 2011 00:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> I think you're being a bit harsh on stack sampling there. It is exact >>> enough to drive optimisation in some really high-performance VMs. It >>> is also deterministic enough to yield data leading to very good >>> performance results in those VMs. Whether focusing on counting >>> messages instead of taking samples is more beneficial would have to be >>> determined by experiment ... >> >> Yes, 25 pages of experiment :-) > > oh, I was not referring to your paper. I was referring to the general > applicability of message counting as opposed to sampling. The latter > is true-and-tried in many high performance VMs. For the former, an > experiment has yielded good results (from what I take from this thread > - I still haven't read your paper, sorry, it's on top of the pile) in > a constrained setting. All I was saying is that it is not possible to > conclude anything for the broader area from the experiments you > conducted. But we're probably of the same opinion here. > >>> What you mean with "non-portable" I do not understand. >> >> The information about the execution time contained in your profile cannot be compared with a new profile realized on a different machine, with a different CPU. > > That is correct, but the approach itself is portable - may I quote > you: "Most profilers, including MessageTally, count stack frames at a > regular interval. This is doomed to be inexact, non-deterministic and > non-portable". You weren't talking about the results. Those are > obviously specific to the platform, clock frequency, L1/L2/L3 cache > and memory sizes, application input (!) and other factors. > > Best, > > Michael > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Nicolas Cellier

2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: > > On 28 Apr 2011, at 23:56, Nicolas Cellier wrote: > >> One silly idea while reading this thread (not the paper): >> For single core, the idea makes sense. >> It may even extend easily to multicore VM (just forget about Smalltalk >> for a while) by counting message sent per core and taking the max. > So, why forget about Smalltalk in this context? > If you don't like the performance of the RoarVM, just integrate the ideas into Cog :-P > Sure, maybe the ;) were de rigueur. However, as I understand it, it's entirely up to user to write code exploiting parallel Process explicitly right ? Nicolas > *scnr* > > Bye the way, I just remember two interesting talks at OOPSLA'09, that are related: > http://www.oopsla.org/oopsla2009/program/research-program/110-reliability-a… > >>> How Java VM Can Get More from a Hardware Performance Monitor >>> Inferred Call Path Profiling > > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > >

April 28, 2011

[Pharo-project] Zinc problems found

by Esteban Lorenzano

Hi, I found some problems on Zinc implementation. Take this example: HTTPSocket httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' args: (Dictionary new at: 'prettyprint' put: #('true'); yourself) accept: '*/*' request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} this, if I have the correct authentication key, gives me the correct answer (an atom-xml response). Now, if I try: ZnHTTPSocketFacade httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' args: (Dictionary new at: 'prettyprint' put: #('true'); yourself) accept: '*/*' request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} (this should work, as the facade is for compatibility, I think) I have two errors, one of them easily solvable, and the other... well... I couldn't solve it in the 15' I spent on it :) 1) arguments are not in the correct way. While HTTPSocket functions expect something like this: Dictionary new at: 'prettyprint' put: #('true'); "<-- Parameter is an array" yourself. ZnHTTPSocketFacade expects something like this: Dictionary new at: 'prettyprint' put: 'true'; "<-- Parameter is a string" yourself. 2) This is the hard one. If you do the get request with parameter fixed, you should get the atom feed. But you don't. You get a ZnResponse who is OK (status 200), but entity is empty. I followed the error until this method: canReadContent ^ self hasContentLength or: [ self isChunked or: [ self allowsReadingUpToEnd ] ] who return false, because none of the questions is true. Then, no entity is filled, and I have no answer :( Hope this help :) Cheers, Esteban

April 28, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Stefan Marr

On 28 Apr 2011, at 23:56, Nicolas Cellier wrote: > One silly idea while reading this thread (not the paper): > For single core, the idea makes sense. > It may even extend easily to multicore VM (just forget about Smalltalk > for a while) by counting message sent per core and taking the max. So, why forget about Smalltalk in this context? If you don't like the performance of the RoarVM, just integrate the ideas into Cog :-P *scnr* Bye the way, I just remember two interesting talks at OOPSLA'09, that are related: http://www.oopsla.org/oopsla2009/program/research-program/110-reliability-a… >> How Java VM Can Get More from a Hardware Performance Monitor >> Inferred Call Path Profiling Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 28, 2011