[Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo
alexandre.bergel at me.com
Thu Apr 28 18:14:23 CEST 2011
>>> Counting messages is, in the average, closely link to the average execution time.
> In the setting of the paper, that might be correct.
> Even for the stated goal of optimizing for performance, it might still be interesting.
> However, the optimizations done based on this criteria are bound to one specific VM implementation.
Not only to the VM, but also to the compiler.
>> I believe this is correct only as long as a purely interpreting VM is
>> used, even though quick messages add a tiny bit of uncertainty. But
>> add a JIT compiler and some inlining, and timeToRun and MessageTally
>> are suddenly interesting again.
> Or have a VM that is not Squeak, and perhaps use a language that is not used in the style Smalltalk is (7 lines of code per method, right?).
Yes, but there hasn't been a major change on the VM front since I started Smalltalk. Cog is the notable exception, but the assumption I made without Cog remains valid with Cog.
> Have only skimmed the paper, Alexandre, so excuse the perhaps stupid question: Why don't you just count the number of executed bytecodes? The correlation between bytecodes and execution time should be even more close than messages to exec time.
Indeed, it does. Counting bytecode instructions is also a valid way to estimate average execution time. There is some work on this (cf the related work section).
Counting bytecode is more expensive than counting messages. In general, my opinion is that OO programming is about sending messages, not executing bytecode. Message counting has also the advantage to be friendlier with a JIT.
> Bye the way, the remark on the mismatch between OO programming and profiling: profiling is about the execution model, and the execution model of Smalltalk is based on a stack machine. To me the execution model seems to be orthogonal to the structuring of the code. I don't see how you can really abstract from that, without coming up with a 'object-oriented' execution model (what ever that would be). Perhaps, the closest to that would be an actor-based execution model, like Erlang's language semantics. No stacks just message buffers.
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 am simply focusing on sending messages, which is in my opinion, the essence of the OO executing model. Using a stack machine is an implementation matter. It is not essential to OO.
> Best regards
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> Phone: +32 2 629 2974
> Fax: +32 2 629 3525
Alexandre Bergel http://www.bergel.eu
More information about the Pharo-project