On Sun, Oct 03, 2021 at 08:31:14AM +0000, Chris Katko via Digitalmars-d wrote: [...]
> The function that dmd's -profile reported was the biggest user of CPU time was a tiny little function that draws a couple background tiles. (<30 at worst case) As opposed to everything else being drawn, tons of opengl primitives, graphical text, text being converted with tons of writelns to console, etc.
[...]

Be aware that dmd -profile uses *16-bit counters* for tracking function call counts; if your program is CPU-intensive and calls the same function(s) in inner loops more than 65535 times, the counters will wrap around and cause the profile output to be garbled.

I ran into this a couple of years ago when trying to profile some CPU-intensive code with some non-trivial testcases, and found dmd -profile output completely unusable because of this limitation.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.

On Sunday, 3 October 2021 at 21:55:29 UTC, H. S. Teoh wrote:
> Be aware that dmd -profile uses *16-bit counters* for tracking function call counts;

WHAT?! Wouldn't 32/64 bit (architecture native) values be faster for memory accesses anyway??

On Sunday, 3 October 2021 at 21:55:29 UTC, H. S. Teoh wrote:
> On Sun, Oct 03, 2021 at 08:31:14AM +0000, Chris Katko via Digitalmars-d wrote: [...]
>> The function that dmd's -profile reported was the biggest user of CPU time was a tiny little function that draws a couple background tiles. (<30 at worst case) As opposed to everything else being drawn, tons of opengl primitives, graphical text, text being converted with tons of writelns to console, etc.
> [...]
>
> Be aware that dmd -profile uses *16-bit counters* for tracking function call counts; if your program is CPU-intensive and calls the same function(s) in inner loops more than 65535 times, the counters will wrap around and cause the profile output to be garbled.
>
> I ran into this a couple of years ago when trying to profile some CPU-intensive code with some non-trivial testcases, and found dmd -profile output completely unusable because of this limitation.
>
>
> T

What the... I had no idea but that alone deems it useless to me.

03.10.2021 19:20, max haughton пишет:
> On Sunday, 3 October 2021 at 08:31:14 UTC, Chris Katko wrote:
>> Does it break down on multi-threaded scenarios?
>>
>> I'm running dmd (newest) + Allegro (a C game programming library) with DAllegro (a nice templated binder). My executable is multi-threaded (mostly just helper functions / glue logic from libraries/D/etc), and using OpenGL on 64-bit Linux with a very recent DMD release.
>>
>> [...]
> 
> Unless your profiler does call stack sampling (which I don't think gprof or dmd does), don't use it. They're not reliable unless you are doing very targeted profiling.
> 
> For profiling code, if you're on an Intel, vTune is top dog. Nothing else is as good.

Both sampling and instrumenting profiling can be unreliable. Sampling profiler results are subject to sampling rate for example. Instrumenting profiler can change timings too much. In fact, sampling and instrumentation complement each other.

On Monday, 4 October 2021 at 06:10:00 UTC, bauss wrote:
> On Sunday, 3 October 2021 at 21:55:29 UTC, H. S. Teoh wrote:
>> On Sun, Oct 03, 2021 at 08:31:14AM +0000, Chris Katko via Digitalmars-d wrote: [...]
>>> [...]
>> [...]
>>
>> Be aware that dmd -profile uses *16-bit counters* for tracking function call counts; if your program is CPU-intensive and calls the same function(s) in inner loops more than 65535 times, the counters will wrap around and cause the profile output to be garbled.
>>
>> I ran into this a couple of years ago when trying to profile some CPU-intensive code with some non-trivial testcases, and found dmd -profile output completely unusable because of this limitation.
>>
>>
>> T
>
> What the... I had no idea but that alone deems it useless to me.

Maybe we can change it

On Wed, Oct 06, 2021 at 05:34:54AM +0000, Imperatorn via Digitalmars-d wrote:
> On Monday, 4 October 2021 at 06:10:00 UTC, bauss wrote:
> > On Sunday, 3 October 2021 at 21:55:29 UTC, H. S. Teoh wrote:
[...]
> > > Be aware that dmd -profile uses *16-bit counters* for tracking function call counts; if your program is CPU-intensive and calls the same function(s) in inner loops more than 65535 times, the counters will wrap around and cause the profile output to be garbled.
> > > 
> > > I ran into this a couple of years ago when trying to profile some CPU-intensive code with some non-trivial testcases, and found dmd -profile output completely unusable because of this limitation.
[...]
> > What the... I had no idea but that alone deems it useless to me.
> 
> Maybe we can change it

That would be very nice.  I believe the code is somewhere in druntime. It would save a lot of grief in the future. :-)


T

-- 
An elephant: A mouse built to government specifications. -- Robert Heinlein