On Monday, 3 August 2020 at 20:36:51 UTC, Stefan Koch wrote:
> Hello Folks,
>
> I am currently integrating the tracy profiler (https://github.com/wolfpld/tracy)
> with dmd.
>
> Such that instead of the profiler in druntime, tracy can be used for instrumented profiling.
>
>
> The current progress is here: https://github.com/dlang/dmd/compare/master...UplinkCoder:tracy?expand=1
>  there are still some teething problems, but I am confident that it will be useful soon.
>
> Cheers,
>
> Stefan

There are some news of this:

Here is a screenshot of the Tracy profiler integration being used, for a "trivial" hello world example, (in reliity the druntime and phobos templates gave me a bit of trouble  ...)

https://ibb.co/0XKyJd3

The code on the left hand side can be compiled with the -tracy switch.
and run (provided you copy TracyClientNoExit.o) into /tmp/TracyClientNoExit.o
(which you have to compile yourself using https://github.com/UplinkCoder/tracy/tree/fixit
and running the build.sh from there).

Cheers everyone!
Note, currently I am using the c-api for dynamic langauges, which creates source locations every time, that makes the profiling a little more expensive than it would usually be.
Hence even a no-op function will take about a microsecond ... But this can be improved later.

Using tracy I found out that the unsignedTempString function in Phobos is somewhat slow ...
No wonder it divides in a loop.
I'll replace it soon.

On Monday, 10 August 2020 at 21:54:33 UTC, Stefan Koch wrote:
> On Monday, 3 August 2020 at 20:36:51 UTC, Stefan Koch wrote:
>> Hello Folks,
>>
>> I am currently integrating the tracy profiler (https://github.com/wolfpld/tracy)
>> with dmd.
>>
>> Such that instead of the profiler in druntime, tracy can be used for instrumented profiling.
>>
>>
>> The current progress is here: https://github.com/dlang/dmd/compare/master...UplinkCoder:tracy?expand=1
>>  there are still some teething problems, but I am confident that it will be useful soon.
>>
>> Cheers,
>>
>> Stefan
>
> There are some news of this:
>
> Here is a screenshot of the Tracy profiler integration being used, for a "trivial" hello world example, (in reliity the druntime and phobos templates gave me a bit of trouble  ...)
>
> https://ibb.co/0XKyJd3

Nice

> The code on the left hand side can be compiled with the -tracy switch.
> and run (provided you copy TracyClientNoExit.o) into /tmp/TracyClientNoExit.o
> (which you have to compile yourself using https://github.com/UplinkCoder/tracy/tree/fixit
> and running the build.sh from there).
>
> Cheers everyone!
> Note, currently I am using the c-api for dynamic langauges, which creates source locations every time, that makes the profiling a little more expensive than it would usually be.
> Hence even a no-op function will take about a microsecond ... But this can be improved later.

that cant be slower than callgrind !

> Using tracy I found out that the unsignedTempString function in Phobos is somewhat slow ...
> No wonder it divides in a loop.
> I'll replace it soon.

On Monday, 3 August 2020 at 20:36:51 UTC, Stefan Koch wrote:
> Hello Folks,
>
> I am currently integrating the tracy profiler (https://github.com/wolfpld/tracy)
> with dmd.
>
> Such that instead of the profiler in druntime, tracy can be used for instrumented profiling.
>
>
> The current progress is here: https://github.com/dlang/dmd/compare/master...UplinkCoder:tracy?expand=1
>  there are still some teething problems, but I am confident that it will be useful soon.
>
> Cheers,
>
> Stefan

Hi,

Looked at source code, and wondered, is it possible to have an abstraction layer between tracy and injected code?

That way we could eliminate tracy depenedency from dmd, and move it into a library solution, which would then allow us to replace tracy woth other tools if needed. It also would allow preprocessing if needed before event would be sent to tracy server.

On Wednesday, 12 August 2020 at 14:51:08 UTC, Alexandru Ermicioi wrote:
>
> Hi,
>
> Looked at source code, and wondered, is it possible to have an abstraction layer between tracy and injected code?
>
> That way we could eliminate tracy depenedency from dmd, and move it into a library solution, which would then allow us to replace tracy woth other tools if needed. It also would allow preprocessing if needed before event would be sent to tracy server.

I am not sure what you are talking about.
There is no dependency between dmd and tracy.

Are you talking about providing a general profiling interface?
That might be possible but outside of the scope what I am trying to do right now.
Also keep in mind that the number of layers between the profiler and the profiled application diminish the usefulness.

To be honest having to link with a library to use tracy already sucks.
I'd rather inject all the profiling code verbatim, but that's too involved at the moment.

On Thursday, 13 August 2020 at 00:32:34 UTC, Stefan Koch wrote:
> On Wednesday, 12 August 2020 at 14:51:08 UTC, Alexandru Ermicioi wrote:
>>
>> Hi,
>>
>> Looked at source code, and wondered, is it possible to have an abstraction layer between tracy and injected code?
>>
>> That way we could eliminate tracy depenedency from dmd, and move it into a library solution, which would then allow us to replace tracy woth other tools if needed. It also would allow preprocessing if needed before event would be sent to tracy server.
>
> I am not sure what you are talking about.
> There is no dependency between dmd and tracy.
>
> Are you talking about providing a general profiling interface?
> That might be possible but outside of the scope what I am trying to do right now.
> Also keep in mind that the number of layers between the profiler and the profiled application diminish the usefulness.
>
> To be honest having to link with a library to use tracy already sucks.
> I'd rather inject all the profiling code verbatim, but that's too involved at the moment.

There is in your comparison between compiled binary, tracy client and dmd, a hardcoded one (linking tracy client, and injecting calls to tracy client in binary in semantic3 visitor of dmd). If you make a *thin* abstraction between tracy client and dmd, you may move tracy client dependency to druntime instead of dmd, and hide it by a version switch if needed. Then you won't need any -tracy flag in dmd itself, just standard profiling switch. D user would also be able to switch to whatever profiling agent he'd like by providing their own implementation in custom druntime, which would be a lot easier than modifying actual dmd to add support for their profiler. This is also in trend of moving compiler magic into a library solution btw.

Also tracy is client-server application, right? You'll still require some lib or implementation of tracy client side to communicate with server, so I'm not sure what do you mean by injecting profiling code verbatim.

- Alex