On 24.08.2012 19:35, timotheecour wrote:
Thanks,
The trace code is in druntime/rt/trace.d. There you can see that the
ticks/sec is just set to the shown constant value for anything but
Windows, but RDTSC is used to read the processor cycles. So the values
are probably off by a factor of 300 to 1000.
So I'm still not sure how to convert those numbers to seconds. Is there
a deterministic way? Is the multiplicative factor (300 to 1000) fixed on
a given machine or what does it depend on ?
The factor should be CPU-cycles-per-second / 3579545, so my estimate was
for a CPU that runs at about 1 - 3.5 GHz.
The time in ms is calculated as (time * 1000000) / freq, so with a
processor speed of 2GHz, this will overflow after about 2000s.
Why not use 64 bit integer instead of 32 bit for counter?
The time is a long, but for current CPU-clock-speeds multiplying it with
1000000 limits the measurable time.
Visual D lets you explore trace.log in a browse window inside Visual
Studio, but I guess this won't help you on OSX.
great! Is there a way to run it on a project build outside of visualD? I
use a makefile instead of relying on visualD's build system. When I open
the profiler window and open trace.log inside nothing is shown. Ideally
all it should do is demangle symbols and convert to a table, so I'm
assuming trace.log is self-contained.
I would have guessed that it should not depend on the system the
trace.log is generated as the D name mangling should be the same. And
even if it is not, the profiler window still displays the mangled names.
If you have an example of a non-working trace.log, you can send it to
me, and I'll have a look.
