- Pharo-dev - lists.pharo.org

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 29, 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 29, 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 29, 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 29, 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 29, 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 29, 2011

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

by Alexandre Bergel

>> Most profilers, including MessageTally, count stack frames at a regular interval. This is doomed to be inexact, non-deterministic and non-portable, and so, whatever the effort you will put in the thread scheduling, memory management or whatsoever. > > 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 :-) > 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. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 29, 2011

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

by Nicolas Cellier

2011/4/29 Alexandre Bergel <alexandre.bergel(a)me.com>: >> 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 > Sure, an obvious limitation... >> >> 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 29, 2011

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

by Nicolas Cellier

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. 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

April 28, 2011

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

by Michael Haupt

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

April 28, 2011