>>> 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. Alexandre > > > 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 > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
