On Sun, May 8, 2011 at 5:07 AM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
What approach do you suggest should I take?
I have no idea. You could try and break down the various activities and benchmark them separately I suppose. You could look at the profiles you're already generating in higher resolution to see where the time is going. You could also try and extract the SystemProfiler from OpenQwaq, which will run on Cog, and is better than MessageTally. Andreas wrote it to get around some of MessageTally's limitations. It should hopefully show primitives quite accurately.
Hi. I have already read this several times. From you now, from Alexandre Bergel, from Henrik Johansen, etc. But no one (or maybe I didn't see it) give a list of the real existent MessageTally limitations or problems. So far, the only thing I read is what Eliot says here: "show primitives quite accurately"
So...which are the rest and what is solved by the SystemProfiler from OpenQwaq ??
MessageTally works by using delays to cause a high-priority process to interrupt the process being profiled. So the sample is taken only at a suspension point. The SystemProfiler support in the VM takes a sample either after a primitive has run or when the VM is checking for events, so it takes more accurate samples. Further, the SystemProfiler's VM support also samples the active process when collecting the sampled method, so it more accurately ascribes profiles to processes. MessageTally only profiles a single process. Both suffer from a bug my colleague Yaron Kashai observed this week at Cadence, which is that if GC pauses are long then both profilers will under-measure the GC costs because they both take a single sample before measurement. So e.g. if a GC pause lasts five times longer than the poll time only one sample will be takem. Ideally the SystemProfiler would be extended to maintain a list of sampled methods and processes. best, Eliot
Thanks in advance,
Mariano
HTH Eliot
Cheers Philippe
-- Mariano http://marianopeck.wordpress.com