Breaking changes in Visual C++ 2015

[Walter Bright via Digitalmars-d]

On 5/9/2015 8:56 PM, deadalnix wrote:
> As long as you are doing trivial toy programs, that is perfect.

The compiler is not a trivial toy program - it's how I made DMC++ still the 
fastest C++ compiler available. I also used it on dmd. dmd being very fast is 
not an accident.


> My bad. It is still clowny that I have to format my code in a particular way to
> get that result. Not formatting my code that way, I never noticed that the
> result even existed in the first place.

Consider:

  5| foo();
  7| if (a && b)

If you were examining the line counts, wouldn't you notice something like that? 
It's pretty obvious that a is executed 5 times and b twice. I use this tool a 
lot. I get what's needed out of them, while keeping the report as a simple printout.


> I can't have the coverage per test case, to know what test is testing what for
> instance (which is arguably mostly due to how tests are ran in the first place).
> It does give me information depending on the formatting of my code. These may
> not seems like important things, but that is what makes the difference.

I saw the report in the picture you linked to. It looks nice. How will it make 
me more productive?


> On the other hand, I have something like:
> $ cat trace.log
> ------------------
>          1    main
> _Dmain    1    45    45
> ------------------
> main    0    0    0
>          1    _Dmain
>
> ======== Timer Is 3579545 Ticks/Sec, Times are in Microsecs ========
>
>    Num          Tree        Func        Per
>    Calls        Time        Time        Call
>
>        1          12          12          12     _Dmain
>        1           0           0           0     main

All that's needed to make DMC++ still the fastest C++ compiler. (The dmd 
profiler is the same as the DMC++ one, but fixed for multithreading.) It tracks 
who are the top time users, and how they get called in a simple format.

I understand that those colorful graphical displays look pretty, and are fun to 
browse around on. What I don't understand is how that translates into a 
programmer being more productive with those results, let alone miles more 
productive.


> For reference, the format used is named callgrind and many tools can manipulate
> it: http://valgrind.org/docs/manual/cl-format.html

Thanks for the link, I've never heard of that before. Switching to it, however, 
now means that the poor user has to download and install more tools to get 
results, and the process of using it is no longer one step.

[If cl-format is really miles better, why not submit a PR to have the dmd report 
generator output that?]

One output from -profile you might not have noticed is a .def file. This sets 
the link order for functions, so that functions that are strongly connected at 
runtime are located adjacent to each other. Makes for much better virtual paging 
and cache performance. It currently only works for Optlink, because nobody cares 
about it.


> I can use both tcmalloc and jemalloc on WAY MORE plateforms that D supports.

My point is you are guaranteed to have the D tools with every D compiler, 
regardless of what platform it is on. And of course you can use tcmalloc and 
jemalloc with D, if you want to.


 > Tested on SDC's test runner, it makes the test runner segfault.

The only known cause of -profile seg faulting was running it on multithreaded 
programs. That's been corrected. If this is something else, without a bugzilla 
report, nothing will happen. And that's true with every language.