相关疑难解决方法(0)

我知道之前有人问这样的类似问题,但是有太多相互矛盾的信息,我真的想尝试一劳永逸地清理它.我将通过明确区分指令集架构(ISA)和实际硬件实现来尝试这样做.首先我尝试澄清:

1.)目前有intel64和amd64 CPU(除其他外,但这些都是重点)

2.)鉴于ISA是一个或多个CPU指令的二进制表示,这意味着ISA与其实际硬件实现完全分离.

我的问题:

intel 64和amd64 CPU之间的区别是否与不同的或扩展的x86-64 ISA有关？或者x86-64 ISA的不同硬件实现？或两者？

以下代码在调试模式下工作正常,因为如果没有设置Bit,_BitScanReverse64被定义为返回0.引用MSDN :(返回值为)"如果设置了索引则为非零,如果未找到设置位,则为0."

如果我在发布模式下编译此代码它仍然有效,但如果我启用编译器优化,例如\ O1或\ O2,则索引不为零且assert()失败.

#include <iostream>
#include <cassert>

using namespace std;

int main()
{
  unsigned long index = 0;
  _BitScanReverse64(&index, 0x0ull);

  cout << index << endl;

  assert(index == 0);

  return 0;
}

这是预期的行为吗？我正在使用Visual Studio Community 2015,版本14.0.25431.01更新3.(我离开了cout,因此在优化期间不会删除变量索引).还有一个有效的解决方法或我不应该直接使用此编译器内在？

我正在尝试计算大量uint64的位奇偶校验.比特奇偶校验是指接受uint64的函数,如果设置的比特数是偶数则输出0,否则为1.

目前我正在使用以下功能(@Troyseph,在这里找到):

uint parity64(uint64 n){
  n ^= n >> 1;
  n ^= n >> 2;
  n = (n & 0x1111111111111111) * 0x1111111111111111;
  return (n >> 60) & 1;
}

相同的SO页面具有以下汇编例程(由@papadp提供):

.code

; bool CheckParity(size_t Result)
    CheckParity PROC
    mov     rax, 0
    add     rcx, 0
    jnp     jmp_over
    mov     rax, 1
jmp_over:
    ret
CheckParity ENDP

END

它利用了机器的奇偶校验标志.但我不能让它与我的C程序一起工作(我知道旁边没有汇编).

问题.如何在C源文件中包含上面(或类似)代码作为内联汇编,以便该parity64()函数运行该代码？

(我在Intel Xeon Haswell上使用GCC和64位Ubuntu 14)

如果它有任何帮助,则parity64()在以下例程中调用该函数:

uint bindot(uint64* a, uint64* b, uint64 entries){
    uint parity …

在优化内循环的过程中,我遇到了奇怪的性能行为,我无法理解和纠正.

代码的精简版本如下; 粗略地说,有一个巨大的数组被分成16个字块,我简单地将每个块中字的前导零的数量加起来.(实际上我正在使用Dan Luu的popcnt代码,但是在这里我选择了一个具有类似性能特征的简单指令,用于"简洁".Dan Luu的代码基于这个SO问题的答案,虽然它具有诱人的类似奇怪的结果,似乎没有在这里回答我的问题.)

// -*- compile-command: "gcc -O3 -march=native -Wall -Wextra -std=c99 -o clz-timing clz-timing.c" -*-
#include <stdint.h>
#include <time.h>
#include <stdlib.h>
#include <stdio.h>

#define ARRAY_LEN 16

// Return the sum of the leading zeros of each element of the ARRAY_LEN
// words starting at u.
static inline uint64_t clz_array(const uint64_t u[ARRAY_LEN]) {
    uint64_t c0 = 0;
    for (int i = 0; i < ARRAY_LEN; ++i) {
        uint64_t t0;
        __asm__ ("lzcnt %1, …

可以安全地假设 x64 构建可以使用TZCNT而无需通过 cpu 标志检查其支持吗？

大多数编译器不优化内联汇编代码(VS2015,gcc),它允许我们编写它不支持的新指令.

但什么时候C/C++编译器应该实现内联汇编优化？