5 ms·

Current VS-compiler dev here, the backend codegen team to be more precise (I actually own PGO). I wish this comment had been written in few days/weeks/months so

Current VS-compiler dev here, the backend codegen team to be more precise (I actually own PGO). I wish this comment had been written in few days/weeks/months so I answer directly and talk specifics about some of the work that went into VS2013, but for now I just want you to know we've aware of all of the issues you brought up, and have either worked on or plan to work on many of them. RE: likely/unlikely, VS has __assume(0), which isn't exactly the same thing I know, but it is something and does help. I'm actually in favor of us doing more with static annotations to bring PGO style optimizations to non-PGO builds. If you feel the same way please be louder about it, but realize there is a vocal group of people who consider static annotations harmful (and they have a large body of evidence in __forceinline backing them up). oprofile: There is ETW/xperf, and of course a variety of instrumented profilers (both shipping and internal) Although I do wish my team was larger, and it doesn't get all the love that some of the more flashing UI stuff does, I wouldn't go as far as to say the toolchain is withering. Some of the smartest people I know are working on my team with me on these problems.

CoolGuySteve 13y ago
I work on an extremely latency sensitive application. The choice of Windows predates me, and frankly, it was a massive mistake. I am never working on Windows again after this job. Here's some feedback for low latency development in Visual Studio. Try not to take it personally, I don't hate you, I just hate every MSVC I've ever used: - With a profiler, we typically see only a few hundred samples in our simulation runs, the rest, between 99.999% and 99.99999% of the samples are in WaitForSingleObject. PGO compiles only 0.4% of our application for speed, and our response times are about 20 usecs slower with it on. - RE xperf (and WinDbg): Stop bundling this shit in "Toolkits". The installers/downloaders are buggy as fuck and break the main VS2012 installer; I don't want to run a bunch of random msi files on our prod server core box; and the download pages are a maze of redirects. - __assume is so useless. How often does someone write a branch that does nothing every time? We need manual size/speed optimization. - PogoAutoSweep crashes threaded programs if you don't suspend every other thread but it's still quasi documented. The PogoSafeMode build flag/environment appears to be ignored. - The filename postfix that PogoAutoSweep adds breaks the VS2012 PGO menu options. - The VS2012 PGO instrumented/optimized menu items overwrite the target exe. So when you realize somethings wrong in the environment or click something by mistake and didn't manually reshuffle the build dir, you have to rebuild everything. Name the target .instrument.exe or put it in another or something please. - There's nothing one can do to limit the VS2012 profiler to specific threads. I was able to write hooks to target threads in VerySleepy in an afternoon, but somehow this feature escapes MS. - The interface for instrumenting specific functions is terrible, use a plain text file or decl_spec FFS. - If there are #defines or other ways to detect an instrumented build, they're terribly documented. - PGO instrumentation/optimization is woefully obtuse. What did it pick for speed? Why did it pick it? What branches did it fold/unfold? How does the pgc weighting actually work? Can I artificially create my own pgc? A perl script that compares the offsets in objdump will give me more information than most of the MSDN articles about this shit. - Not related to our main response loop, but we can see in our logging threads that the LFH malloc appears to often call RtlAnsiStringToUnicodestring. Seriously, what the fuck? - Speaking of which, changing the malloc implementation is still horrible even after the VS2010 msvcrt changes. In linux, you can change LD_PRELOAD and try out tcmalloc or the Intel tbb allocator in about 3 minutes. In Visual Studio, prepare to spend a few hours getting a reasonably large project to build with these. - Why is there SemaphoreSlim in C# but not C++? Why is there no Benaphore primitive that can also be used in WaitForMultipleObjects? - Serious issues in Microsoft Developer Connect are often ignored, closed as behaves as expected, or dismissed off hand. For example, I was tearing my hair out over this one, and the resolution is truly outrageous: http://connect.microsoft.com/VisualStudio/feedback/details/772408/cant-include-stdio-h-among-others-after-installing-vs2012-update-1 http://connect.microsoft.com/VisualStudio/feedback/details/7... I am certain that this comment on Hacker News will make a bigger impact than anything I've ever seen on Microsoft Connect. - RE Instrumenting profilers/bounds checkers: Any project that is reasonably large and has multiple configs/3rd party libraries is bad enough to manage in vanilla Visual Studio that instrumenting it with some other 3rd party plugin becomes a serious time sink. - There is still no valgrind/cachegrind equivalent that provides the same level of detail. The closest thing is either Intel Pin or Rational Purify/Quantify and they are expensive and poor substitutes. Microsoft is the only company that can see and modify the source of the kernel, runtime, linker, and machine code generation, so I don't know who else they expect to write this for them. - Our statically linked application takes 20 minutes link and the link is not parallel. C++ compiles are likewise brutally slow. We resort to developing in VS2008 and compiling release stuff in VS2012. And no, I'm not going to turn on precompiled headers, MSVC builds incorrect binaries about 5% of the time as it is. - Concerning precompiled headers, sharing a single pch file across projects or strictly controlling a single vcproj/vcxproj with the compiled unit is de facto impossible.
- malkia 13y ago
  I also have this gripe - why every version of Visual Studio has to change so much drastically the CRT version, thus requiring new DLL and breaking all plugins that happen to be linking to some other version. This basically means, if you are using (say) Autodesk products, you have to compile all your plugins with exactly the same version the main product (exe) was compiled. This is absolute mess. Talk about 7 different MSVCRxx.DLL and MSVCPxx.DLL in one process. Why can't you think of scheme where backward compatibility works for the CRT/C++RT too? Oh, and on naming things - please stick with VS2012 -> CRT2012 if possible. Also why ShortName / PlatformName in VisualStudio is named so crazy - one amd64/x64 vs Win32/x86 - and then SDK's coming from Microsoft would place in the lib/ folder things sometimes with lib/$(ShortName) and sometimes with lib/$(PlatformName). I know why - because these things are not important. Just hard-code it in your .vcxproj and live a happier life :) Automation begone!
- idwhence 13y ago
  On a related topic - may I seriously ask how we as a community of technologists can help change the tone directed at our brothers and sisters in code? It's no wonder more people from Microsoft don't bother engaging when the first (so far only) reply is a hostile tirade about random collection of complaints that have nothing to do with the person being replied to.
  - com2kid 13y ago
    I'll be perfectly honest, when I was working on the MS compiler team (for CE), I just sort of got used to it. But yes, thick skin is required for those who self identify! Then again I have always held the view that if my users are unhappy, it is a personal failing on the part of my team and myself. (Although I am low enough on the software engineering totem poll that I can't really do anything outside of ensure components I create are as user friendly and high quality as possible!)
  - CoolGuySteve 13y ago
    While you make a valid point about the tone (this specific area has wasted the last 2 weeks of my life), I think you're being disingenuous regarding the " random collection of complaints that have nothing to do with the person being replied to" comment. This person works on PGO and code generation and wanted feedback. Everything I said related to PGO, instrumentation, or parts of the CRT that relate to that (and one about their broken feedback system).
ksk 13y ago
Despite having such massive resources why does the Microsoft C++ compiler frontend suck so much when it comes to standards conformance? You guys are always consistently last when it comes to that.

CoolGuySteve 13y ago

I work on an extremely latency sensitive application. The choice of Windows predates me, and frankly, it was a massive mistake. I am never working on Windows again after this job. Here's some feedback for low latency development in Visual Studio. Try not to take it personally, I don't hate you, I just hate every MSVC I've ever used: - With a profiler, we typically see only a few hundred samples in our simulation runs, the rest, between 99.999% and 99.99999% of the samples are in WaitForSingleObject. PGO compiles only 0.4% of our application for speed, and our response times are about 20 usecs slower with it on. - RE xperf (and WinDbg): Stop bundling this shit in "Toolkits". The installers/downloaders are buggy as fuck and break the main VS2012 installer; I don't want to run a bunch of random msi files on our prod server core box; and the download pages are a maze of redirects. - __assume is so useless. How often does someone write a branch that does nothing every time? We need manual size/speed optimization. - PogoAutoSweep crashes threaded programs if you don't suspend every other thread but it's still quasi documented. The PogoSafeMode build flag/environment appears to be ignored. - The filename postfix that PogoAutoSweep adds breaks the VS2012 PGO menu options. - The VS2012 PGO instrumented/optimized menu items overwrite the target exe. So when you realize somethings wrong in the environment or click something by mistake and didn't manually reshuffle the build dir, you have to rebuild everything. Name the target .instrument.exe or put it in another or something please. - There's nothing one can do to limit the VS2012 profiler to specific threads. I was able to write hooks to target threads in VerySleepy in an afternoon, but somehow this feature escapes MS. - The interface for instrumenting specific functions is terrible, use a plain text file or decl_spec FFS. - If there are #defines or other ways to detect an instrumented build, they're terribly documented. - PGO instrumentation/optimization is woefully obtuse. What did it pick for speed? Why did it pick it? What branches did it fold/unfold? How does the pgc weighting actually work? Can I artificially create my own pgc? A perl script that compares the offsets in objdump will give me more information than most of the MSDN articles about this shit. - Not related to our main response loop, but we can see in our logging threads that the LFH malloc appears to often call RtlAnsiStringToUnicodestring. Seriously, what the fuck? - Speaking of which, changing the malloc implementation is still horrible even after the VS2010 msvcrt changes. In linux, you can change LD_PRELOAD and try out tcmalloc or the Intel tbb allocator in about 3 minutes. In Visual Studio, prepare to spend a few hours getting a reasonably large project to build with these. - Why is there SemaphoreSlim in C# but not C++? Why is there no Benaphore primitive that can also be used in WaitForMultipleObjects? - Serious issues in Microsoft Developer Connect are often ignored, closed as behaves as expected, or dismissed off hand. For example, I was tearing my hair out over this one, and the resolution is truly outrageous: http://connect.microsoft.com/VisualStudio/feedback/details/772408/cant-include-stdio-h-among-others-after-installing-vs2012-update-1 http://connect.microsoft.com/VisualStudio/feedback/details/7... I am certain that this comment on Hacker News will make a bigger impact than anything I've ever seen on Microsoft Connect. - RE Instrumenting profilers/bounds checkers: Any project that is reasonably large and has multiple configs/3rd party libraries is bad enough to manage in vanilla Visual Studio that instrumenting it with some other 3rd party plugin becomes a serious time sink. - There is still no valgrind/cachegrind equivalent that provides the same level of detail. The closest thing is either Intel Pin or Rational Purify/Quantify and they are expensive and poor substitutes. Microsoft is the only company that can see and modify the source of the kernel, runtime, linker, and machine code generation, so I don't know who else they expect to write this for them. - Our statically linked application takes 20 minutes link and the link is not parallel. C++ compiles are likewise brutally slow. We resort to developing in VS2008 and compiling release stuff in VS2012. And no, I'm not going to turn on precompiled headers, MSVC builds incorrect binaries about 5% of the time as it is. - Concerning precompiled headers, sharing a single pch file across projects or strictly controlling a single vcproj/vcxproj with the compiled unit is de facto impossible.

malkia 13y ago
I also have this gripe - why every version of Visual Studio has to change so much drastically the CRT version, thus requiring new DLL and breaking all plugins that happen to be linking to some other version. This basically means, if you are using (say) Autodesk products, you have to compile all your plugins with exactly the same version the main product (exe) was compiled. This is absolute mess. Talk about 7 different MSVCRxx.DLL and MSVCPxx.DLL in one process. Why can't you think of scheme where backward compatibility works for the CRT/C++RT too? Oh, and on naming things - please stick with VS2012 -> CRT2012 if possible. Also why ShortName / PlatformName in VisualStudio is named so crazy - one amd64/x64 vs Win32/x86 - and then SDK's coming from Microsoft would place in the lib/ folder things sometimes with lib/$(ShortName) and sometimes with lib/$(PlatformName). I know why - because these things are not important. Just hard-code it in your .vcxproj and live a happier life :) Automation begone!
idwhence 13y ago
On a related topic - may I seriously ask how we as a community of technologists can help change the tone directed at our brothers and sisters in code? It's no wonder more people from Microsoft don't bother engaging when the first (so far only) reply is a hostile tirade about random collection of complaints that have nothing to do with the person being replied to.
- com2kid 13y ago
  I'll be perfectly honest, when I was working on the MS compiler team (for CE), I just sort of got used to it. But yes, thick skin is required for those who self identify! Then again I have always held the view that if my users are unhappy, it is a personal failing on the part of my team and myself. (Although I am low enough on the software engineering totem poll that I can't really do anything outside of ensure components I create are as user friendly and high quality as possible!)
- CoolGuySteve 13y ago
  While you make a valid point about the tone (this specific area has wasted the last 2 weeks of my life), I think you're being disingenuous regarding the " random collection of complaints that have nothing to do with the person being replied to" comment. This person works on PGO and code generation and wanted feedback. Everything I said related to PGO, instrumentation, or parts of the CRT that relate to that (and one about their broken feedback system).

ksk 13y ago

Despite having such massive resources why does the Microsoft C++ compiler frontend suck so much when it comes to standards conformance? You guys are always consistently last when it comes to that.