blocks|key|362778|text|不，这不是典型的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362779|64位整数算法的使用不是典型的(!)应用性能的测量。如果这确实占了应用程序时间的很大一部分(否则它完全不相关)，那么您有一个处理数据加密/解密的应用程序，我认为您会同意这不是每个定义的典型应用程序。|362780|362781|·是的，任何做大量整数运算的事情都要快得多|blockquote|362782|362783|362784|不是的。任何对其CPU使用的很大一部分执行整数运算(这可能与启动许多CPU不同)都可能增加。这基本上限制了一些副作用应用程序的影响。例如，Web应用程序将不执行SHA加密-+SSL将由内核处理。|362785|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Q|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|T|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|M|$]]

No, it is not typical.

The usage of 64-bit integer arithmetic is not a typical (!) measurement of application performance. If that does make up a significant portion of your application time (otherwise it is totally irrelevant), you have an application that deals with encryption / decryption of data, and I think you will agree this is not a typical application per definition.

<blockquote>
 •yes, anything doing lots of integer arithmetic will be much faster
</blockquote>

No. Anything doing integer maths for a significant portion of its CPU usage (which may be different from doing many of them to start) may increase. This basically limits the impact to quite a few side effect applications. Web applications, for example, would not do SHA encryption - SSL would be handled by the kernel.

blocks|key|2481803|text|当使用在64位CPU寄存器上操作的机器代码指令时，涉及long和ulong的操作肯定会快一倍。在32位模式下，这些操作被“模拟”为两个(或更多)单独的指令，这也是在32位模式下读写64位值不是原子的原因。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2481804|也就是说，大多数计算繁重的任务可能仍然使用32位值(int和uint)或更小的值。那些没有速度上的差别。|2481805|entityMap^0|R|4|W|5|0|Q|3|U|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

Operations involving <code>long</code> and <code>ulong</code> will certainly be almost twice as fast when using machine code instructions that operate on 64-bit CPU registers. In 32-bit mode, these operations are “emulated” as two (or more) separate instructions, which is also why reading and writing a 64-bit value is not atomic in 32-bit mode.

That said, the majority of computationally-heavy tasks probably still use 32-bit values (<code>int</code> and <code>uint</code>) or smaller. There is no speed difference for those.

blocks|key|342082|text|首先，很高兴你能分享测试结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342083|答:视情况而定。|342084|64位是一个不同于32位的lot，这是一个完整的单独的讨论。你之所以不能从那些知道他们在说什么的人那里得到一个明确的答案，是因为有些事情更快，而另一些事情更慢。但是，一些应用程序和某些算法显然从中受益。|offset|length|style|BOLD|342085|64位可以处理更多的数据，在当时移动更大的数据块，有更多的寄存器，使共享库更快等等。但是它也改变了中断工作的方式(Iirc)，有更多的指令(尽管一些旧的被删除)，对于较小的数据块，堆栈和指针占用更多的空间等等。|342086|如果你对CPU的能力有很高的要求，那么企业购买一个更强大的CPU通常比在这样的水平上调整程序更便宜。可悲！但是要确定某一种算法在任何一个平台上的效率，必须对其进行测试。|342087|在机器代码中，您添加的每个堆栈项占用内存的两倍，因此在L1、L2和内存之间移动的数据量是原来的两倍。但是，对于每次计算和内存读/写，您可以处理更多的数据一次(更高的吞吐量对大量的数据)。这取决于你传递了多少数据，你在做什么算术运算。然后考虑到速度的增加/损失比操作系统只移动4k页，并且每个指针所占的高值L1和L2缓存的两倍.%2B所有我不记得的事。|342088|我的观点是，这个问题很快就变得复杂起来，答案将非常具体。|342089|我想说的是，强制.Net应用程序使用32位的唯一原因是它引用了32位库。在执行代码之前，它无法确定此依赖项，因此会导致异常。|342090|entityMap^0|0|0|D|3|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@$F|Y|G|Z|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

First of all, great that you share the test results.

Answer: It depends.

64-bit is a lot different from 32-bit, and this is a whole separate discussion. The reason why you can't get a clear answer from anyone who knows what they are talking about is that some things are faster and other things slower. But some applications and certain algorithms clearly do benefit from it.

64-bit can address more, moves bigger chunks of data at the time, has more registers, makes shared libraries faster, etc. But it also changes how interrupts work(iirc), has more instructions (though some old are removed), is less efficient on smaller chunks of data, stack and pointers takes up more space, etc.

If you have a high demands on CPU power then it is usually cheaper for a business to buy a stronger CPU than to tune the program on such levels... Sadly! But to determine the efficiency of a certain algorithm on either platform you must test it. 

In the machine code every stack item you add takes twice the memory, so twice the amount of data is being moved between L1, L2 and memory. But for every compute and memory read/write you can process more data per pass (higher throughput on large amounts of data). So it depends on how much data you are passing and how much and what kind of arithmics you are doing. Then consider that speed gain/loss compared to the OS only moving 4k pages, and that every pointer stored takes up twice as much of the highly valuabe L1 and L2 cache... + everything I can't remember.

My point is that the question quickly becomes complex and the answer will be very specific to the question.

I'd say the only reason to force a .Net application to 32-bit is if it references 32-bit libraries. It is unable to determine this dependency until the code is executed so it leads to an exception.

blocks|key|342123|text|如前所述，答案很复杂，在很大程度上取决于你在做什么。相关问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342124|342125|What+are+the+actual+performance+differences+between+Int64+and+Int32+on+32+and+64+bit+MS+Windows?|unordered-list-item|offset|length|342126|.NET+2.0+application+('Any+CPU')+running+slow+on+64-bit+OS/processoer+|342127|Differences+between+32+and+64-bit+.NET+(4)+applications|342128|What+is+the+difference+between+a+32-bit+and+64-bit+processor?|342129|What+are+the+differences+between+.NET+in+32+or+64+bit+systems?|342130|342131|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/281590|1|https://stackoverflow.com/questions/1525976|2|https://stackoverflow.com/questions/3540699|3|https://stackoverflow.com/questions/4552905|4|https://stackoverflow.com/questions/1095493^0|0|0|0|2O|0|0|0|1Y|1|0|0|1J|2|0|0|1P|3|0|0|1Q|4|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|18|8|@]|9|@$F|19|G|1A|1|1B]]|A|$]]|$1|H|3|I|5|E|7|1C|8|@]|9|@$F|1D|G|1E|1|1F]]|A|$]]|$1|J|3|K|5|E|7|1G|8|@]|9|@$F|1H|G|1I|1|1J]]|A|$]]|$1|L|3|M|5|E|7|1K|8|@]|9|@$F|1L|G|1M|1|1N]]|A|$]]|$1|N|3|O|5|E|7|1O|8|@]|9|@$F|1P|G|1Q|1|1R]]|A|$]]|$1|P|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]|Y|$5|T|U|V|A|$W|Z]]|10|$5|T|U|V|A|$W|11]]|12|$5|T|U|V|A|$W|13]]|14|$5|T|U|V|A|$W|15]]]]

As mentioned the answer is complex and depends highly on what you are doing. Related questions:

<ul>
<li><a href="https://stackoverflow.com/questions/281590">What are the actual performance differences between Int64 and Int32 on 32 and 64 bit MS Windows?</a></li>
<li><a href="https://stackoverflow.com/questions/1525976">.NET 2.0 application (&#39;Any CPU&#39;) running slow on 64-bit OS/processoer </a></li>
<li><a href="https://stackoverflow.com/questions/3540699">Differences between 32 and 64-bit .NET (4) applications</a></li>
<li><a href="https://stackoverflow.com/questions/4552905">What is the difference between a 32-bit and 64-bit processor?</a></li>
<li><a href="https://stackoverflow.com/questions/1095493">What are the differences between .NET in 32 or 64 bit systems?</a></li>
</ul>

It has been said it's OK for a .NET application to be compiled in x86 mode because pretty much the only benefit x64 gives is a larger virtual address space, thus allowing the application to allocate more than 2 (or 3) GB of memory, or memory-map very large files in their entirety.

However, a very simple test indicates that on a 64-bit machine, SHA256Managed hashes a 10&nbsp;MB byte array almost twice as slowly if the application is x86 than if it is x64. So, any application that does a lot of SHA256 hashing benefits rather significantly from being "Any CPU" or having separate builds for the two platforms.

My question is: is this a typical result for .NET? Do other computationally-heavy tasks benefit similarly from running in 64-bit mode on a 64-bit OS? Of course, I could just test every specific computation, but I'd appreciate an overall "rule of thumb", such as:

<ul>
<li>yes, anything doing lots of integer arithmetic will be much faster</li>
<li>yes, all numeric computations are much faster (incl. doubles/decimals)</li>
<li>no, this is a rare exception and most algorithms run at roughly the same speed in both modes</li>
</ul>

SHA256Managed twice as fast in x64 builds - is this typical?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有人说，.NET应用程序可以在x86模式下编译，因为x64提供的唯一好处是有更大的虚拟地址空间，从而允许应用程序分配超过2(或3) GB的内存或内存--映射非常大的文件。然而，一个非常简单的测试表明，在64位计算机上，如果应用程序是SHA256Managed，则x86哈希10 MB字节数组的速度几乎是x64的两倍。因此...

问SHA256Managed在x64构建中的速度是以前的两倍--这是典型的吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SHA256Managed在x64构建中的速度是以前的两倍--这是典型的吗？EN