ThreadPool performance you can see

re: ThreadPool performance you can see

Pravin — Fri, 17 Sep 2010 04:05:08 GMT

Would appreciate if you can share the numbers on .NET 2.0?

re: ThreadPool performance you can see

Surupa — Wed, 21 Apr 2010 05:34:15 GMT

John -

Most VS 2010 and .NET 4 assemblies are already pre-compiled to native code using NGen today. Are you referring to application binaries built using VS 2010?

The .NET Framework and Visual Studio assemblies are pre-compiled in the background when the machine is idle. You can run commands such as "ngen.exe ExecuteQueuedItems" to eagerly generate the images (synchronously)instead of waiting for the machine to be idle. You probably don't want to regenerate existing native images, although there are commands to do that as well.

There isn't however any command that globally opts in all managed code on a given system to be compiled to native code ahead of execution time.

If you can help me understand what you may be trying to accomplish with NGen, I may be able to provide a more informative answer.

BTW, some information about NGen can be found here:

http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx &

http://msdn.microsoft.com/en-us/magazine/cc163610.aspx.

re: ThreadPool performance you can see

John L. Galt — Mon, 19 Apr 2010 22:37:04 GMT

A friend of mine just told me that there is a native command for those running VS2010 that allows them to recompile their assemblies into code native for their architecture.

He said it had to do with running NGEN with (a) specific argument(s) and it would rebuild all of .NET 4 Assemblies (and he may have mentioned 3.5 as well, cannot remember, and I ended up not saving the chat).

Furthermore, once this was performed, any program that then installed that used 4 would also undergo an NGEN process recompilation.

Any ideas on this?

re: ThreadPool performance you can see

Stephen Toub - MSFT — Thu, 15 Apr 2010 15:02:01 GMT

Lasse-

Good questions. An analogy might help here.

Consider a team working on a project. When there's just one person, there's basically no overhead, as that person can chug along getting the job done. When another person comes on to the team, now those two people need to start coordinating, which requires some face to face meetings. Now additional folks come on to the project, and you not only have one-on-ones each week (potentially up to N^2 of them), but also weekly team meetings or daily scrum standups, status reports that need to get written, team reviews with management to understand project progress, people randomly stopping by your office to ask you questions, etc. The more people on the project, the more overhead there is, and this overhead potentially grows greater than linearly with the number of team members. If you just catalogued how much time was being spent in this overhead, and ignored the actual work being done by folks, that's similar to what this test is measuring.

In effect, and continuing with the analogy, .NET 4 hired a good project manager. He ensures there are fewer meetings and that the meetings that are held are kept short. He also pays keen attention to whether the team as a whole is being efficient, and may remove folks from the project if they're actually decreasing the team's productiveness / work throughput rather than increasing it.

Again, keep in mind that this example was pure overhead. As soon as you start adding other "real" work into the work item bodies, you very quickly see these differences level off. The key then is that these improved efficiencies in .NET 4 allow you to break your problem apart into more smaller pieces than you previously could efficiently, which means you can scale your problem to larger and larger systems.

re: ThreadPool performance you can see

Andrea Moro — Thu, 15 Apr 2010 13:10:19 GMT

Iàm looking forward to receive Visual Studio 2010 with the MSDN subscription DVD to enjoy this numbers.

re: ThreadPool performance you can see

Lasse V. Karlsen — Thu, 15 Apr 2010 10:59:53 GMT

Ok, I realize that this measures overhead only, but is there really that much more overhead for a quad-core box? What about a eight-core box then? Are we talking a quadrupling in overhead there as well?

re: ThreadPool performance you can see

Lasse V. Karlsen — Thu, 15 Apr 2010 10:56:22 GMT

Why is the quad-core value for .NET 3.5 nearly 4 times the dual-core value? This seems to tell me that quad-core for a multithreaded .NET 3.5 program is a bad idea, as it will run faster on a dual-core. This is counter-intuitive. What am I interpreting wrong here?

re: ThreadPool performance you can see

Stephen Toub - MSFT — Wed, 14 Apr 2010 15:26:22 GMT

Damon, yes, it's always utilized whatever cores the machine has, up to 32 in a 32-bit process and 64 in a 64-bit process.

re: ThreadPool performance you can see

Damon — Wed, 14 Apr 2010 14:30:56 GMT

Question: in previous version of the .NET, is ThreadPool able to distribute the operations between cores?

re: ThreadPool performance you can see

Davide — Wed, 14 Apr 2010 10:23:27 GMT

Wooow !

Congratulations and thanks !!