CUDA学习笔记(十一)Memory Access

转载于https://www.cnblogs.com/1024incn/tag/CUDA/

Memory Access Patterns

大部分device一开始从global Memory获取数据,而且,大部分GPU应用表现会被带宽限制。因此最大化应用对global Memory带宽的使用时获取高性能的第一步。也就是说,global Memory的使用就没调节好,其它的优化方案也获取不到什么大效果,下面的内容会涉及到不少L1的知识,这部分了解下就好,L1在Maxwell之后就不用了,但是cache的知识点是不变的。

Aligned and Coalesced Access

如下图所示,global Memory的load/store要经由cache,所有的数据会初始化在DRAM,也就是物理的device Memory上,而kernel能够获取的global Memory实际上是一块逻辑内存空间。Kernel对Memory的请求都是由DRAM和SM的片上内存以128-byte和32-byte传输解决的。

 

所有获取global Memory都要经过L2 cache,也有许多还要经过L1 cache,主要由GPU的架构和获取模式决定的。如果L1和L2都被使用,那么Memory的获取是以128-byte为单位传输的,如果只使用L2,则以32-byte为单位传输,在允许使用L1的GPU中(Maxwell已经彻底不使用L1,原本走L1都换成走texture cache),L1是可以在编译期被显示使用或禁止的。

由上文可知,L1 cache中每一行是128bytes,这些数据映射到device Memory上的128位对齐的块。如果warp中每个thread请求一个4-byte的值,那么每次请求会要求获取128 bytes值,正好契合cache line大小和device Memory segment大小。

因此,我们在设计代码的时候,有两个特征需要注意:

  1. Aligned Memory access 对齐
  2. Coalesced Memory access 连续

当要获取的Memory首地址是cache line的倍数时,就是Aligned Memory Access,如果是非对齐的,就会导致浪费带宽。至于Coalesced Memory Access则是warp的32个thread请求的是连续的内存块。

下图就是很好的符合了连续和对齐原则,只有128-byte Memory传输的消耗:

 

下图则没有遵守连续和对齐原则,有三次传输消耗发生,一次是从偏移地址0开始,一次是从偏移地址256开始,还有一次是从偏移128开始,而这次包含了大部分需要的数据,另外两次则有很多数据并不是需要的,而导致带宽浪费。

 

一般来讲,我们应该这样优化传输效率:使用最少的传输次数来满足最大的获取内存请求。当然,需要多少传输,多大的吞吐都是跟CC有关的。

Global Memory Reads

在SM中,数据运送是要经过下面三种cache/buffer的,主要依赖于要获取的device Memory种类:

  1. L1/L2 cache
  2. Constant cache
  3. Read-only cache

L1/L2是默认路径,另外两条路需要应用显示的说明,一般这样做都是为了提升性能(写CUDA代码的时候,可以先都使用global Memory,然后根据需要慢慢调节,使用一些特殊的内存来提升性能)。Global Memory的load操作是否经过L1cache可以有下面两个因素决定:

  1. Device compute capability
  2. Compiler options

默认情况下,L1是被开启的,-Xptxas -dlcm=cg可以用来禁用L1。L1被禁用后,所有去L1的都直接去L2了。当L2未命中时,就直接去DRAM。所有Memory transaction可能请求一个,两个或者四个segment,每个segment是32 bytes。当然L1也可以被显式的开启-Xptxas -dlcm=ca,此时,所有Memory请求都先走L1,未命中则去L2。在Kepler K10,K20和K20x系列GPU,L1不在用来cache global Memory,L1的唯一用途就是来cache由于register spill放到local Memory的那部分register。

Cache Loads

我们以默认开启L1为例,说明下对齐和连续,下图是理想的情况,连续且对齐,warp中所有thread的Memory请求都落在同一块cache line(128 bytes),只有一次传输消耗,没有任何多余的数据被传输,bus使用效率百分百。

 

下图是对齐但线程ID和地址不是连续一一对应的情况,不过由于所有数据仍然在一个连续对齐的块中,所有依然没有额外的传输消耗,我们仍然只需要一次128 bytes的传输就能完成。

 

下图则是非连续未对齐的情况,数据落在了两个128-byte的块中,所以就有两个128-byte的传输消耗,而其中有一半是无效数据,bus使用是百分之五十。

 

下图是最坏的情况,同样是请求32个4 bytes数据,但是每个地址分布的相当不规律,我们只想要需要的那128 bytes数据,但是,实际上下图这样的分布,却需要N∈(0,32)个cache line,也就是N次数据传输消耗。

 

CPU的L1 cache是根据时间和空间局部性做出的优化,但是GPU的L1仅仅被设计成针对空间局部性而不包括时间局部性。频繁的获取L1不会导致某些数据驻留在cache中,只要下次用不到,直接删。

Uncached Loads

这里就是指不走L1但是还是要走L2,也就是cache line从128-byte变为32-byte了。依然以上文warp 32个thread每个4 bytes请求,总计128 bytes为例,下图是理想的对齐且连续情形,所有的128 bytes都落在四块32 bytes的块中。

 

下图请求没有对齐,请求落在了160-byte范围内,bus有效使用率是百分之八十,相对使用L1,性能要好不少。

 

下图是所有thread都请求同一块数据的情形,bus有效使用率为4bytes/32bytes=12.5%,依然要比L1表现好。

 

下图是情况最糟糕的,数据非常分散,但是由于所请求的128 bytes落在了多个以32 bytes为单位的segment中,因此无效的数据传输要少的多。

 

Example of Misaligned Reads

内存获取模式一般都是有应用的实现和算法来决定的,一些情况下,要满足连续内存是非常难的。但是对于对齐来说,是有一些方法来帮助应用实现的。

下面以代码来检验上述知识,kernel中多了一个k索引,是用来配置偏移地址的,通过他就可以配置对齐情况,只有在load两个数组A和B时才会使用k。对C的写操作则继续使用原来的代码,从而保证写操作 保持很好的对齐。

__global__ void readOffset(float *A, float *B, float *C, const int n,int offset) {unsigned int i = blockIdx.x * blockDim.x + threadIdx.x;unsigned int k = i + offset;if (k < n) C[i] = A[k] + B[k];
}        

下面是main代码,offset默认是零:

 View Code

编译运行:

复制代码

$ nvcc -O3 -arch=sm_20 readSegment.cu -o readSegment
$ ./readSegment 0
readOffset <<< 32768, 512 >>> offset 0 elapsed 0.001820 sec
$ ./readSegment 11
readOffset <<< 32768, 512 >>> offset 11 elapsed 0.001949 sec
$ ./readSegment 128
readOffset <<< 32768, 512 >>> offset 128 elapsed 0.001821 sec

复制代码

当offset=11时,会导致从A和B load数据时不对齐。其运行时间消耗也是最大的,我们可以使用nvcc的gld_efficiency来检验一下:

$ nvprof --devices 0 --metrics gld_efficiency ./readSegment 0
$ nvprof --devices 0 --metrics gld_efficiency ./readSegment 11
$ nvprof --devices 0 --metrics gld_efficiency ./readSegment 128

输出:

Offset 0: gld_efficiency 100.00%
Offset 11: gld_efficiency 49.81%
Offset 128: gld_efficiency 100.00%

可以看到offset=11时,效率减半,可以预见其吞吐必然很高,也可以使用gld_transactions来检验:

$ nvprof --devices 0 --metrics gld_transactions ./readSegment $OFFSET

输出为:

Offset 0: gld_transactions 65184
Offset 11: gld_transactions 131039
Offset 128: gld_transactions 65744

然后我们使用-Xptxas -dlcm=cg来禁用L1,看一下直接使用L2的表现:

$ ./readSegment 0
readOffset <<< 32768, 512 >>> offset 0 elapsed 0.001825 sec
$ ./readSegment 11
readOffset <<< 32768, 512 >>> offset 11 elapsed 0.002309 sec
$ ./readSegment 128
readOffset <<< 32768, 512 >>> offset 128 elapsed 0.001823 sec

从该结果看出,未对齐的情况更糟糕了,然后看下gld_efficiency:

Offset 0: gld_efficiency 100.00%
Offset 11: gld_efficiency 80.00%
Offset 128: gld_efficiency 100.00%

因为L1被禁用后,每次load操作都是以32-byte为单位而不是128,所以无用数据会减少非常多。

这里未对齐反而情况变糟是一种特例,高Occupancy情况下,uncached会帮助提升bus有效使用率,而对于未对齐的情况,无用数据的传输将明显减少。

Read-Only Cache

最开始,read-only cache是用来为texture Memory load服务的,对于CC3.5以上,该cache可以替换L1(Maxwell之后,L1的功能完全就被这个cache取代了)。Read-only cache的单位是32 bytes,一般来讲是比L1要好用得多。

有两种方式来使用read-only cache:

  1. Using the function __ldg
  2. Using a declaration qualifier on the pointer being dereferenced

例如:

__global__ void copyKernel(int *out, int *in) {int idx = blockIdx.x * blockDim.x + threadIdx.x;out[idx] = in[idx];
}

改写后:

__global__ void copyKernel(int *out, int *in) {int idx = blockIdx.x * blockDim.x + threadIdx.x;out[idx] = __ldg(&in[idx]);
}

或者使用 const __restrict__来修饰指针。该修饰符帮助nvcc编译器识别non-aliased指针,nvcc会自动使用该non-alias 指针从read-cache读出数据。

__global__ void copyKernel(int * __restrict__ out,const int * __restrict__ in) {int idx = blockIdx.x * blockDim.x + threadIdx.x;out[idx] = in[idx];
}

Global Memory Writes

写操作相对要简单的多,L1压根就不使用了。数据只会cache在L2中,所以写操作也是以32bytes为单位的。Memory transaction一次可以是一个、两个或四个segment。例如,如果两个地址落在了同一个128-byte的区域内,但是在不同的两个64-byte对齐的区域,一个四个segment的transaction就会被执行(也就是说,一个单独的4-segment的传输要比两次1-segment的传输性能好)。

下图是一个理想的情况,连续且对齐,只需要一次4 segment的传输:

 

下图是离散的情况,会由三次1-segment传输完成。

 

下图是对齐且地址在一个连续的64-byte范围内的情况,由一次2-segment传输完成:

 

Example of Misaligned Writes

再次修改代码,load变回使用i,而对C的写则使用k:

__global__ void writeOffset(float *A, float *B, float *C,const int n, int offset) {unsigned int i = blockIdx.x * blockDim.x + threadIdx.x;unsigned int k = i + offset;if (k < n) C[k] = A[i] + B[i];
}    

修改host的计算函数;

void sumArraysOnHost(float *A, float *B, float *C, const int n,int offset) {for (int idx = offset, k = 0; idx < n; idx++, k++) {C[idx] = A[k] + B[k];}
}    

编译运行:

复制代码

$ nvcc -O3 -arch=sm_20 writeSegment.cu -o writeSegment
$ ./writeSegment 0
writeOffset <<< 2048, 512 >>> offset 0 elapsed 0.000134 sec
$ ./writeSegment 11
writeOffset <<< 2048, 512 >>> offset 11 elapsed 0.000184 sec
$ ./writeSegment 128
writeOffset <<< 2048, 512 >>> offset 128 elapsed 0.000134 sec

复制代码

显而易见,Misaligned表现最差,然后查看gld_efficiency:

复制代码

$ nvprof --devices 0 --metrics gld_efficiency --metrics gst_efficiency ./writeSegment $OFFSET
writeOffset Offset 0: gld_efficiency 100.00%
writeOffset Offset 0: gst_efficiency 100.00%
writeOffset Offset 11: gld_efficiency 100.00%
writeOffset Offset 11: gst_efficiency 80.00%
writeOffset Offset 128: gld_efficiency 100.00%
writeOffset Offset 128: gst_efficiency 100.00%

复制代码

除了offset=11的store外,所有load和store都是百分百。当offset=11时,128-bytes的写请求会被一个4-segment和一个1-segment的传输服务,因此,我们虽然需要写128bytes但是却有160bytes数据被load,从而导致百分之八十的效率。

Array of Structure versus Structure of Arrays

作为C程序员,我们应该熟悉两种组织数据的方式:array of structures(AoS)和structure of arrays(SoA)。二者的使用是一个有趣的话题,主要是数据排列组织。

观察下面代码,首先考虑该数据结构集合在使用AoS组织时,是怎样存储的:

struct innerStruct {float x;float y;
};
struct innerStruct myAoS[N]; //每一对x和y的存储,空间上是连续的

然后是SoA:

struct innerArray {float x[N];float y[N];
};
struct innerArray moa; //x和y是分别存储的,所有x和y是分别存储在两段不同的连续地址里。

下图显示了AoS和SoA在内存中的存储格式,当对x进行操作时,会导致一般的带宽浪费,因为在操作x时,y也会隐式的被load,而SoA的表现就要好得多,因为所有x都是相邻的。

 

许多并行编程规范里,特别是SIMD-style风格的规范,都更倾向于使用SoA,在CUDA C里,SoA也是非常建议使用的,因为数据已经预先排序连续了。

Example:Simple Math with the AoS Data Layout

复制代码

__global__ void testInnerStruct(innerStruct *data,innerStruct *result, const int n) {unsigned int i = blockIdx.x * blockDim.x + threadIdx.x;if (i < n) {innerStruct tmp = data[i];tmp.x += 10.f;tmp.y += 20.f;result[i] = tmp;}
}            

复制代码

输入长度是1M,#define LEN 1<<20

初始化数据:

复制代码

void initialInnerStruct(innerStruct *ip, int size) {for (int i = 0; i < size; i++) {ip[i].x = (float)(rand() & 0xFF) / 100.0f;ip[i].y = (float)(rand() & 0xFF) / 100.0f;}return;
}

复制代码

Main代码:

 View Code

编译运行(Fermi M2070):

$ nvcc -O3 -arch=sm_20 simpleMathAoS.cu -o simpleMathAoS
$ ./simpleMathAoS
innerStruct <<< 8192, 128 >>> elapsed 0.000286 sec

查看load和store性能:

$ nvprof --devices 0 --metrics gld_efficiency,gst_efficiency ./simpleMathAoS
gld_efficiency 50.00%
gst_efficiency 50.00%

正如预期那样,都只达到了一般,因为额外那部分消耗都用来load/store 另一个元素了,而这部分不是我们需要的。

Example:Simple Math with the SoA Data Layout

复制代码

__global__ void testInnerArray(InnerArray *data,InnerArray *result, const int n) {unsigned int i = blockIdx.x * blockDim.x + threadIdx.x;if (i<n) {float tmpx = data->x[i];float tmpy = data->y[i];tmpx += 10.f;tmpy += 20.f;result->x[i] = tmpx;result->y[i] = tmpy;}
}    

复制代码

分配global Memory:

int nElem = LEN;
size_t nBytes = sizeof(InnerArray);
InnerArray *d_A,*d_C;
cudaMalloc((InnerArray **)&d_A, nBytes);
cudaMalloc((InnerArray **)&d_C, nBytes);

编译运行:

$ nvcc -O3 -arch=sm_20 simpleMathSoA.cu -o simpleSoA
$ ./simpleSoA
innerArray <<< 8192, 128 >>> elapsed 0.000200 sec

查看load/store性能:

$ nvprof --devices 0 --metrics gld_efficiency,gst_efficiency ./simpleMathSoA
gld_efficiency 100.00%
gst_efficiency 100.00%

Performance Tuning

调节device Memory带宽利用性能时,主要是力求达到下面两个目标:

  1. Aligned and Coalesced Memory accesses that reduce wasted bandwidth
  2. Sufficient concurrent Memory operations to hide Memory latency

Unrolling Techniques

展开循环可以增加更多的独立的Memory操作,我们在之前博文有详细介绍如何展开loop,考虑之前的redSegment的例子,我们修改下readOffset来使每个thread执行四个独立Memory操作,就像下面那样:

复制代码

__global__ void readOffsetUnroll4(float *A, float *B, float *C,const int n, int offset) {unsigned int i = blockIdx.x * blockDim.x * 4 + threadIdx.x;unsigned int k = i + offset;if (k + 3 * blockDim.x < n) {C[i] = A[k]C[i + blockDim.x] = A[k + blockDim.x] + B[k + blockDim.x];C[i + 2 * blockDim.x] = A[k + 2 * blockDim.x] + B[k + 2 * blockDim.x];C[i + 3 * blockDim.x] = A[k + 3 * blockDim.x] + B[k + 3 * blockDim.x];}
}

复制代码

编译运行(可能需要使用-Xptxas -dlcm=ca来启用L1):

复制代码

$ ./readSegmentUnroll 0
warmup <<< 32768, 512 >>> offset 0 elapsed 0.001990 sec
unroll4 <<< 8192, 512 >>> offset 0 elapsed 0.000599 sec
$ ./readSegmentUnroll 11
warmup <<< 32768, 512 >>> offset 11 elapsed 0.002114 sec
unroll4 <<< 8192, 512 >>> offset 11 elapsed 0.000615 sec
$ ./readSegmentUnroll 128
warmup <<< 32768, 512 >>> offset 128 elapsed 0.001989 sec
unroll4 <<< 8192, 512 >>> offset 128 elapsed 0.000598 sec

复制代码

我们看到,unrolling技术会对性能有巨大影响,比地址对齐影响还大。对于这类I/O-bound的kernel,提高内存获取的并行性对性能提升的影响,有更高的优先级。不过,我们应该看到,对齐的test比未对齐的test表现依然要好。

Unrolling并不能影响内存操作的总数目(只是影响并行的操作数目),我们可以查看下相关属性:

复制代码

$ nvprof --devices 0 --metrics gld_efficiency,gst_efficiency ./readSegmentUnroll 11
readOffset gld_efficiency 49.69%
readOffset gst_efficiency 100.00%
readOffsetUnroll4 gld_efficiency 50.79%
readOffsetUnroll4 gst_efficiency 100.00%
$ nvprof --devices 0 --metrics gld_transactions,gst_transactions
./readSegmentUnroll 11
readOffset gld_transactions 132384
readOffset gst_transactions 32928
readOffsetUnroll4 gld_transactions 33152
readOffsetUnroll4 gst_transactions 8064

复制代码

Exposing More Parallelism

这方面就是调整grid和block的配置,下面是加上unrolling后的结果:

复制代码

$ ./readSegmentUnroll 0 1024 22
unroll4 <<< 1024, 1024 >>> offset 0 elapsed 0.000169 sec
$ ./readSegmentUnroll 0 512 22
unroll4 <<< 2048, 512 >>> offset 0 elapsed 0.000159 sec
$ ./readSegmentUnroll 0 256 22
unroll4 <<< 4096, 256 >>> offset 0 elapsed 0.000157 sec
$ ./readSegmentUnroll 0 128 22
unroll4 <<< 8192, 128 >>> offset 0 elapsed 0.000158 sec

复制代码

表现最好的是block配置256 thread的kernel,虽然128thread会增加并行性,但是依然比256少那么一点点性能,这个主要是CC版本对应的资源限制决定的,以本代码为例,Fermi每个SM最多有8个block,每个SM能够并行的的warp是48个,当使用128个thread(per block)时,每个block中有4个warp,因为每个SM最多8个block能够同时运行,因此该kernel每个SM最多只能有32个warp,还有16个warp的计算性能没用上,所以性能差了就,可以使用Occupancy来验证下。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/167927.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

OSI网络分层模型

OSI英文全文是Open System Interconnection Reference Model&#xff0c;翻译成中文就是开放式系统互联通信参考模型。 OSI模型分成了七层&#xff0c;部分层次与 TCP/IP 很像&#xff0c;从下到上分别是&#xff1a; 第一层&#xff1a;物理层&#xff0c;网络的物理形式&…

浏览器从输入url到渲染页面发生了什么?

浏览器从输入url到渲染页面发生了什么&#xff1f; 一、解析URL 首先浏览器做的第一步工作就是要对 URL 进行解析&#xff0c;浏览器会判断这个url的合法性 &#xff0c;以及是否有可用缓存&#xff08;如果有缓存即可以不用进行下一步的DNS域名解析&#xff09;&#xff0c;…

iOS原生、Android 原生, flutter 三种方式给照片流添加文字(水印)

效果图:三中代码实现的效果差不多 Swift:代码 import UIKitclass ImageWatermarking: NSObject {static func textToImage(drawText text: String, inImage initImage: UIImage, atPoint point: CGPoint) -> UIImage {let textColor = UIColor.whitelet textFont = UIFon…

@RequestMapping运用举例(有源码) 前后端如何传递参数?后端如何接收前端传过来的参数,传递单个参数,多个参数,对象,数组/集合(有源码)

目录 一、RequestMapping 路由映射 二、参数传递 1、传递单个参数 2、传递多个参数 3、传递对象 4、后端参数重命名 一、RequestMapping 路由映射 指定请求访问的路径既可以修饰类&#xff0c;又可以修饰方法 RequestMapping支持Get、Post、Delete等多种请求方式 Re…

【JavaScript】深入讲解浏览器渲染原理

一. 浏览器是如何渲染页面的&#xff1f; 当浏览器的网络线程收到 HTML 文档后&#xff0c;会产生一个渲染任务&#xff0c;并将其传递给渲染主线程的消息队列。 在事件循环机制的作用下&#xff0c;渲染主线程取出消息队列中的渲染任务&#xff0c;开启渲染流程。 渲染&…

Gartner 2024年十大战略技术趋势,谈谈持续威胁暴露管理(CTEM)

科技云报道原创。 近日&#xff0c;Gartner发布了2024年企业机构需要探索的10大战略技术趋势。 这份连年更新的报告&#xff0c;是Gartner分析其在未来三年内如何影响企业的战略&#xff0c;以指导关键岗位决策者尽早了解探索并满足各自的业务需求。 2024年十大重要战略趋势…

【数据结构】String类对象的创建与字符串常量池的“神秘交易”

作者主页&#xff1a;paper jie_博客 本文作者&#xff1a;大家好&#xff0c;我是paper jie&#xff0c;感谢你阅读本文&#xff0c;欢迎一建三连哦。 本文录入于《JAVA数据结构》专栏&#xff0c;本专栏是针对于大学生&#xff0c;编程小白精心打造的。笔者用重金(时间和精力…

Tomcat+nginx负载均衡和动静分离

Nginx实现负载均衡和动静分离的原理 Nginx实现负载均衡是通过反向代理实现Nginx服务器作为前端&#xff0c;Tomcat服务器作为后端&#xff0c;web页面请求由Nginx服务来进行转发。 但是不是把所有的web请求转发&#xff0c;而是将静态页面请求Ncinx服务器自己来处理&#xff0c…

vmware安装 Rocky9(自定义分区安装)

一、下载镜像 访问官网&#xff0c;下载dvd的镜像 Download Rocky | Rocky Linuxhttps://rockylinux.org/download 二、新建vmware虚拟机 1、vmware尽量选择vmware17 2、下一步 3、稍后安装 4、选择系统类型&#xff1a;red hat9 5、自定义安装位置 6、根据电脑配置&#…

Windows 95 的辉煌诞生历史

1992 年 2 月&#xff0c;Windows 3.1 的研发即将结束&#xff0c;而 Windows 团队正忙得不亦乐乎地计划他们的下一盘大棋。到了 3 月 5 日&#xff0c;他们终于悠哉悠哉地敲定了战略大计&#xff1a;横扫桌面、笔记本、移动设备以及时髦的触控笔设备。至于那些高大上的服务器和…

自然语言处理---Transformer机制详解之GPT2模型介绍

1 GPT2的架构 从模型架构上看, GPT2并没有特别新颖的架构, 它和只带有解码器模块的Transformer很像. 所谓语言模型, 作用就是根据已有句子的一部分, 来预测下一个单词会是什么. 现实应用中大家最熟悉的一个语言模型应用, 就是智能手机上的输入法, 它可以根据当前输入的内容智…

什么是全链路压测?

随着互联网技术的发展和普及&#xff0c;越来越多的互联网公司开始重视性能压测&#xff0c;并将其纳入软件开发和测试的流程中。 阿里巴巴在2014 年双11 大促活动保障背景下提出了全链路压测技术&#xff0c;能更好的保障系统可用性和稳定性。 什么是全链路压测&#xff1f;…

hello react

react中文官网 一、什么是react React是一个由Facebook开源的JavaScript库&#xff0c;用于构建用户界面。它基于组件化的思想&#xff0c;将界面拆分成多个独立的、可复用的组件&#xff0c;并通过组件之间的交互构建整个用户界面。React使用虚拟DOM&#xff08;Virtual DOM…

成都瀚网科技有限公司:抖音小店选品策略引领电商潮流

在抖音小店日益繁荣的电商环境中&#xff0c;选品显得尤为重要。一个好的产品可以带来稳定的流量和可观的销售额&#xff0c;而一个错误的选择可能导致店铺的运营陷入困境。那么&#xff0c;如何在抖音小店进行正确的选品呢&#xff1f;本文将为你揭示抖音小店选品的秘密通道。…

Jmeter性能 —— 事务控制器

统计性能测试结果一定会关注TPS&#xff0c;TPS表示&#xff1a;每秒处理事务数&#xff0c;JMeter默认每个事务对应一个请求。我们可以用逻辑控制器中的事务控制器将多个请求统计为一个事务。 1、添加事务控制器 2、事务控制器参数说明 Generate parent sample&#xff1a;如…

无纸化办公小程序数据交互、wxs的使用

前言 很多同志们再写小程序的过程中&#xff0c;不知道该怎么发起HTTP请求到后端&#xff0c;在Web环境中发起HTTPS请求是很常见的&#xff0c;但是微信小程序是腾讯内部的产品&#xff0c;不能直接打开一个外部的链接。例如&#xff0c;在微信小程序中不能直接打开www.taobao…

Python数据挖掘 | 升级版自动查核酸

&#x1f4d5;作者简介&#xff1a;热爱跑步的恒川&#xff0c;致力于C/C、Java、Python等多编程语言&#xff0c;热爱跑步&#xff0c;喜爱音乐的一位博主。 &#x1f4d7;本文收录于恒川的日常汇报系列&#xff0c;大家有兴趣的可以看一看 &#x1f4d8;相关专栏C语言初阶、C…

经典卷积神经网络 - LeNet

该模型用于手写的数字识别。 LeNet模型包含了多个卷积层和池化层&#xff0c;以及最后的全连接层用于分类。其中&#xff0c;每个卷积层都包含了一个卷积操作和一个非线性激活函数&#xff0c;用于提取输入图像的特征。池化层则用于缩小特征图的尺寸&#xff0c;减少模型参数和…

【IO】JavaIO流:字节流、字符流、缓冲流、转换流、序列化流等

个人简介&#xff1a;Java领域新星创作者&#xff1b;阿里云技术博主、星级博主、专家博主&#xff1b;正在Java学习的路上摸爬滚打&#xff0c;记录学习的过程~ 个人主页&#xff1a;.29.的博客 学习社区&#xff1a;进去逛一逛~ IO流 Java IO1. 认识IO2. FileOutputStream(写…