reduceSum记录

最新推荐文章于 2024-04-02 00:01:06 发布
最新推荐文章于 2024-04-02 00:01:06 发布
阅读量714 收藏 17
点赞数 7
文章标签： c++ 算法
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ostecdududu/article/details/126265882
版权

reduceSum 算子实现版本记录总结

第一版

__global__ void reduceSum(float *input, float *result, const int size) {
  int x = blockIdx.x * blockDim.x + threadIdx.x;
  if (x >= size) {
    return;
  }

  int len = blockDim.x / 2;
  while (len > 0) {
    if (threadIdx.x < len) {
      input[x] += input[x + len];
    }

    len /= 2;
    __syncthreads();
  }

  if (threadIdx.x == 0) {
    result[blockIdx.x] = input[blockIdx.x];
  }
}

主要思想是在一个block内每次规约启动左边一半的线程，每一个线程完成当前规模的一次原地规约，随后规模减半，直到为一，此时
该块的规约结果就放在线程0管理的地址处。

这个kernel没有线程束分化的问题，因为每次激活一半的线程，同一个线程束内的线程要么同时启动，要么不参与运算，不存在一部分
线程选择A分支，另一部分线程选择B分支的情况。

第二版

__global__ void reduceSumSharedMemory(float *input, float *result,
                                      const int size) {
  extern __shared__ float tempArray[];
  int x = blockIdx.x * blockDim.x + threadIdx.x;
  if (x >= size) {
    return;
  }

  // prepare data
  tempArray[threadIdx.x] = input[x];
  __syncthreads();

  int len = blockDim.x / 2;
  while (len > 0) {
    if (threadIdx.x < len) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + len];
    }

    len /= 2;
    __syncthreads();
  }

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
  __syncthreads();
}

主要思想是由于全局内存的存取效率相对低于对共享内存的存取，所以第一步可以先将数据从全局内存读取到共享内存中，随后在共享内存中
进行规约。

主要结果如下：

dataseize1031024*1024
Durationusecond744.58
SOL DRAM%26.22
SOL L1/TEX Cache%94.54
SOL L2 Cache%9.81
SM [%]%75.04

相比于第一版并没有时间上的进步，但是提高了L1 Cache的利用率，主要原因在于算子的计算密度并不高，主要限制在于内存带宽的利用率。虽然
在共享内存中规约肯定会比从全局内存中规约要快，但是算子把数据从全局内存读取到共享内存这一步效率并不高，即使能够很快的完成共享内存
规约，也会因为等待数据时间过长导致没有任何进步。

第三版

__global__ void reduceSumTwoLoads(float *input, float *result, const int size) {
  extern __shared__ float tempArray[];

  int x = blockIdx.x * blockDim.x * 2 + threadIdx.x;
  if (x >= size) {
    return;
  }

  // prepare data
  tempArray[threadIdx.x] = input[x] + input[x + blockDim.x];
  __syncthreads();

  int len = blockDim.x / 2;
  while (len > 0) {
    if (threadIdx.x < len) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + len];
    }

    len /= 2;
    __syncthreads();
  }

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这个kernel的主要改进点在于，kernel执行的时候每次规约都用一半的线程不活跃，造成线程资源的浪费，因此，在上一步的基础上每次读取两个数据，并进行规约
结果如下：

dataseize1031024*1024
Durationusecond372.22
SOL DRAM%52.08
SOL L1/TEX Cache%91.3
SOL L2 Cache%19.09
SM [%]%73.88

相比于上一个kernel，这次的改进导致时间接近减半，内存利用率翻倍。最初改进的理由是避免线程的浪费，从SM利用率上看的确实现了这一目标，但是kernel的性能
改进主要得益于内存带宽的利用率提高。同一个线程每次读取的数据增加了，全局层面上会有更多的访存被合并，提高了数据读取到共享内存的效率，减少了数据等待的时间
自然提高了性能。

第四版

__device__ void wrapReduce(volatile float *input, int id) {
  input[id] += input[id + 32];
  input[id] += input[id + 16];
  input[id] += input[id + 8];
  input[id] += input[id + 4];
  input[id] += input[id + 2];
  input[id] += input[id + 1];
}
__global__ void reduceSumUnrollLastWrap(float *input, float *result, int size) {
  extern __shared__ float tempArray[];

  int x = blockIdx.x * blockDim.x * 2 + threadIdx.x;
  if (x >= size) {
    return;
  }

  // prepare data
  tempArray[threadIdx.x] = input[x] + input[x + blockDim.x];
  __syncthreads();

  int len = blockDim.x / 2;
  while (len > 32) {
    if (threadIdx.x < len) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + len];
    }

    len /= 2;
    __syncthreads();
  }

  // last wrap
  if (threadIdx.x < 32) {
    wrapReduce(tempArray, threadIdx.x);
  }

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这一版的改进出发点在于，当规约规模小于32时只需要一个线程束就能实现所有的功能，而GPU上线程的基本调度单位是线程束，在同一个线程束内
的所有线程使用SIMD的方式同步执行。因此，当规模小于等于32时对循环进行展开，直接在一个束内进行求解，这样的好处是避免了所有线程在规模
小于等于32时执行无效的for循环和if判断指令，提高了线程的利用效率。

结果如下：

dataseize1031024*1024
Durationusecond247.52
SOL DRAM%78.40
SOL L1/TEX Cache%59.03
SOL L2 Cache%28.79
SM [%]%52.44

从结果看，随着内存带宽利用率的提高，算子耗时进一步减少，主要原因在于通过展开最后一个线程束，减少了线程的无效指令执行时间，从而间接
增加了线程访存的时间。

第五版

template <int threadNumber>
__device__ void reduceOnSharedMempry(float *tempArray, int id) {
  // manually unroll max to 1024 threads

  if (threadNumber >= 1024) {
    if (threadIdx.x < 512) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + 512];
    }
    __syncthreads();
  }

  if (threadNumber >= 512) {
    if (threadIdx.x < 256) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + 256];
    }
    __syncthreads();
  }

  if (threadNumber >= 256) {
    if (threadIdx.x < 128) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + 128];
    }
    __syncthreads();
  }

  if (threadNumber >= 128) {
    if (threadIdx.x < 64) {
      tempArray[threadIdx.x] += tempArray[threadIdx.x + 64];
    }
    __syncthreads();
  }

  // last wrap
  if (threadIdx.x < 32) wrapReduce<128>(tempArray, threadIdx.x);
}

template <int threadNumber>
__global__ void reduceSumUnrollIterations(float *input, float *result) {
  __shared__ float tempArray[threadNumber];
  int x = blockIdx.x * blockDim.x * 2 + threadIdx.x;

  // prepare data
  tempArray[threadIdx.x] = input[x] + input[x + blockDim.x];
  __syncthreads();

  reduceOnSharedMempry<threadNumber>(tempArray, threadIdx.x);

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这一版的改进思路延续上一版的循环展开，既然最后一个束展开后可以减少for循环和if判断指令的消耗，那么在明确线程块大小的前提下也可以通过
循环展开减少循环指令和if指令的消耗。

结果如下：

dataseize1031024*1024
Durationusecond239.42
SOL DRAM%80.80
SOL L1/TEX Cache%60.81
SOL L2 Cache%29.63
SM [%]%54.01

和上一版只展开最后一个束相比，推理时间进一步减少，这种循环展开带来的性能提升主要是减少了不必要的指令执行，增加了访存指令的密度，间接
提高了访存时间和内存带宽利用率。

第六版

template <int threadNumber>
__global__ void reduceSumUnrollAndLoads4(float *input, float *result) {
  __shared__ float tempArray[threadNumber];
  int x = blockIdx.x * blockDim.x * 4 + threadIdx.x;

  // loads four elements into register
  float temp = input[x] + input[x + blockDim.x];
  float temp2 = input[x + blockDim.x * 2] + input[x + blockDim.x * 3];
  // write results into shared memory
  tempArray[threadIdx.x] = temp + temp2;
  __syncthreads();

  // reduce on shared memory
  reduceOnSharedMempry<threadNumber>(tempArray, threadIdx.x);

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这个kernel的优化思路延续第三版，既然同一个线程读取两个数据会提高内存带宽的利用率，那么增加更多的数据读取应该能进一步增带宽利用率，
这一版是一个线程块处理连续的四个数据块。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.78
SM Frequencycycle/nsecond1.36
Elapsed Cyclescycle319030
Memory [%]%88.28
SOL DRAM%88.28
Durationusecond234.05
SOL L1/TEX Cache%32.74
SOL L2 Cache%31.75
SM Active Cyclescycle315,965.44
SM [%]%29.06

这一版的内存利用率达到了88.28，推理时间相比于之前的版本也有了更多的进步，提升的主要原因就在于进一步地增加了可供调度的访存指令的数量，
增加了访存指令的密度，从而提高内存带宽的利用率。

第七版

template <int threadNumber>
__global__ void reduceSumUnrollAndLoads8(float *input, float *result) {
  __shared__ float tempArray[threadNumber];
  int x = blockIdx.x * blockDim.x * 8 + threadIdx.x;

  // loads four elements into register
  float temp = input[x] + input[x + blockDim.x];
  float temp2 = input[x + blockDim.x * 2] + input[x + blockDim.x * 3];
  float temp3 = input[x + blockDim.x * 4] + input[x + blockDim.x * 5];
  float temp4 = input[x + blockDim.x * 6] + input[x + blockDim.x * 7];
  // write results into shared memory
  tempArray[threadIdx.x] = temp + temp2 + temp3 + temp4;
  __syncthreads();

  // reduce on shared memory
  reduceOnSharedMempry<threadNumber>(tempArray, threadIdx.x);

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这个kernel的优化思路延续第六版，既然增加独立的访存指令能够提高内存带宽利用率，那么就可以继续增加，这个版本一个块需要处理原来8倍的block。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.79
SM Frequencycycle/nsecond1.36
Elapsed Cyclescycle317,563
Memory [%]%88.62
SOL DRAM%88.62
Durationusecond232.74
SOL L1/TEX Cache%21.31
SOL L2 Cache%47.55
SM Active Cyclescycle314,594.09
SM [%]%19.46

一次读取8个数据并进行规约进一步的提高了内存带宽的利用率，从而减少了推理时间，由于一个线程需要处理原来八倍的数据量，所需的block数量大大降低，
所以SM的利用率反而降低了

第八版

template <int threadNumber>
__global__ void reduceSumUnrollAndLoads16LinearAccessMemory(float *input,
                                                            float *result) {
  __shared__ float tempArray[threadNumber];
  int x = blockIdx.x * blockDim.x * 16 + threadIdx.x * 16;

  // loads 16 elements into register
  float temp = input[x] + input[x + 1];
  float temp2 = input[x + 2] + input[x + 3];
  float temp3 = input[x + 4] + input[x + 5];
  float temp4 = input[x + 6] + input[x + 7];
  float temp5 = input[x + 8] + input[x + 9];
  float temp6 = input[x + 10] + input[x + 11];
  float temp7 = input[x + 12] + input[x + 13];
  float temp8 = input[x + 14] + input[x + 15];

  // write results into shared memory
  tempArray[threadIdx.x] =
      temp + temp2 + temp3 + temp4 + temp5 + temp6 + temp7 + temp8;
  __syncthreads();

  // reduce on shared memory
  reduceOnSharedMempry<threadNumber>(tempArray, threadIdx.x);

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这一版尝试继续增加单个线程处理的数据量。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.80
SM Frequencycycle/nsecond1.37
Elapsed Cyclescycle523,348
Memory [%]%53.75
SOL DRAM%53.75
Durationusecond382.98
SOL L1/TEX Cache%97.92
SOL L2 Cache%19.16
SM Active Cyclescycle518,682.57
SM [%]%8.85

从结果看并没有达到理想的效果，一方面是因为这种通过增加单个线程负载的方式来提高内存带宽利用率已经接近极限了，在上一个版本中的
内存利用率提升已经很小了再增加负载效果有限。

性能衰退的原因可能是因为寄存器资源不足，导致单个线程不能按照设定的逻辑将数据存放
到寄存器中然后直接规约。实际上这一系列优化的主要思路就是通过给单个线程分配更多的寄存器资源和增加更多的内存访问实现对内存带宽
的利用率增加，这一方法的一个限制就在于SM上的寄存器资源，当资源不足时，寄存器就无法放置这么多全局内存数据，转而将数据存放在全局内存
导致性能下降。

第九版

template <int threadNumber>
__global__ void reduceSumUnrollAndLoads8LinearAccessMemory(float *input,
                                                           float *result) {
  __shared__ float tempArray[threadNumber];
  int x = blockIdx.x * blockDim.x * 8 + threadIdx.x * 8;

  // loads eight elements into register
  float temp = input[x] + input[x + 1];
  float temp2 = input[x + 2] + input[x + 3];
  float temp3 = input[x + 4] + input[x + 5];
  float temp4 = input[x + 6] + input[x + 7];
  // write results into shared memory
  tempArray[threadIdx.x] = temp + temp2 + temp3 + temp4;
  __syncthreads();

  // reduce on shared memory
  reduceOnSharedMempry<threadNumber>(tempArray, threadIdx.x);

  // write internal result back to global memory
  if (threadIdx.x == 0) {
    result[blockIdx.x] = tempArray[threadIdx.x];
  }
}

这一版在第七版的基础上进行优化，主要考虑是第七版读取八个全局内存数据的时候间隔很大，这样可能会造成分散的内存访问，降低内存带宽利用率。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.79
SM Frequencycycle/nsecond1.36
Elapsed Cyclescycle318,004
Memory [%]%88.48
SOL DRAM%88.48
Durationusecond232.12
SOL L1/TEX Cache%89.35
SOL L2 Cache%40.24
SM Active Cyclescycle314,906.72
SM [%]%19.14

和第七版相比，推理时间有一点进步，但是并不是和预想的那样的进步，主要原因在于，块内的合并内存访问极大的提高了L1 Cache的利用率，所以减少了
规约操作的时间，但是块内的合并内存访问并没有提高全局的内存合并访问，从结果上看甚至降低了内存利用率，全靠L1 Cache的提高平衡了一些性能。

第十版

template <int threadNumber>
__device__ void wrapReduceByShuffle(volatile float *input, int id) {
  if (threadNumber >= 64) input[id] += input[id + 32];

  // read data into thread register
  int sum = input[id];

  // Use XOR mode to perform butterfly reduction
  sum += __shfl_xor_sync(0xffffffff, sum, 16, 32);
  sum += __shfl_xor_sync(0xffffffff, sum, 8, 32);
  sum += __shfl_xor_sync(0xffffffff, sum, 4, 32);
  sum += __shfl_xor_sync(0xffffffff, sum, 2, 32);
  sum += __shfl_xor_sync(0xffffffff, sum, 1, 32);

  // write register value to shared memory
  if (id == 0) *input = sum;
}

这一版优化的出发点是，在展开最后一个束的时候，第四版是将数据从共享内存读入寄存器，规约完成后再写回全局内存，这就存在重复的数据读写和运算指令，
通过一次读数据后直接使用shuffle指令即可实现线程束内部的规约，减少重复的数据读写和运算指令消耗。

结果差不多，几乎没有区别。

分析原因，访问寄存器只需要一个周期，访问共享内存是1~20个周期，理论上寄存器应该更快，但是算子的主要瓶颈仍然在于全局内存访问效率，即使规约操作
变快了还是需要等待数据，因此这样的优化意义不大。另一方面，由于对共享内存的访问不存在bank conflict 的问题，本身访问共享内存的带宽就足够大，和
访问寄存器差异不大。

第十一版

__global__ void reduceSumByWrap(float *input, float *result) {
  __shared__ float tempArray[32];

  int wrapNum = blockDim.x / 32;
  int wrapId = threadIdx.x >> 5;
  int laneId = threadIdx.x & 31;
  volatile float *basePtr = input + wrapId * 32;

  // read data into registers and perform wrap reduce
  float value = *(basePtr + laneId);
  value += __shfl_xor_sync(0xffffffff, value, 16, 32);
  value += __shfl_xor_sync(0xffffffff, value, 8, 32);
  value += __shfl_xor_sync(0xffffffff, value, 4, 32);
  value += __shfl_xor_sync(0xffffffff, value, 2, 32);
  value += __shfl_xor_sync(0xffffffff, value, 1, 32);
  if (laneId == 0) {
    tempArray[wrapId] = value;
  }
  __syncthreads();

  // reduce on shared memory
  if (wrapId == 0) {
    if (laneId < wrapNum)
      value = tempArray[laneId];
    else
      value = 0;

    value += __shfl_xor_sync(0xffffffff, value, 16, 32);
    value += __shfl_xor_sync(0xffffffff, value, 8, 32);
    value += __shfl_xor_sync(0xffffffff, value, 4, 32);
    value += __shfl_xor_sync(0xffffffff, value, 2, 32);
    value += __shfl_xor_sync(0xffffffff, value, 1, 32);
  }
  if (laneId == 0) result[blockIdx.x] = value;
}

这一版的优化思路建立在对之前的kernel的数据流动分析基础上，以目前最好的第九版为例：数据首先从全局内存流向寄存器，然后从寄存器流向共享内存，这就是
第一步的数据导入；在接下来的基于共享内存的规约中，每进行一次规约活跃线程数量减半，造成线程资源的浪费。

为了解决这两个问题，可以使用基于束的规约方式：第一步中，每个线程束获取到全局内存数据后直接使用shuffle指令进行束内规约，然后将结果写入共享内存，这样即可
解决第一个问题；在基于共享内存的规约过程中，每个线程束处理32个数据，读入数据后进行束内规约，然后将结果写入共享内存。使用这样的规约方式既能够优化数据
流动，又可以优化线程资源使用。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.79
SM Frequencycycle/nsecond1.36
Elapsed Cyclescycle2,203,537
Memory [%]%14.70
SOL DRAM%0.00
Durationusecond1600
SOL L1/TEX Cache%15.76
SOL L2 Cache%5.09
SM Active Cyclescycle2,201,373.46
SM [%]%14.70

结果看来，这个kernel性能非常差，并没有达到预期效果。主要原因在于，当线程束读取全局内存数据的时候采用的是束内连续读取，这样的方式在微观上能够一次读取32个
数据，但是从全局上并不能导致合并的内存读取，因此内存的利用率十分低下。

第十二版

__global__ void reduceSumByWrapV2(float *input, float *result, size_t size) {
  __shared__ float tempArray[32];

  int wrapNum = blockDim.x / 32;
  int wrapId = threadIdx.x >> 5;
  int laneId = threadIdx.x & 31;

  float value = 0;
  for (int i = blockIdx.x * blockDim.x + threadIdx.x; i < size;
       i += blockDim.x * gridDim.x) {
    value += input[i];
  }

  // read data into registers and perform wrap reduce
  value += __shfl_xor_sync(0xffffffff, value, 16, 32);
  value += __shfl_xor_sync(0xffffffff, value, 8, 32);
  value += __shfl_xor_sync(0xffffffff, value, 4, 32);
  value += __shfl_xor_sync(0xffffffff, value, 2, 32);
  value += __shfl_xor_sync(0xffffffff, value, 1, 32);
  if (laneId == 0) {
    tempArray[wrapId] = value;
  }
  __syncthreads();

  // reduce on shared memory
  if (wrapId == 0) {
    if (laneId < wrapNum)
      value = tempArray[laneId];
    else
      value = 0;

    value += __shfl_xor_sync(0xffffffff, value, 16, 32);
    value += __shfl_xor_sync(0xffffffff, value, 8, 32);
    value += __shfl_xor_sync(0xffffffff, value, 4, 32);
    value += __shfl_xor_sync(0xffffffff, value, 2, 32);
    value += __shfl_xor_sync(0xffffffff, value, 1, 32);
  }
  if (laneId == 0) result[blockIdx.x] = value;
}

这版本参考了Nvidia 的博客，在上一个版本的基础上，使用grid-stride的方式读取全局内存而不是基于束的全局内存读取，其余操作不变。

结果如下：

dataseize3210241024
DRAM Frequencycycle/nsecond6.79
SM Frequencycycle/nsecond1.36
Elapsed Cyclescycle318,146
Memory [%]%88.46
SOL DRAM%88.46
Durationusecond232.12
SOL L1/TEX Cache%59.30
SOL L2 Cache%40.09
SM Active Cyclescycle315,140.16
SM [%]%19.43

从结果上看，使用了grid-stride方式读取全局内存后，改进的wrap-based kernel性能能够达到之前通过增加内存事务一样的效果。这个kernel的好处在于，
使用grid-stride方式读取全局内存使得kernel具有可扩展性，之前的方式需要指定thread的数量刚好匹配的处理的数据的数量，如果要处理多个数据就需要
改变kernel调用的方式。使用新的wrap-based, grid-stride读取方式的kernel能够使用相同的代码调用，不需要复杂的调用函数。

还没有想明白的问题

完全循环展开为什么128效果最好，256，512效果不好，

如何设定block和grid

block中线程的数量应该大于一个SM中最大线程数/最大block数，并且选择SM中最大线程数的约数。由于block是在SM上运行，grid中block的数量最好是SM个数
的倍数。

其它收获

在优化reduce算子的过程中纠正了一些错误的认知，比如”使用共享内存一定会更快“，”一个block内的线程访问连续的地址会提高全局内存访问效率“，更重要的
是在分析算子的时候能够从数据流动的方式分析算子的性能，通过分析数据的流动分析算子是否有冗余的数据搬运或者逻辑分支。

ostecdududu
关注
  • 7
    点赞
  • 踩
  • 17
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
reduce_sum()函数 Tensorflow
a1111h的博客
08-25 2526
reduce_sum() reduce_sum() 函数由reduce和sum两个单词组成函数名，从字面意思上讲是减少和求和的意思，这让人感到莫名其妙。 reduce_sum() 函数确实有减少和求和两层意思，但减少和求和的作用对象却不一样： reduce在函数中应该翻译成降维或者塌缩的意思，他的作用对象是求和对象的维度，而sum求和便是求指定维度的数据和。 下面我们举一个三维数组的例子 ...
TensorFlow的reduce_sum()函数
Sual
05-20 5万+
日期：2017.5.20导师让下周二之前用TensorFlow把MNIST跑通，今天看源码碰到这么一行，发现TensorFlow里面的求和函数和其他语言差别挺大，便记录下来。import tensorflow as tf...# 交叉熵评估代价 cross_entropy = tf.reduce_mean(-tf.reduce_sum(y_ * tf.log(y), reduction_indice
深度学习之常用算子介绍
最新发布
ueke1的博客
04-02 2257
打开 onnx 模型图，可以看到它是一个有向无环图。除了 Input、Output ，其他都是算子（是操作，而不是节点）在ONNX（Open Neural Network Exchange）模型中，除了输入和输出，其他都是算子（Operations）。算子是表示神经网络模型中的不同操作或层的元素。一个ONNX模型由一系列算子组成，通过连接这些算子来定义模型的计算流程。
tf.reduce_sum理解（小记）
热门推荐
arjick的专栏
11-01 9万+
reduce_sum应该理解为压缩求和，用于降维 # 'x' is [[1, 1, 1] #         [1, 1, 1]] #求和 tf.reduce_sum(x) ==> 6 #按列求和 tf.reduce_sum(x, 0) ==> [2, 2, 2] #按行求和 tf.reduce_sum(x, 1) ==> [3, 3] #按照行的维度求和 tf.r
TensorFlow基础1：reduce_sum()函数和reduce_mean()函数
闪电小飞侠
11-15 2万+
TensorFlow之reduce_sum()函数和reduce_mean()函数
reduce_sum和reduce_mean函数
Dzwfvz的博客
08-08 1173
reduce_sum和reduce_mean函数 https://blog.csdn.net/Vipbinn/article/details/82978003 https://www.cnblogs.com/rossoneri/p/8029940.html https://blog.csdn.net/chengshuhao1991/article/details/78545723 一...
对tf.reduce_sum tensorflow维度上的操作详解
09-20
在TensorFlow库中，`tf.reduce_sum`是一个非常重要的函数，它用于计算张量（tensor）在指定维度上的和。这个函数在处理机器学习模型时，尤其是在计算损失、归一化或者聚合数据时非常常见。下面我们将深入探讨`tf....
MapperReduce
04-01
MR案例资料提取码.txt，这个文件中的提取码可在百度网盘中提取MR案例资料
yls.zip_reduce
09-24
reduce(first, second) 初始条件：有理数first和有理数second存在。 操作结果：返回有理数first减去second的结果。 multiplus(first, second) 初始条件：有理数first和有理数second存在。 操作结果：返回...
解析JavaScript数组方法reduce
10-20
let sum = [0, 1, 2, 3, 4].reduce((x, y) => x + y, 0); // 10 ``` 在这个例子中，`reduce`将数组的所有数字相加，初始值为0。 2. **扁平化二维数组：** ```javascript let arr = [[1, 2], [3, 4], [5, 6]]....
tf.sign和tf.reduce_sum
Deep Learning and NLP Farm
04-30 1万+
tensorflow中两个经常用到的操作，理解的不是很透彻，故在此做标记： 关于reduce_sum的维度问题也容易让人迷惑，特找来好用的图示，一看即懂： 为了加深影响，给出简单code import numpy as np import tensorflow as tf inputs = [[1,0,2],[3,2,4]] inputs = np.array(inputs) A = t
tf.reduce_sum用法
qq_36201400的博客
09-28 1012
计算张量维度上的元素之和。 沿给定的“轴”减小“ input_tensor”。 除非“ keepdims”为真，否则对于“轴”中的每个条目，张量的秩都会降低1。 如果`keepdims`为true，则减小的维度保留为长度1。 如果`axis`为None，则缩小所有维度，并返回带有单个元素的张量。 def reduce_sum_v1(input_tensor, axis=None, keepdims=None, .
Tensorflow学习笔记——reduce_sum函数
陈正经
08-05 1537
以上是reduce_sum函数的定义 reduce_sum( input_tensor, axis=None, keep_dims=False, name=None, reduction_indices=None ) 说明： reduce_sum() 就是求和，由于求和的对象是tensor，所以是沿着tensor的某些维度求和。函数名中加了reduce...
ReduceSum算子性能问题
weixin_45666880的博客
11-09 227
***************************************************解答*****************************************************可参照一下这里，有性能分析，可以自检一下自己的模型：https://www.mindspore.cn/mindinsight/docs/zh-CN/r1.8/performance_profiling.html。具体到代码而言，在损失函数中，使用到了几次该算子。我根据API映射将该算子迁移过来。
3.5.2 reduce_sum、reduce_mean、reduce_max、reducemin函数详解
baochunlei1的博客
01-08 1780
自己开发了一个股票智能分析软件，功能很强大，需要的点击下面的链接获取： https://www.cnblogs.com/bclshuai/p/11380657.html 1.1.1 reduce_sum、reduce_mean、reduce_max、reducemin函数介绍 reduce_sum函数是用来求多维tensor的元素之和的方法，reduce是降维的意思，sum是求和的意思。其定义如下： reduce_sum(input_tensor, axis=None, keepd...
tf.reduce_sum 用法
崔伟灿的博客
11-16 1004
tf.reduce_sum 的功能描述原文为： """Computes the sum of elements across dimensions of a tensor. Reduces `input_tensor` along the dimensions given in `axis`. Unless `keepdims` is true, the rank of the t...
tf.reduce_sum()用法介绍
sunmingyang1987的博客
12-19 2万+
方法定义： tf.reduce_sum( input_tensor, axis=None, keepdims=None, name=None) tf.reduce_sum()作用是按一定方式计算张量中元素之和 input_tensor为待处理张量； axis指定按哪个维度进行加和，默认将所有元素进行加和； keepdims默认为False，表示不维持原来张量的维度，反之维持原张量维度； name用于定义该操作名字。 示例： 有如下张量，形状为(2,3,4)的三维张量：
python的reduce, sum的使用
风不吹雨下的专栏
04-19 2477
reduce(function, sequence[, initial]) -> value function为两个参数的函数，进行对 sequence的累计操作， 如 reduce(lambda x, y : x + y, [1,2,3,4,5]) 结果为 ((((1+2)+3)+4)+5) = 15 如果 initial 有指定的话，它相当于在sequence是追加一个数据。或者当 s
tf.reduce_sum详解（附代码实例）
lllxxq141592654的博客
05-20 701
官方文档：https://www.tensorflow.org/api_docs/python/tf/math/reduce_sum tf.math.reduce_sum( input_tensor, axis=None, keepdims=None, name=None, reduction_indices=None, # 废除 keep_dim...
8.现有一网站记录了每一个广告被点击情况，记录的数据格式包括时间戳、用户、广告三个字段（字段之间使用空格分割）。 数据样本如下： 1516609143867 64 16 1516609143869 75 18 1516609143869 87 12 现因业务应用需要，需要统计出每一个广告被点击次数。请结合MapReduce编程模型给出设计思路和核心代码（给出map函数和reduce函数的核心代码即可）。
06-12
设计思路： 1. Map阶段：将每一条记录的广告ID作为key，出现一次计数为1作为value，发往Reduce节点。 2. Reduce阶段：对每个广告ID的value做累加操作，得到该广告被点击的总次数。 Map函数核心代码： ``` public void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields = value.toString().split(" "); String adId = fields[2]; context.write(new Text(adId), new IntWritable(1)); } ``` Reduce函数核心代码： ``` public void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException { int sum = 0; for (IntWritable value : values) { sum += value.get(); } context.write(key, new IntWritable(sum)); } ```

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值