vectorization of a simple loop -- not in DMD?

[max haughton]

On Thursday, 14 July 2022 at 13:00:24 UTC, ryuukk_ wrote:
> On Thursday, 14 July 2022 at 05:30:58 UTC, Siarhei Siamashka 
> wrote:
>> On Tuesday, 12 July 2022 at 13:23:36 UTC, ryuukk_ wrote:
>>> I wonder if DMD/LDC/GDC have built in tools to profile and 
>>> track performance
>>
>> Linux has a decent system wide profiler: 
>> https://perf.wiki.kernel.org/index.php/Main_Page
>> And there are other useful tools, such as callgrind. To take 
>> advantage of all these tools, DMD/LDC/GDC only need to provide 
>> debugging symbols in the generated binaries, which they 
>> already do. Profiling applications to identify performance 
>> bottlenecks is very easy nowadays.
>
> I am not talking about linux, and i am not talking about 3rd 
> party tools
>
> I am talking about the developers of DMD/LDC/GDC, do they 
> profile the compilers, do they provide ways to monitor/track 
> performance? do they benchmark specific parts of the compilers?
>
> I am not talking about the output of valgrind
>
> Zig also has: https://ziglang.org/perf/ (very slow to load)
>
> Having such thing is more useful than being able to plug 
> valgrind god knows how into the compiler and try to decipher 
> what does what and what results correspond to what internally, 
> and what about a graph over time to catch regressions?
>
> DMD is very fast at compiling code, so i guess Walter doing 
> enough work to monitor all of that
>
> LDC on the other hand.. they'd benefit a lot by having such 
> thing in place

Running valgrind on the compiler is completely trivial. Builtin 
profilers are often terrible. LDC and GDC and dmd all have 
instrumenting profilers builtin, of varying quality. gprof in 
particular is somewhat infamous.

dmd isn't particularly fast, it does a lot of unnecessary work. 
LDC is slow because LLVM is slow.

We need a graph over time, yes.