Tracy Profiler Integration

[Avrina]

On Tuesday, 4 August 2020 at 16:32:06 UTC, Steven Schveighoffer 
wrote:
> On 8/4/20 12:01 PM, Avrina wrote:
>> On Tuesday, 4 August 2020 at 12:47:54 UTC, Steven 
>> Schveighoffer wrote:
>>> On 8/4/20 4:44 AM, Stefan Koch wrote:
>>>> newCTFE in the end, has a lot less benefit than I first 
>>>> assumed.
>>>
>>> If CTFE becomes way less expensive (in CPU usage and memory 
>>> usage), then the template problem becomes easier as well, as 
>>> we can do more CTFE to replace templates.
>> 
>> CTFE takes 500 ms for my project. It takes a total of about 10 
>> seconds for the frontend to do everything, without -inline. 
>> The more significant problem is definitely templates, their 
>> expansion and how everything is processed back into a AST. 
>> Such as the case if your run CTFE, even "newCTFE" the result 
>> is still going to have to be expanded back into an AST, which 
>> is the core problem.
>
> I have faced much different problems (mostly with memory 
> consumption). Part of the problem of current CTFE is that it 
> consumes lots of memory needlessly (at least that's my 
> recollection). That is part (but not all) of the reason we use 
> recursive templates instead of CTFE to solve our compile-time 
> computation problems.

If you use -lowmem and you still have memory issues, then it 
probably won't help. If it's CTFE. The reason so much memory is 
being used is because at times the compiler is working backwards. 
Even when it has a representation that is smaller and closer to 
what the final result should be, it has to convert it backwards 
into an AST.

> I don't know whether newCTFE fixes ALL the problems or not. But 
> it will still help.

It will very likely introduce new problems as well.

>>>> If I had had a good integrated profiler back then, and some 
>>>> of the code which I have access to now, I would probably 
>>>> never have started newCTFE, and would have tried to fix the 
>>>> template system itself.
>>>
>>> I still think newCTFE has worthwhile benefit, even if it 
>>> alone cannot fix all the problems.
>>>
>>> I think newCTFE and type functions (along with Manu's ... 
>>> DIP) would be a good combination to attack the problem.
>>>
>> 
>> It doesn't help, it just introduces a whole lot of more 
>> complexity into the compiler as well. Effectively it creates a 
>> second compiler within the compiler. It is much more 
>> complicated than the current solution, and I don't imagine the 
>> speed up is going to be that much as, for my case it will only 
>> be able to reduce the build time by a maximum of 500 ms.
>
> What is "It" that you are talking about?
>
> I imagine part of the problem here is that CTFE is avoided 
> because it doesn't deal with types and compile-time lists very 
> well -- you have only one solution there. In which case, CTFE 
> is not used in many places where it really is a natural fit.
>
> So really, if CTFE was more usable, it could replace the vast 
> template usage that is likely causing your build to be slower, 
> and then an optimized CTFE becomes more relevant.
>
> -Steve

It is newCTFE. I haven't looked at type functions, maybe they can 
help, but the larger issue is just how the compiler is 
structured. They can help in some cases, but not all. Part of 
what takes so much memory in my project and the build time, is in 
fact the runtime. I wonder how fast the compile time would be 
with -betterC but I'm not going to modify my project that much to 
figure out.

Have you looked at newCTFE and how it is being implemented and 
exactly what it affects? I think that's just overly positive 
optimism and not how it will end up working (without heavy 
modification, more than what is already being done in regards to 
newCTFE).