Closed GoogleCodeExporter closed 8 years ago
Original comment by collinw
on 29 May 2009 at 4:11
Reid's fixing this as he works on the instrumentation stuff.
Original comment by collinw
on 1 Jun 2009 at 10:38
WITH_TSC is totally broken, it turns out.
First, it didn't work on x86_64. That was why it kept segfaulting yesterday.
Second, the meaning of what it was trying to measure is now lost with
FAST_DISPATCH
and computed gotos. When the TSC stuff was originally written, it made the
assumption that control always made it back to the top of the main eval for
loop, and
that assumption is quite wrong right now. Furthermore, it tries to measure
things
like loop overhead, which if you consider multiple FAST_DISPATCH'ed opcodes in
a row
doesn't really make sense.
In order to make it work the way it used to, we'd have to insert code in the
beginning of the TARGET macro, which would probably hurt performance a lot,
since it
prints to stderr every time it takes a measurement.
To me it seems like the right thing to do is to rip it out and do timings for
what we
really care about, using the same old TSC flag. We should also load the
statistics
up in a vector or something instead of printing to stderr on every opcode
(whose idea
was that?).
So what is it that we really want to profile? Function call overhead seems
like a
place to start, but should I anticipate trying to record information about
other opcodes?
Original comment by reid.kle...@gmail.com
on 2 Jun 2009 at 9:54
This issue was closed by r611.
Original comment by reid.kle...@gmail.com
on 5 Jun 2009 at 7:08
Original issue reported on code.google.com by
thomaswout@gmail.com
on 14 Apr 2009 at 1:34