11 ms·

I wish they would dedicate more time to improving cl.exe and link.exe in terms of performance and language support and less time with these hokey team visualiza

I wish they would dedicate more time to improving cl.exe and link.exe in terms of performance and language support and less time with these hokey team visualization gimics. Every release since 2008 has been getting slower and slower for C++, the C compiler is awful, PGO instrumentation in Win8 is less capable, and there's no equivalents in the Windows ecosystem to gcc's likely/unlikely, oprofile, or valgrind. It's at the point now where developing on Windows vs Linux is a serious performance and security impediment due to their withering native toolchain. But I guess nobody over there gets promoted for fixing the hard stuff.

darkchasma 13y ago
"hokey team visualization gimics" keep management off the teams ass, so I appreciate a little attention. Though I ultimately agree, there isn't a lot here that's scratching any of our itches.
TylerE 13y ago
How hard would it be to create stub apps that really just call out to clang/llvm?
- archangel_one 13y ago
  Not hard. But how hard would it be to make large existing codebases which have always been built by VC++ compile against them? Very. Let alone the institutional aversion to admitting their competitors have done something better than them...
  - tracker1 13y ago
    Personally I've wanted a project type without a "compile" in VS for a while... mainly for other environments that serve as a client/service for the VS stuff... I often use a "website" project and uncheck it from "build" but that's not quite what is needed. Mainly, as an example, I want to be able to have my NodeJS webservice project in the same solution as my MVC website project, and the C# dll client project. The NodeJS solution doesn't need all the assembly folders, or a .Net compile... but it does need the configured prebuild step, that's it. People say to use a "Website" project, but that brings my entire node_modules tree into source control. It's a pain.
    - Thieum22 13y ago
      Maybe you could try the Makefile Project for this : http://msdn.microsoft.com/en-us/library/txcwa2xx(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/txcwa2xx(v=vs.110).a... You get to decide what happens on build events as far as I remember.
    - katbyte 13y ago
      Perhaps you could create a custom target that overrides the compile\build targets and simply does nothing?
sriramk 13y ago
ex-VS person here (from 5 years ago though). It is never an either-or. It is always a complex mix of what customers ask for, what the strategic priorities/market realities are. Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. On promotions - I think it's the reverse problem. People only get promoted for working on something that's perceived to be hard.
- ajross 13y ago
  > Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. Note that you switch between "devs" and "customer" there. I argue that the real problem is that for VS those demographics are different. Devs in "Microsoft shops" don't go out and decide on a complier, they use VS because that's all there is. And the decision to purchase that compiler is made for them by the suited management class who frankly don't care about C++11 support beyond what they see in a line item checklist. But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them. Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave.
  - pjmlp 13y ago
    > ... they use VS because that's all there is On Windows there are lots of compilers to choose from.
    - mkr-hn 13y ago
      There are other words around those words. ajross is describing a corporate environment where the choice is sometimes made for you.
      - 13y ago
echohack 13y ago
My assessment: Gimmicks: - Popout explorer windows (So you can get the old style Pending Changes window, if you like) - Make comments and discussions on code through web UI - New release management plugin - “Team rooms” allow your team to collaborate on code "I'm OK with this" improvements: - “Indicators” in code that give you info about blocks of code - Cloud load testing - More agile portfolio management options - Test cases can be worked on through web UI Real Improvements: :(
- Locke1689 13y ago
  Do you have any managed improvements you'd really like to see?
- seanmcdirmid 13y ago
  Perhaps this post is just on TFS. If you aren't a PM or working in an enterprise software team, nothing about that will be very exciting.
FactoryFactory 13y ago
From the first few lines of the article: > As usual, there’s so much I will only be able to just skim the surface with this post. Stay tuned for many more posts on my blog, the ALM blog, the Visual Studio blog and others as we reveal more detailed information about all of the new capabilities. >I will not, in this post, be talking about many of the new VS 2013 features that are unrelated to the Application Lifecycle workflows. Stay tuned for more about the rest of the VS 2013 capabilities at the Build conference.
pjmlp 13y ago
C is officially deprecated. Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level. Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already available.
- outside1234 13y ago
  honest question, is the Windows kernel written in C++? If not, what does that team use to build it if "C is deprecated"?
  - pointyhats 13y ago
    The Windows kernel is C++. From what I've seen (shared source), it's mainly C-style C++ though. I didn't see a single template or a class in my travels.
    - munin 13y ago
      If you read the WRK, ntoskrnl is all C...
      - pjmlp 13y ago
        Or a C++ subset in the near future, if the BUILD 2012 remark is true.
        malkia 13y ago
        and most of all extern "C", possibly no exceptions, no RTTI, no global new/delete, etc. - e.g. "embedded"-C++ like (only guessing).
        pjmlp 13y ago
        Most likely yes.
terrymah 13y ago
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.

darkchasma 13y ago

"hokey team visualization gimics" keep management off the teams ass, so I appreciate a little attention. Though I ultimately agree, there isn't a lot here that's scratching any of our itches.

TylerE 13y ago

How hard would it be to create stub apps that really just call out to clang/llvm?

archangel_one 13y ago
Not hard. But how hard would it be to make large existing codebases which have always been built by VC++ compile against them? Very. Let alone the institutional aversion to admitting their competitors have done something better than them...
- tracker1 13y ago
  Personally I've wanted a project type without a "compile" in VS for a while... mainly for other environments that serve as a client/service for the VS stuff... I often use a "website" project and uncheck it from "build" but that's not quite what is needed. Mainly, as an example, I want to be able to have my NodeJS webservice project in the same solution as my MVC website project, and the C# dll client project. The NodeJS solution doesn't need all the assembly folders, or a .Net compile... but it does need the configured prebuild step, that's it. People say to use a "Website" project, but that brings my entire node_modules tree into source control. It's a pain.
  - Thieum22 13y ago
    Maybe you could try the Makefile Project for this : http://msdn.microsoft.com/en-us/library/txcwa2xx(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/txcwa2xx(v=vs.110).a... You get to decide what happens on build events as far as I remember.
  - katbyte 13y ago
    Perhaps you could create a custom target that overrides the compile\build targets and simply does nothing?

sriramk 13y ago

ex-VS person here (from 5 years ago though). It is never an either-or. It is always a complex mix of what customers ask for, what the strategic priorities/market realities are. Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. On promotions - I think it's the reverse problem. People only get promoted for working on something that's perceived to be hard.

ajross 13y ago
> Often the problem with these queries is that there are not enough devs complaining to MSFT. No PM/engg manager is going to ignore a bug/problem if it shows up high in customer requests. Note that you switch between "devs" and "customer" there. I argue that the real problem is that for VS those demographics are different. Devs in "Microsoft shops" don't go out and decide on a complier, they use VS because that's all there is. And the decision to purchase that compiler is made for them by the suited management class who frankly don't care about C++11 support beyond what they see in a line item checklist. But you're right, that clearly the "devs" have preferences. The problem with your mechanism is that they don't express them to you in customer service requests. They just job-hop to another environment, doing Javascript work, or Linux, or Ruby. And you never hear from them. Basically, the way feedback works in this world is with feet, not bug reports. If you build it they will come. If you don't they will leave.
- pjmlp 13y ago
  > ... they use VS because that's all there is On Windows there are lots of compilers to choose from.
  - mkr-hn 13y ago
    There are other words around those words. ajross is describing a corporate environment where the choice is sometimes made for you.
    - 13y ago

echohack 13y ago

My assessment: Gimmicks: - Popout explorer windows (So you can get the old style Pending Changes window, if you like) - Make comments and discussions on code through web UI - New release management plugin - “Team rooms” allow your team to collaborate on code "I'm OK with this" improvements: - “Indicators” in code that give you info about blocks of code - Cloud load testing - More agile portfolio management options - Test cases can be worked on through web UI Real Improvements: :(

Locke1689 13y ago
Do you have any managed improvements you'd really like to see?
seanmcdirmid 13y ago
Perhaps this post is just on TFS. If you aren't a PM or working in an enterprise software team, nothing about that will be very exciting.

FactoryFactory 13y ago

From the first few lines of the article: > As usual, there’s so much I will only be able to just skim the surface with this post. Stay tuned for many more posts on my blog, the ALM blog, the Visual Studio blog and others as we reveal more detailed information about all of the new capabilities. >I will not, in this post, be talking about many of the new VS 2013 features that are unrelated to the Application Lifecycle workflows. Stay tuned for more about the rest of the VS 2013 capabilities at the Build conference.

pjmlp 13y ago

C is officially deprecated. Personally I would like to see proper C++11 support instead of playing around with C++/CX and while they are at it, either provide a native compiler for .NET or improve NGEN's optimizer for C++ performance level. Given that Microsoft had .NET native compilers for Singularity and Windows Phone 8 .NET apps are compiled to native code, it isn't as if they don't have the tooling already available.

outside1234 13y ago
honest question, is the Windows kernel written in C++? If not, what does that team use to build it if "C is deprecated"?
- pointyhats 13y ago
  The Windows kernel is C++. From what I've seen (shared source), it's mainly C-style C++ though. I didn't see a single template or a class in my travels.
  - munin 13y ago
    If you read the WRK, ntoskrnl is all C...
    - pjmlp 13y ago
      Or a C++ subset in the near future, if the BUILD 2012 remark is true.
      - malkia 13y ago
        and most of all extern "C", possibly no exceptions, no RTTI, no global new/delete, etc. - e.g. "embedded"-C++ like (only guessing).
        pjmlp 13y ago
        Most likely yes.

terrymah 13y ago

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.