为什么VMREAD/VMWRITE比内存读/写操作慢
从逻辑上讲，写入任何CPU存储变量应该比相应的内存操作快，因为没有缓存未命中的机会。这些状态缓存在 CPU 中，并且在下一次虚拟机启动/虚拟机恢复操作之前不会更改任何 CPU 状态。因此，它们应该比对内存地址的等效操作更快
当查看AMD和英特尔提供的不同虚拟化解决方案时，就会出现这个问题。英特尔要求对VMCS数据结构的所有更改都应始终通过VMREAD/VMWRITE接口，而不是通过常规内存R/W操作。然而，AMD不构成任何此类限制，其VMCB区域由常规内存操作修改。
Intel方法的收益应该比AMD更快的VMExit/VMResume时间。然而，英特尔会通过添加新指令来降低灵活性。
然而，实际上，VMREAD/VMWRITE操作比常规内存操作慢。这对我来说毫无意义。
共有1个答案
常规内存读/写由专用硬件处理，以优化它们，因为真实的程序中充满了它们。
大多数工作负载不会花费太多时间来修改特殊的 CPU 控制寄存器，因此这些指令的内部处理通常不会得到很好的优化。在内部，它可以是微编码的（即从微码ROM解码为许多uops）。
段寄存器可能不是一个很好的类比，因为写入一个寄存器会触发CPU从GDT/LDT加载描述符。但根据Agner-Fog对Nehalem的测试，mov-sr、r每13个周期有一个吞吐量，解码为6 uops（从微码）。（他不再为以后的CPU测试段寄存器。）实际上，我不确定这是16位还是32位模式。如果是16位实模式，则写入段寄存器不会读取描述符；它只是更新了基础和限制。
读取段寄存器更快：每个时钟一个。但这仍然比读取普通寄存器慢（常规mov指令在Nehalem上的吞吐量为0.33c）。
Nehalem每个时钟只能加载和/或存储一次，而Sandybridge系列每个时钟可以加载2次。但段寄存器读取可能不会更快。
从控制寄存器移入/移出可能会更慢，因为它比段寄存器更罕见。
-
假设我在一个大型数据集上迭代，根据用户提供的变量，我要么区分大小写，要么不区分大小写。我认为，因为这个用户提供的值永远不会改变，所以将它放入一个寄存器是一个好主意，例如: 这是编译器输出的一个示例——https://godbolt.org/z/7KrGzr.似乎与前缀在寄存器中进行了比较，以查看它是否为0： 如果没有它，它与内存地址进行比较： 然而，当我在本地运行它时，没有的版本要快得多： 该功能
-
我有一个动作，生成一个密码重置链接，并电子邮件给用户 是什么导致web服务器决定内容不变并返回HTTP 304？ 我知道有个办法 https://stackoverflow.com/a/18620970/141172 注意：我在上面将localhost更改为local，因为StackOverflow不允许发布包含localhost的链接：-） 浏览器是Internet Explorer10。
-
内存操作 函数 void * rt_memset (void *s, int c, rt_ubase_t count) 设置内存数据 void * rt_memcpy (void *dst, const void *src, rt_ubase_t count) 复制内存数据 void * rt_memmove (void *dest, const void *src, rt_
-
据我所知，synchronized关键字将本地线程缓存与主存同步。volatile关键字基本上总是在每次访问时从主存中读取变量。当然，访问主存比本地线程缓存要昂贵得多，因此这些操作也很昂贵。然而，CAS操作使用低级硬件操作，但仍然必须访问主存。那么CAS操作如何更快呢？
-
主要内容：to_excel(),read_excel()Excel 是由微软公司开发的办公软件之一，它在日常工作中得到了广泛的应用。在数据量较少的情况下，Excel 对于数据的处理、分析、可视化有其独特的优势，因此可以显著提升您的工作效率。但是，当数据量非常大时，Excel 的劣势就暴露出来了，比如，操作重复、数据分析难等问题。Pandas 提供了操作 Excel 文件的函数，可以很方便地处理 Excel 表格。 to_excel() 通过 to_ex
-
问题内容： 我了解Scanner的优点，以及何时使用Scanner和BufferedReader。我读了一个不同的问题，但在一些类似的问题中，它的问题是Scannervs. BufferedReader 当我从输入中读取内容时，为什么Scanner这么慢？ 我认为这与Scanner中有一个小的缓冲区有关，但是在这里我迷路了。最初的问题来自 Codechef，但我对该解决方案不感兴趣。 这是具有给定