彭于斌
可以了 ```cpp #include #include #include #include #include #include template static void memcpy_streamed(char *dst, char const *src, char const *nextSrc, size_t size) { const size_t width = 64; /* auto chDst...
不并行： ``` 100%|████████████| 1000/1000 [00:02
哦还有你这个是不是knn之类的，START_X是任意数的，如果你能保证START_X都是64的整数倍，可以把src数组block化，这样就完全没有跳跃访问了。
> 原来 std::memcpy 也是可以被优化的吗？ memcpy 只有在数据量大于 4096 时才会尝试用 stream 指令，否则依然会使用 store 指令。而你这里都是一小段一小段分别 memcpy，他是不知道你是一个大数据量拷贝的。
> 我的所有操作都是内存 I/O 密集的任务。没有计算。我记得小彭老师介绍cuda编程的时候说过N卡的显存速度快与主存。我输出的数据最后也要搬到显存上做深度学习，那我是不是可以直接在cuda上做切片。。。小彭老师能预估一下这个性能提升大概有多大？ 显存确实比内存快，但是从内存到显存，却比两者都慢！因为需要经过 PCIe 总线。 如果说：CPU=湖泊，PCIe=河流，GPU=大海。 你的问题就变成：我有很多货物，但是有很大一部分是要扔掉的。是提前在湖泊里挑选出需要的货物留下，在运河里开精简的货物，还是先把所有的货物一次性运到大海里再进行挑选。显然河流是瓶颈，在湖泊里提前挑选好可以尽可能降低河流的负担。 设显存到显存的时间成本为1，内存到内存的时间成本为2，内存到显存的时间成本为3。 所以如果你是一次性切片的话，那么两种方案的速度比较如下： - 在 CPU 上切片好后拷给 GPU 计算：2*64 + 3*64 + 1*64 - CPU 直接全拷给 GPU 切片并计算：2*164 + 3*164 + 1*64...
哦对了，你这个果真是uint64的数据？如果不需要，可以改用uint32的，还有你这个图片，看起来像是可以变成稀疏化体素的，不知道是自己写还是因为别的第三方库就要求这种XYZC的稠密格式？有没有办法改用专业的openvdb？
还有一件事，你知不知道你这个切片其实还是有一定计算的，那就是整数索引的乘法计算，因为你的数组大小都不保证是2的幂次方，不仅没有对齐保障也需要一直计算整数乘法（虽然最后还会是内存瓶颈）。使用专业的openvdb稀疏存储，那么每个儿子块都是8x8x8，可以用高效的`>>3`和`&7`来实现三维索引线性化。openvdb最重要的一点是他可以把全部为0的8x8x8区块用一个空指针表示，对于你这种只有一小块有东西，大部分是0的体素能够节省不少空间，可能你是要伺候第三方库，只提供了稠密的固定CXYZ的接口？
``` for (int j = 0; j < height; j++) { dst[0] = col_0[height - 1 - j]; if (2 == td) { dst[1] = col_1_td2[height - 1 - j];...
是td。td是在这个for循环内是常量，为什么要多次重复拷贝进同一个dst + td？我的测试显示60%的时间花在这三个memcpy里。
因为stbiw的作者认为这样拷贝带走方便 无法顺畅的大口呼吸，是活着的最好证明 ---Original--- From: ***@***.***> Date: Wed, Jan 12, 2022 11:41 AM To: ***@***.***>; Cc: ***@***.***>; Subject: Re: [parallel101/hw01] homework - finish (PR #69) 我知道了，用到stbiw库的没有加#define STB_IMAGE_WRITE_IMPLEMENTATION的文件只会拿到库函数的声明 而编译stbiw库的时候，需要加上上面的宏定义把函数的实现给编译器 但是为啥不直接把.h文件分成.h和.cpp呢，一个只有声明，一个只有实现，为什么非得让我们自己写一个空的cpp文件呢？ 我没啥开发经验，实在是很疑惑。 —...