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 16:09, Toon Verwaest wrote: > You shouldn't write "do" loops that start at the beginning and go until the end. You should just say that you want the calculation done and that your intent is that you have visited everything. And then of course you might have dependencies etc... but the idea is generally, don't say how to do it, just declare what you want as a result. > > Of course, it doesn't immediately match what we are used to doing: telling the computer how we want things done; but you can't really say that you have to tell the computer more about parallelization. It's exactly the opposite. Well, it is not that easy. You have to include enough information intro the program, and you have to break it down in a way that allows parallelism. For instance, you need to tell the machine that your operators are associative or commutative to enable optimizations and reordering. And there seem to be approaches for instance to infer parallel solutions like prefix-sum algorithms[1] but that is also restricted to certain applications. Nothing general, no holly grail or silver bullet. Best regards Stefan [1] Prefix Sums and Their Applications. Guy E. Blelloch -- 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 Stefan Marr

Hello Alexandre: On 29 Apr 2011, at 16:55, Alexandre Bergel wrote: > I though about your email. I do not understand why automatic parallelization is not the way to go. In my opinion, the computer has much more knowledge about the programmer about where side effects appear and where to cut or split a computation. > > Actually, if I want to be provocative, I would say that parallelization cannot be effective without being automatic. For a similar reason that the compiler will always know better than me how to properly allocate registers. First, compilers have always the limitations and heuristics for the common case. The stuff I am most interested in, i.e., interpreters, are an extreme challenge for compilers. Carefully designed and optimized assembler code will always outperform a compiler in that case. But ok, interpreters are not the common case for most compilers... But still, it is always about what the compiler is allowed to assume and what kind of knowledge is encoded in a program. If you write an inherently sequential program, like an algorithm for huffman decoding, no compiler on the world will stand a chance to automatically parallelize that. However, if you encode you programs in a way, like Guy Steele proposes, that is, making the opportunity for parallelism obvious, than you also have a chance to benefit from that. Thus, solve you problems using data structures that allow parallel execution: get rid of linked lists, abandoned all kind of linear data structures. Use trees! TREES! Trees have always been good for the environment and for humans. And nowadays they are the way to go for green computing ;) And whether you prefer to have you language/VM to do a 'spawn' here or there or whether you put it in explicitly, well, thats a matter of taste or religion... The important thing that matters is that the structure of your problem allows for parallelization. > I feel it would be cheaper for me to buy a faster computer than to learn how to program in a multi-core fashion. Ehm, I assume you haven't bought a computer the last 5 years, otherwise you would have noticed that you can't do that anymore... 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 29, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 56 - HostFont

by Marcus Denker

On Apr 28, 2011, at 6:23 PM, laurent laffont wrote: > Today: HostFont > Seems to be unused. I vote for removing. (together with IdentityGlyphMap) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 29, 2011

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

by Alexandre Bergel

I am not sure to which paper you are referring to. But yes, I read the one that we mentioned in the various emails. "Wake Up and Smell the Coffee" is a good one. Actually, there are several papers on a similar topic. The ones that I like very very much are: - "Producing wrong data without doing anything obviously wrong!" - "Evaluating the accuracy of java profilers." The authors of these papers are Todd Mytkowicz, Amer Diwan, Matthias Hauswirth, and Peter F. Sweeney. These guys really rock. They will be at ecoop. Cheers, Alexandre On 29 Apr 2011, at 04:32, StÃ©phane Ducasse wrote: > alex did you read the OOPSLA paper stefan or michael sent around about profiling and the default flaw in research approach? > > Stef > > On Apr 29, 2011, at 12:40 AM, Alexandre Bergel wrote: > >> +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 Toon Verwaest

Actually if you listen to Guy Steele's talk the whole point is to let the developer be even more ignorant than you are now. You shouldn't write "do" loops that start at the beginning and go until the end. You should just say that you want the calculation done and that your intent is that you have visited everything. And then of course you might have dependencies etc... but the idea is generally, don't say how to do it, just declare what you want as a result. Of course, it doesn't immediately match what we are used to doing: telling the computer how we want things done; but you can't really say that you have to tell the computer more about parallelization. It's exactly the opposite. On 04/29/2011 05:05 PM, Alexandre Bergel wrote: > Interesting result. But still, I feel that the computer should be able to do some inference. This could be at runtime, at compile time or during the development. I think than expecting the user to have the knowledge about how to parallelize an application is too much asking. > > I will read Charlotte's work. > > Alexandre > > > On 29 Apr 2011, at 09:58, Toon Verwaest wrote: > >> I have a hunch that Stefan is referring to the PhD thesis of Charlotte Herzeel without giving names. As far as I understood from my discussions with her (and her talks), it generally doesn't really pay off to automatically parallelize on branches. You get minimal speedups (1% at best). >> >> I tend to agree with Stefan / Michael / Guy Steele... Maybe you don't need much, but the mapreduce style is the minimum requirement to give the language enough "wiggle room" to automatically parallelize stuff. But it DOES require you to restructure your application in a slightly more declarative fashion. >> >> cheers, >> Toon >> >> On 04/29/2011 04:55 PM, Alexandre Bergel wrote: >>> Hi Stefan, >>> >>> I though about your email. I do not understand why automatic parallelization is not the way to go. In my opinion, the computer has much more knowledge about the programmer about where side effects appear and where to cut or split a computation. >>> >>> Actually, if I want to be provocative, I would say that parallelization cannot be effective without being automatic. For a similar reason that the compiler will always know better than me how to properly allocate registers. >>> >>> I feel it would be cheaper for me to buy a faster computer than to learn how to program in a multi-core fashion. >>> >>> Cheers, >>> Alexandre >>> >>> >>>>> 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... >>> >>

April 29, 2011

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

by Toon Verwaest

I have a hunch that Stefan is referring to the PhD thesis of Charlotte Herzeel without giving names. As far as I understood from my discussions with her (and her talks), it generally doesn't really pay off to automatically parallelize on branches. You get minimal speedups (1% at best). I tend to agree with Stefan / Michael / Guy Steele... Maybe you don't need much, but the mapreduce style is the minimum requirement to give the language enough "wiggle room" to automatically parallelize stuff. But it DOES require you to restructure your application in a slightly more declarative fashion. cheers, Toon On 04/29/2011 04:55 PM, Alexandre Bergel wrote: > Hi Stefan, > > I though about your email. I do not understand why automatic parallelization is not the way to go. In my opinion, the computer has much more knowledge about the programmer about where side effects appear and where to cut or split a computation. > > Actually, if I want to be provocative, I would say that parallelization cannot be effective without being automatic. For a similar reason that the compiler will always know better than me how to properly allocate registers. > > I feel it would be cheaper for me to buy a faster computer than to learn how to program in a multi-core fashion. > > Cheers, > Alexandre > > >>> 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... > >

April 29, 2011

Re: [Pharo-project] XML and DTD

by Olivier Auverlot

Le 29/04/11 14:02, Torsten Bergmann a Ã©crit : > AFAIK there are various possibilities to check an XML: > a) using an internal DTD > b) using an external DTD (in a file) > c) using an external schema > d) mixing internal dtd and external dtd > > To validate using an internal DTD (a) the validation > on the parser has to be set to true. Thats all, at least > in Java: > > DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); > factory.setValidating(true); > > Havent tried the Pharo implementation, dont know if it is > complete or not. Maybe a) is at least supported. > > Only Michael RÃ¼ger (Impara.de) may be able to tell you > since he wrote the original code AFAIK. > > You can also dig through the code or try an example > to see if the setting #isValidating: has any effect. > Setting #isValidating seems not have any effect. The parser ignores the errors in the XML file. > Did you check the unit tests on squeaksource.com/XMLSupport > Maybe they are useful too. I had not found any complementary informations into this files aaarrrgh ! I think that validating is not possible with XML-Parser... Doctor Who. Where are you ? :-) > Bye > T. > >

April 29, 2011

Re: [Pharo-project] Explicit control of Parallel execution in Smalltalk ? (was Counting Messages as a Proxy for Average Execution Time in Pharo)

by Nicolas Cellier

2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: > Hi: > > On 29 Apr 2011, at 02:18, Nicolas Cellier wrote: > >> 2011/4/29 Stefan Marr <pharo(a)stefan-marr.de>: >>> >>> 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 >>> >> >> Interestingly, I was thinking of Xtreams as an obvious Smalltalk test >> case for parallelism. > Hm, you refer to http://code.google.com/p/xtreams/ ? > Maybe its just my missing imagination, but Xtreams alone do not look like they help here a lot. > It's just that Xtreams wrapper structure is equivalent to unix pipes, but that's only a particular form of parallelism. Nicolas > >> But of course choosing manually an optimal multi-Process >> implementation is far from easy... > Right, and that is also not what I meant with 'automatic parallelization does not work'. > I just think, that you will need to formulate your problems in a way that the opportunity for parallelism is obvious. > There is no smart compiler that will parallelize something _in the spirit of_ a recursively defined factorial. > I think, we will be forced to formulate our problems in some way that is not inherently sequential. (That is basically also what Michael referred to with Guy Steele's work, Fortress is all about trees, and I also assume that this is the best bet for the moment.) > Data-flow/stream languages force you to do that, Fork/Join and map reduce are also about forcing your problem into a structure that is manageable. > And then, we can apply something like a work-stealing scheduler and we do not need to specify how the computation is to be distributed over the available computational resources. > > > However, there is always a big constant factor in all this on todays machines, and we are still forced to think about a sequential cut-off. Hopefully we can apply some of that automatic fusing of fine-grained parallelism to get a good-enough solution to avoid having to think about sequential cut-offs. (Which still will remain interesting since certain sequential strategies will always outperform naive divide-and-conquer strategies.) > > > >> Reading http://cag.lcs.mit.edu/commit/papers/06/gordon-asplos06-slides.pdf >> reinforce my feeling that it shall not be optimized manually, and that >> user shall not design/assign Process directly. >> I don't know what the >> right abstraction would be in Smalltalk though such that a VM could do >> it, and neither do I understand how StreamIT solves the optimization, >> but thanks for these interesting clues. > Fine-grained parallelism and a good scheduling approach help already a lot. Work-stealing seems to be the state-of-the-art solution for that. And hopefully, we will get to replace the stupid scheduler in the RoarVM with a work-stealing one soon. (But a CogJIT RoarVM would help real-world performance more ;)) > > 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 29, 2011

[Pharo-project] XML and DTD

by Torsten Bergmann

AFAIK there are various possibilities to check an XML: a) using an internal DTD b) using an external DTD (in a file) c) using an external schema d) mixing internal dtd and external dtd To validate using an internal DTD (a) the validation on the parser has to be set to true. Thats all, at least in Java: DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setValidating(true); Havent tried the Pharo implementation, dont know if it is complete or not. Maybe a) is at least supported. Only Michael RÃ¼ger (Impara.de) may be able to tell you since he wrote the original code AFAIK. You can also dig through the code or try an example to see if the setting #isValidating: has any effect. Did you check the unit tests on squeaksource.com/XMLSupport Maybe they are useful too. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

April 29, 2011

Re: [Pharo-project] XML and DTD

by Alexandre Bergel

Hi Olivier! There no documentation as far I am aware of. If you find a way to solve your problem, please write tests about it Alexandre Le 29 avr. 2011 Ã 06:11, Olivier Auverlot <olivier.auverlot(a)gmail.com> a Ã©crit : > Le 28/04/11 14:38, StÃ©phane Ducasse a Ã©crit : >> On Apr 28, 2011, at 11:58 AM, Olivier Auverlot wrote: >> >>> Hi, >>> >>> Now, I'm playing with XML-Parser. It's a funny game but I have a little question. How to validate a XML file with a DTD ? >> I do not know. > > I need this to validate XML data received by my application. XML-Parser seems to contain the tools required. There is a category named XML-Parser-DTD. In the category XML-Parser, there is a method named XMLConfiguration>>#isValidating. But how use them ? > > Someone has a link to a documentation, an exemple, an information, an bottle that contains a message, something ? > > What are the alternative ways to parsing XM, generating XML and validating XML data ? > > Olivier ;-) > www.auverlot.fr >> In VisualWorks there was a kind of validator now in XMLwriter....package I do not know. >> >>> Thank for your help. >>> >>> Best regards >>> Olivier ;-) >>> >>> www.auverlot.fr >>> >> > >

April 29, 2011