Visual Studio 2008、2010 或 2012 (v11) 是为使用多核而编写的吗?

发布于 2024-08-13 05:33:38 字数 518 浏览 4 评论 0原文

基本上我想知道 2010 年和 2012 年的 Visual Studio IDE 和/或编译器是否是为了利用多核环境而编写的(我知道我们可以使用并行性在所有版本中针对多核环境,但这不是我的问题)。

我正在尝试决定是否应该获得更高时钟频率的双核或更低时钟频率的四核,因为我想尝试找出哪个处理器将为我提供 Visual Studio 2010 或 2012 (v11) 的绝对最佳体验( ide 和后台编译器)。

如果他们在一个核心中运行最重要的部分(后台编译器和其他 ide 任务),那么如果运行四核,核心将更快地被切断,特别是如果后台编译器是最繁重的任务,我想这会很困难分离多个进程,因此即使它使用多核,如果大部分处理仍然必然发生在一个核中(即 VS 的最重要部分),您可能仍然最好选择更高时钟的 CPU环境)。

我是一名 VB 程序员,他们在 2010 年和 2012 年取得了巨大的性能改进,恭喜(除了可怕的灰度设计和到处都是大写),但我希望能够无缝地使用 VS...任何人都有想法?另外,我不太担心解决方案加载时间,因为我一次只编写一个项目。

谢谢。

Basically i want to know if the visual studio IDE and/or compiler in 2010 and 2012 was written to make use of a multi core environment (i understand we can target multi core environments in all versions using parallelism, but that is not my question).

I am trying to decide on if i should get a higher clock dual core or a lower clock quad core, as i want to try and figure out which processor will give me the absolute best possible experience with Visual Studio 2010 or 2012 (v11) (ide and background compiler).

If they are running the most important section (background compiler and other ide tasks) in one core, then the core will get cut off quicker if running a quad core, especially if background compiler is the heaviest task, i would imagine this would be difficult to separate in more than one process, so even if it uses multi cores you might still be better off going for a higher clock CPU if the majority of the processing is still bound to occur in one core (i.e. the most significant part of the VS environment).

I am a VB programmer, they've made great performance improvements in 2010 and 2012, congrats (except for the horrid grey scale design and the uppercase everywhere), but I would love to be able to use VS seamlessly... anyone have any ideas? Also, I'm not too worried about solution load time, as I only code one project at a time.

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

乖乖哒 2024-08-20 05:33:38

MSBuild 支持并行构建项目。 Visual Studio 2008 利用多个处理器来编译项目

MSBuild supports building projects in parallel. Visual Studio 2008 takes advantage of multiple processors to compile projects.

一抹淡然 2024-08-20 05:33:38

正如其他人所指出的,MSVS 2010 确实使用多个进程进行编译。尽管如此,它不会自动转换为大大减少编译时间。
我刚刚对一个中型 C++ 项目(大约 200 个文件)进行了测试。
它在 3.4 Ghz 的双核上构建速度比 2.8Ghz 的四核更快。虽然双核处理器更便宜。 (系统实际上与每个 4GiB DDR2 Ram 相同)。
我还必须指出,在编译过程中,双核处理器的负载最大为 70%。正如您所看到的,如果 VS2010 甚至 2 个核心都无法完全加载,那么拥有 4 个或更多核心有什么意义呢?

As other people have noted, MSVS 2010 does indeed use multiple processes for compilation. Although, it does not automatically converts into heavily reduced compilation time.
I have just made a test with a middle sized C++ project (around 200 files).
It built faster on Dual Core at 3.4 Ghz than Quad Core at 2.8Ghz. Although Dual Core processor is cheaper. (Systems are practically identical with 4GiB DDR2 Ram each).
I must note also, that during compilation Dual Core processor was loaded to 70% max. As you can see, if VS2010 can not fully load even 2 cores, what is the point of having 4 or more?

诗酒趁年少 2024-08-20 05:33:38

我认为使用更高时钟频率的双核可能会更好。我认为 VS(以及当今的大多数应用程序)尚未充分利用多线程的优势。 VS 可能有数十个线程在运行,但我认为只有一小部分操作真正充分利用了它们。 VS 的大部分实现都是在 STA 线程上运行的 C++ COM 组件,因此 UI 线程在许多情况下完成了大部分工作。事实上,作为 VS2010 的一部分,VS shell 的许多部分都被用托管代码重写,这将有助于打破更多这些古老的组件 STA 依赖性。正如其他人提到的,一些关键场景(例如构建大型解决方案)已经利用了多个核心(MSBuild 可以很好地并行工作),因此,如果这些场景主导了您关心的内容,那么更多核心会更好。但对于IDE UI使用和后台编译之类的事情,我认为大部分仍然是单线程的。我工作时使用的是四核机器,我很少看到 VS2008 使用超过 25% 的 CPU 资源。 (我还没有足够认真地使用 VS2010,不知道哪些场景更好,尽管我知道至少有一些场景更好。)

I think you're probably better off with a higher-clock dual core. I think VS (and most apps today) do not yet take great advantages of multi-threading. VS may have dozens of threads running, but only a subset of operations really take advantage of them well I think. A whole lot of the VS implementation is C++ COM components that run on the STA thread, so the UI thread does the bulk of the work in many scenarios. The fact that many pieces of the VS shell are being rewritten in managed code as part of VS2010 will help break a lot more of these ancient component STA dependencies. As others have mentioned, some key scenarios (like building a large solution) already do take advantage of multiple cores (MSBuild works well in parallel), so if those dominate what you care about, then more cores is better. But for things like IDE UI usage and background compilation, I think most of these are still mostly single-threaded. I've a quad-core box at work, and I rarely see VS2008 use more than 25% of my CPU resources. (I've not used VS2010 enough in earnest to know which scenarios are better, though I know at least a few are better.)

本王不退位尔等都是臣 2024-08-20 05:33:38

忘记CPU。可以为您的机器带来最大的性能提升的是固态硬盘。 Resharper 和 Intellisense 等编译和后台进程的 IO 密集程度很高,因此 Visual Studio 的主要瓶颈是 IO。我从来没有见过 VS 最大化 CPU,无论我是像现在这样使用单核、双核、四核还是 8 核。

更新
感谢您的评论@Erx...我不是正在发生的确切过程的专家。但是,如果您考虑一下编译器为了编译一个项目而进行了多少次读取,您就不会对 IO 命中感到惊讶。 Visual Studio 可能会将文件保存在内存中,但是您是否注意到,当您构建项目并且有未保存的更改时,文件会在构建开始之前首先保存?这告诉我 msbuild 编译器正在访问保存的文件,并且它不使用内存中的文件。如果您在 VS 中关闭了某个文件,则无法保证该文件仍然在内存中,因为它可能已被 VS 的内存管理清除。所以编译器得到一个干净的副本是有道理的。这可能是数百或数千个文件。然后是编译输出的写入、NuGet 包读取、ConfigGen 脚本(http://configgen.codeplex.com/)。你明白了。

另外,我在某处读到,Intellisense 对文件系统进行了大量的读取和写入,因此如果您的硬盘驱动器速度较慢,这将对性能造成额外的影响。

Resharper 等插件也会攻击文件系统,特别是在后台编译时。我绝不会提倡删除 Resharper,因为它是可用的最佳生产力工具。因此,我要重申,如果您斥巨资购买了具有最新数量的可用内核和大量 RAM 的精美新系统,请花费数百美元/100 英镑购买新的 SSD。你不会后悔的。

另外,请查看 Scott Guthrie 关于此事的博客 http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx 具体来说,我引用:“...在必要时权衡购买额外的 CPU 处理器速度,转而投资更快的磁盘”。如果有人知道的话,你会期望 Visual Studio 开发团队的负责人知道。

Forget CPU. The single biggest performance boost you can give your machine is a Solid State drive. Compilation and background processes such as Resharper and Intellisense are so IO intensive that the main bottleneck with visual studio is IO. I have never seen VS max out the CPU, regardless of whether I had single, dual quad or 8 cores as I do now.

Update
Thanks for your comment @Erx... I am no expert about the exact processes that are going on. However, if you think about how many reads the compiler makes just to compile a project, you won't be surprised by the IO hit. Visual Studio may hold files in memory, but have you noticed that when you build a project and you have unsaved changes, the files are saved first before the build kicks off? This tells me that the msbuild compiler is accessing the saved files and that it doesn't use the in-memory files. If you have closed a file in VS, there is no guarantee that the file is still in memory as it might have been cleaned up by VS's memory management. So it makes sense that the compiler gets a clean copy. This can be many hundreds or thousands of files. Then there is the writing of compiled output, NuGet package reads, ConfigGen scripts (http://configgen.codeplex.com/). You get the picture.

Also, I have read somewhere that Intellisense does a lot of reading and writing to the file system, so that is going to be an added hit on performance if you have a slow HDD.

Plugins such as Resharper also hit the file system, particularly with background compilation. I would never advocate removing Resharper as it is the best productivity tool available. So I will reiterate, if you have splashed out on a fancy new system with the latest number of available cores and huge ammounts of RAM, spend a couple of hundred dollars / £100 on a new SSD. You won't regret it.

Also, Check out Scott Guthrie's bog on the matter http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx Specifically, I quote: "...where necessary trade off purchasing additional CPU processor speed in favor of investing in a faster disk instead". If anybody should know you would expect the head of the Visual Studio Development Team to know.

江挽川 2024-08-20 05:33:38

需要考虑的事情是您在开发环境中使用虚拟化。无论 Visual Studio 是否使用,虚拟化肯定会使用多个内核。我有多个开发环境,每个环境都有自己的虚拟机。

On thing to consider would be your use of virtualization in your development environment. virtualization definitely makes use of multiple cores whether or not Visual Studio does. I have multiple development environments each with its own VM.

看春风乍起 2024-08-20 05:33:38

该问题已被编辑以提及 VS2012,但大多数答案可以追溯到发布之前。 VS2012 引入了并行构建作为标准功能。因此,有更好的机会在功能强大的 CPU 上轻松利用更多内核。然而,如前所述,如果您希望缩短编译时间,则快速硬盘驱动器至关重要,最好是高端 SSD。

关于硬盘驱动器还是 CPU 是否是更好的投资存在一些争论,但改进其中任何一个都会产生很大的影响。在大多数市场中,开发人员的时间成本远远超过硬件成本,因此通常您最好购买最好的 CPU 和硬盘驱动器。唯一需要考虑的因素是最高端的收益递减规律。

引用关于 VS2012 上并行构建的文章:

Visual Studio 2010 包含一个“最大并行数”选项
项目构建。”虽然没有任何限制的迹象,
此 IDE 选项仅适用于 C++ 项目。幸运的是,这
限制不再适用于 Visual Studio 11。相反,现在有
还完全支持其他语言的并行构建。查看
为此,请同时运行 Process Explorer 的副本,并使用以下解决方案
许多项目正在建设中。你会看到多个 MSBuild
创建实例——与“最大数量”中指定的数量一样多
并行项目构建。”

The question has been edited to mention VS2012, but most of answers date back to before that was released. VS2012 introduced parallel builds as a standard feature. So, there is better opportunity to easily utilize more cores on a capable CPU. However as previously mentioned, if you want short compile times a fast hard drive is essential, preferably a high end SSD.

There is some debate regarding whether the hard drive or the CPU is the better investment, but improving either should have a big impact. In most markets the cost of developer time far outweighs hardware costs so usually you are best off buying the best CPU and hard drive you can. The only thing to factor in is the law of diminishing returns at they very top end.

Quote from the article regarding parallel builds on VS2012:

Visual Studio 2010 included an option for "maximum number of parallel
project builds." Although there was no indication of any restriction,
this IDE option only worked for C++ projects. Fortunately, this
restriction no longer applies to Visual Studio 11. Rather, there's now
full support for parallel builds in other languages as well. To view
this, run a copy of Process Explorer at the same time a solution with
numerous projects is building. You'll see that multiple MSBuild
instances are created -- as many as specified in the "maximum number
of parallel project builds."

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文