在Cortex-A8平台下memcpy性能的测试

2024-01-16 04:48
文章标签 平台 性能 测试 memcpy cortex a8

本文主要是介绍在Cortex-A8平台下memcpy性能的测试，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

用goole搜到的一篇文章： 暂时忘记了出处，转到这里吧！

在Cortex-A8平台下memcpy性能的测试

ShuyongChen

前言

在Crun timelibrary中，memcpy是重要的函数，对应用软件的性能有着重要的影响。ARM芯片发展到Cortex-A8[1][2]架构，不但频率有了很大提升，而且架构设计有了很大地改进。其中增加的NEON指令，是类似于原先X86平台下的MMX指令，是为多媒体而设计。但因为这类指令一次可以处理64-bit数据，对memcpy函数性能提升也很有帮助。本文主要是测试采用NEON[2]指令的多种memcpy实现，探讨NEON指令和预取(preload)指令对性能的影响，以及在芯片优化和工艺进步后，这些影响的变化趋势。同时希望芯片设计人员在了解软件实现的基础上，给予一个知其然，也知其所以然的解释，进而指导进一步提高性能的方向。

平台介绍

本次的测试平台来源于笔者工作项目中接触到的Cortex-A8平台。见下面列表：

  • FreeScalei.MX51 / i.MX53

  • QualCommmsm8x50 / msm7x30

  • Samsungs5pc100 / s5pc110

  • TIomap 3430 / omap 3730

i.MX5family

i.MX5family的介绍见[6][7]。其中i.MX535可以运行在800MHZ/ 1000MHZ两种频率上。

  • i.MX515

  • freq:800MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • i.MX535

  • freq:800MHZ / 1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

Snapdragonfamily

Snapdragon的介绍见[8][9][10]。其中msm7x30可以运行在800MHZ/ 1000MHZ两种频率上。此外Snapdragoncache特别之处是128-bitwide(NEON), 128-byte / line。标准Cortex-A8中，该数值为64-bitwide(NEON), 64-byte / line。这对性能有较大影响。

  • msm8x50

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 128-bit wide(NEON), 128-byte / line

  • msm7x30

  • freq:800MHZ / 1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 128-bit wide(NEON), 128-byte / line

s5pcfamily

s5pcfamily参考平台见[11]。

  • s5pc100

  • freq:665MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • s5pc110

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 512KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

omap3family

omap3family参考平台见[12][13][14]。

  • omap3430

  • freq:550MHZ

  • cachesize: 16KB/16KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

  • omap3730

  • freq:1000MHZ

  • cachesize: 32KB/32KB I/D Cache and 256KB L2 Cache

  • cacheline: 64-bit wide(NEON), 64-byte / line

memcpy实现介绍

memcpy的实现在ARM平台上的发展有3类版本：

  1. C语言版本

  2. ARM汇编版本

  3. NEON汇编版本

ARM公司的文档[4]对memcpy的实现有很好描述。有人[5][19][20]还进一步阐述了实现原理和技巧。简述如下：

  • NEON指令一次可以处理64-bit数据，效率更高。

  • NEON架构与L1/L2cache都有直连，在OS层级enable后，可以获得更好的性能。

  • ARM/ NEON的pipeline有可能异步处理，交替使用ARM/ NEON指令有可能获得更好的性能。

  • 在一次循环中，用尽可能多的寄存器copy更多的数据，保证pipeline有更好的效率。目前一次最大处理块为128-byte。

  • 对cache的操作有讲究。

  • memcpy属于一次扫瞄无回溯的操作，对于cache采用预取(preload)策略可以提高hitrate。所以汇编版本中一定会使用pld指令提示ARM预先把cacheline填充好。

  • pld指令中的offset很有讲究。一般为64-byte的倍数。在ARMv5TE平台是一个循环用一个pld指令。在Cortex-A8平台上速度更快，需要一个循环用2~3个pld指令填充cacheline。这样一个循环消费2~3个时钟周期换得cachehit rate提高，效果是值得的。

  • 进一步的，Cortex-A8架构提供了preloadengine指令，可以让软件更深地影响cache，以便让cachehit rate得到提高。不过要在用户空间使用ple指令，需要在OS中打补丁开放权限。



C语言版本

C语言版本主要是做对比。采用两个实现：

  1. 32-bitwide copy。后面标记为in32_cpy。

  2. 16-bytewide copy。后面标记为vec_cpy。这个实现的技巧是采用gcc的向量扩展”__attribute__((vector_size(16)))”，在C语言层级实现16-bytewide copy，将具体实现交给编译器。



值得注意的事情是，编译器不会主动插入pld指令。因为编译器无法判断应用对内存的访问模式。

ARM汇编版本

ARM汇编版本也主要是做对比。采用两个实现：

  1. SiarheiSiamashka实现[15]。后面标记为arm9_memcpy。他是为NokiaN770做的优化。

  2. NicolasPitre实现[16]。后面标记为armv5te_memcpy。这是目前glibc里面缺省的armmemcpy实现。

NEON汇编版本

NEON汇编版本采用四个实现：

  1. MånsRullgård实现[19]。这是一个128-byte-alignblock的最简单的实现。没有判断不是128-bytealign的情况。因此不是实用的版本。但通过这类实现，可以考察memcpy性能的极限。他总共提供4种实现。

    1. 全ARM汇编的实现。后面标记为memcpy_arm。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_arm_nopld。

    2. 全NEON汇编的实现。后面标记为memcpy_neon。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_nopld。

    3. ARM/NEON指令交替使用的实现。后面标记为memcpy_armneon。此外，笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_armneon_nopld。

    4. ple+NEON的实现。后面标记为memcpy_ple_neon。此外，笔者还将其中的NEON指令换成ARM指令，做为对比试验，考察ple指令对ARM/NEON指令的影响。后面标记为memcpy_ple_arm。因为这个实现需要对linuxkernel打补丁，在omap3430平台上没有成功。在Snapdragon平台上更换kernel有些麻烦，所以也没有测试。

  2. CodeSourcery实现[17]。这是CodeSourcerytoolchain中的glibc里面的实现。也分两种实现。

    1. ARM实现。后面标记为memcpy_arm_codesourcery。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_arm_codesourcery_nopld。

    2. NEON实现。后面标记为memcpy_neon_codesourcery。这也是Androidbionic里面采用的NEON实现。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_codesourcery_nopld。

  3. QualComm实现[18]。后面标记为memcpy_neon_qualcomm。这是QualComm在CodeAurora Forum中为Snapdragon平台开发的优化版本。主要是对8660/8650A平台的优化。这个版本的特点是针对L2cache line size ＝ 128bytes而设计，pldoffset设置得特别大。结果在其它Cortex-A8平台上没有效果。所以笔者将pldoffset改为MånsRullgård实现的数值。笔者还将其中的pld指令去掉，做为对比试验，考察pld指令的影响。后面标记为memcpy_neon_qualcomm_nopld。

  4. SiarheiSiamashka实现[20]。后面标记为memcpy_neon_siarhei。这是SiarheiSiamashka向glibc提交的NEON版本，没有被glibc采纳。但是在MAEMO项目中得到采用。这个版本的特点是pldoffset是从小到大增长的，以期望适应blocksize的变化。

测试方案介绍

测试方案十分简单。参考了movialmemory tester的实现[21]。执行步骤如下：

  1. 先对每个实现进行正确性的验证。主要方法是以随机的blocksize & offset，填充随机的内容，然后执行memcpy操作，然后再用系统的memcmp函数对两块内存做校验。

  2. 然后对每个实现以不同的blocksize调用400次。如果totalcopy size < 1MB，则增加count直到满足要求。对总操作计时。

  3. 以totalcopy size / total copy time公式计算memcpybandwidth。



上述提到的blocksize = 2^n ( 7 <= n <= 23 )。



此外，这个测试程序运行在openembedded-gpe软件系统中。QualComm/Samsung硬件平台只提供Android软件系统，要更换到GPE系统有些麻烦，则采用chroot方式进行测试。不论是哪种软件平台，都是进入到图形系统后，静置，等待黑屏，然后再进行测试。



下表是运行环境的统计。

硬件平台

软件环境

imx51800MHZ

openembedded-gpe

imx531000MHZ

openembedded-gpe

imx53800MHZ

openembedded-gpe

msm72301000MHZ

Android+ chroot

msm7230800MHZ

Android+ chroot

msm82501000MHZ

Android+ chroot

omap3430550MHZ

openembedded-gpe

omap37301000MHZ

openembedded-gpe

s5pc100665MHZ

Android+ chroot

s5pc1101000MHZ

Android+ chroot



下表是测试项目的统计。

实现方案

i.MX51

i.MX53

Snapdragon

s5pc1xx

omap3430

omap3730

int32_cpy

YES

YES

YES

YES

YES

YES

vec_cpy

YES

YES

YES

YES

YES

YES

arm9_memcpy

YES

YES

YES

YES

YES

YES

armv5te_memcpy

YES

YES

YES

YES

YES

YES

memcpy_arm

YES

YES

YES

YES

YES

YES

memcpy_arm_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon

YES

YES

YES

YES

YES

YES

memcpy_neon_nopld

YES

NO

YES

YES

YES

YES

memcpy_armneon

YES

YES

YES

YES

YES

YES

memcpy_ple_arm

YES

YES

N/A

YES

N/A

YES

memcpy_ple_neon

YES

YES

N/A

YES

N/A

YES

memcpy_arm_codesourcery

YES

YES

YES

YES

YES

YES

memcpy_arm_codesourcery_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_codesourcery

YES

YES

YES

YES

YES

YES

memcpy_neon_codesourcery_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_qualcomm

YES

YES

YES

YES

YES

YES

memcpy_neon_qualcomm_nopld

YES

NO

YES

YES

YES

YES

memcpy_neon_siarhei

YES

YES

YES

YES

YES

YES

注1：因为i.MX53EVK板子发生故障，未能测试所有nopld的测试项。

注2：在给omap3430打开preloadengine后，测试产生非法指令错，未能测试ple的测试项。

注3：要替换Snapdragonkernel有些麻烦， 未能测试ple的测试项。

测试结果与分析

下面的图表限于页面大小不能很好地显示细节。具体的数据和大图可到数据表文档中查看。

各个硬件平台上各种实现的表现

  1. imx51800MHZ





  1. imx531000MHZ





  1. imx53800MHZ





  1. msm72301000MHZ





  1. msm7230800MHZ





  1. msm82501000MHZ





  1. omap3430550MHZ





  1. omap37301000MHZ





  1. s5pc100665MHZ





  1. s5pc1101000MHZ





  1. 小结

  1. 在blocksize = 512B ~ 32K之间，有一个性能高台，blocksize = 256K也有一个性能的转折。

    1. 这个特性体现了32KBL1 / 256KB L2 cache的影响。

    2. 小于512B的性能不佳，可能与函数调用，函数开始的块对齐技巧造成的损耗有关，也可能与blocksize太小，cache没有准备好函数就结束了有关。

  2. 文档[]对memcpy的实现还是有指导意义的。但随着芯片内部的优化和工艺的提升，有些规则发生了变化。

    1. NEON指令的性能总是要高于ARM指令的性能。但交替使用ARM/NEON指令并不总是带来性能的提升。随着发展ARM/NEON指令之间性能差在缩小。

    2. pld指令的作用越来越小。在较老的芯片上，如omap3430，采用pld指令后，同一个实现可以有50%的性能提升。在较新的芯片上，如msm7230/s5pc110上，性能基本没有区别，甚至同一个实现没有pld指令后，性能稍稍有些提升。这也许是因为pld指令没有效果，倒反在每个循环中浪费了时钟周期造成的。

    3. 采用ple指令的实现的性能令人大失所望。这也说明如果没有很好的模型设计，软件去干预cache的使用，很容易会造成性能的恶化。

  3. Snapdragon平台有最好的cache性能。超出cache后，各种实现(包括C语言实现)的性能基本一致，也很高效。这也许是Snapdragon平台13-stageload/storepipeline[][]的设计造成的。这个特性对高级语言是有好处的。因为编程不可能在很多地方采用汇编语言。这样开发人员就不必过多地考虑汇编优化，依赖编译器就可以了。

  4. s5pc110平台有最好的平均性能。超出cache后，NEON实现的性能最好，基本保持一条水平线。

在small/bigblock size下各个硬件平台的表现

性能因为blocksize分为fitin cache / out of cache两种表现，所以做两个剖面做对比分析。

  • 8Kblock size。体现fitin cache时的性能。

  • 8Mblock size。体现outof cache时的性能。

MånsRullgård的实现

因为MånsRullgård的实现最简单，除了一个循环体外，没有其它判断代码，可以认为是体现平台速度极限的实现。





ARM的实现









NEON的实现









小结

  1. NEON指令的性能总是要高于ARM指令的性能。随着发展ARM/NEON指令之间性能差在缩小。

  2. 交替使用ARM/NEON指令，在fitin cache条件下性能要差于NEON版本。在outof cache条件下，两个版本性能基本一样。

  3. 在fitin cache条件下，Snapdragon平台有最好的性能。超过第二名s5pc110大约为43%。

  4. 在outof cache条件下，s5pc110有最好的性能。超过第二名omap3730大约为57%。

  5. 在同一个硬件平台下，超频(如i.MX53800/1000MHZ & msm7x30 800/1000MHZ)对memory性能影响很小。

实用ARM/NEON实现在各个硬件平台的表现

通过同一种实现在不同硬件平台上性能的对比，结合上一节的图表，可以评价一种实现的平均性能，也就是适应性。

ARM的实现













NEON的实现













小结

  1. 同一种的实现，在不同的硬件平台上都有不同的表现。没有一种实现在所有平台上是最好的。

  2. Codesourcery版本，包括ARM/NEON版本，有很好的适应性。不愧是做toolchain的公司。

  3. SiarheiSiamashka的NEON版本也有很好的适应性。NOKIA的技术实力也很强。这哥们好像也是pixman项目里面做NEON优化的主力。

  4. Qualcomm版本只适合Snapdragon平台。期待以后能在msm8660以及后续的芯片上进行测试。

总结

  1. 在blocksize = 512B ~ 32K之间，有一个性能高台，blocksize = 256K也有一个性能的转折。这个特性体现了32KBL1 / 256KB L2 cache的影响。

  2. NEON指令的性能总是要高于ARM指令的性能。随着发展ARM/NEON指令之间性能差在缩小。交替使用ARM/NEON指令，性能往往要差于NEON版本。

  3. 如果没有很好的模型设计，软件去干预cache的使用，很容易会造成性能的恶化。

  4. 在fitin cache条件下，Snapdragon平台有最好的性能。

  5. 在outof cache条件下，s5pc110有最好的性能。

  6. 在同一个硬件平台下，超频对memory性能影响很小。

  7. 同一种的实现，在不同的硬件平台上都有不同的表现。没有一种实现在所有平台上是最好的。

进一步的测试

因为在Cortex-A8系列芯片里，NEON模块是必有的。而在Cortex-A9系列芯片里，NEON模块是可选的。因为NEON模块会影响到diesize，因而影响功耗和成本。因此有些Cortex-A9芯片，如NvidiaTegra250，没带有NEON模块。那么有无NEON模块会对软件性能造成什么样的影响呢？

参考文档

  1. ARMCortex-A8

http://en.wikipedia.org/wiki/ARM_Cortex-A8



  1. Cortex™-A8Technical Reference Manual

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344k/index.html



  1. c0,Cache Size Identification Registers

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Chdebced.html



  1. Whatis the fastest way to copy memory on a Cortex-A8?

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html



  1. ARM-NEONmemory hazards

http://hardwarebug.org/2008/12/31/arm-neon-memory-hazards/



  1. i.MX5family

http://en.wikipedia.org/wiki/I.MX



  1. Freescalei.MX515

http://www.7-cpu.com/cpu/imx515.html



  1. Snapdragon(System on Chip)

http://en.wikipedia.org/wiki/Snapdragon_(System_on_Chip)



  1. QualcommReveals Details on Scorpion Core

http://www.bdti.com/InsideDSP/2007/11/14/Qualcomm



  1. QualcommSnapdragon

http://www.7-cpu.com/cpu/Snapdragon.html



  1. ODROID

http://hardkernel.com/



  1. OMAP3family

http://en.wikipedia.org/wiki/OMAP3



  1. OmapWorld

http://omapworld.com/



  1. beagleboard

http://beagleboard.org/



  1. SiarheiSiamashka: Optimized Memory Copying Functions For Nokia 770

http://lists.maemo.org/pipermail//maemo-developers/2006-March/003269.html



  1. NicolasPitre: ARM memcpy and memmove

http://sourceware.org/ml/libc-ports/2006-10/msg00024.html



  1. CodeSourceryC Library

http://www.codesourcery.com/



  1. Neonmemcpy: Attempts to do a memcpy with Neon registers if possible

https://www.codeaurora.org/patches/quic/qsd/SAMPLE_3918_NEON_MEMOPS_20101001.tar.gz



  1. MånsRullgård: memory bandwidth problem - Beagle Board

http://groups.google.com/group/beagleboard/browse_thread/thread/12c7bd415fbc0993/c54dde7b9d55cf99



  1. SiarheiSiamashka: ARM: NEON optimized implementation of memcpy

http://sourceware.org/ml/libc-ports/2009-07/msg00003.html



  1. Memorytester

http://sandbox.movial.com/gitweb?p=mmem.git;a=summary



这篇关于在Cortex-A8平台下memcpy性能的测试的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/611388。

相关文章

Nginx设置连接超时并进行测试的方法步骤

Nginx设置连接超时并进行测试的方法步骤

《Nginx设置连接超时并进行测试的方法步骤》在高并发场景下,如果客户端与服务器的连接长时间未响应,会占用大量的系统资源,影响其他正常请求的处理效率,为了解决这个问题,可以通过设置Nginx的连接... 目录设置连接超时目的操作步骤测试连接超时测试方法：总结：设置连接超时目的设置客户端与服务器之间的连接
阅读更多...
Springboot中分析SQL性能的两种方式详解

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式：MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录
阅读更多...
Tomcat高效部署与性能优化方式

Tomcat高效部署与性能优化方式

《Tomcat高效部署与性能优化方式》本文介绍了如何高效部署Tomcat并进行性能优化,以确保Web应用的稳定运行和高效响应,高效部署包括环境准备、安装Tomcat、配置Tomcat、部署应用和启动T... 目录Tomcat高效部署与性能优化一、引言二、Tomcat高效部署三、Tomcat性能优化总结Tom
阅读更多...
C#使用yield关键字实现提升迭代性能与效率

C#使用yield关键字实现提升迭代性能与效率

《C#使用yield关键字实现提升迭代性能与效率》yield关键字在C#中简化了数据迭代的方式,实现了按需生成数据,自动维护迭代状态,本文主要来聊聊如何使用yield关键字实现提升迭代性能与效率,感兴... 目录前言传统迭代和yield迭代方式对比yield延迟加载按需获取数据yield break显式示迭
阅读更多...
Java实现任务管理器性能网络监控数据的方法详解

Java实现任务管理器性能网络监控数据的方法详解

《Java实现任务管理器性能网络监控数据的方法详解》在现代操作系统中,任务管理器是一个非常重要的工具,用于监控和管理计算机的运行状态,包括CPU使用率、内存占用等,对于开发者和系统管理员来说,了解这些... 目录引言一、背景知识二、准备工作1. Maven依赖2. Gradle依赖三、代码实现四、代码详解五
阅读更多...
如何测试计算机的内存是否存在问题? 判断电脑内存故障的多种方法

如何测试计算机的内存是否存在问题? 判断电脑内存故障的多种方法

《如何测试计算机的内存是否存在问题?判断电脑内存故障的多种方法》内存是电脑中非常重要的组件之一，如果内存出现故障，可能会导致电脑出现各种问题，如蓝屏、死机、程序崩溃等，如何判断内存是否出现故障呢？下... 如果你的电脑是崩溃、冻结还是不稳定，那么它的内存可能有问题。要进行检查，你可以使用Windows 11
阅读更多...
正则表达式高级应用与性能优化记录

正则表达式高级应用与性能优化记录

《正则表达式高级应用与性能优化记录》本文介绍了正则表达式的高级应用和性能优化技巧,包括文本拆分、合并、XML/HTML解析、数据分析、以及性能优化方法,通过这些技巧,可以更高效地利用正则表达式进行复杂... 目录第6章：正则表达式的高级应用6.1 模式匹配与文本处理6.1.1 文本拆分6.1.2 文本合并6
阅读更多...
Vue3 的 shallowRef 和 shallowReactive：优化性能

Vue3 的 shallowRef 和 shallowReactive：优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉，那么对 shallowRef 和 shallowReactive 是否了解呢？ 在编程和数据结构中，“shallow”（浅层）通常指对数据结构的最外层进行操作，而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素，而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层（Shallow） 定义
阅读更多...
流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台，是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力，在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术，能够处理多种视频流格式，并以多种格式（RTMP、RTSP、HTTP-FLV、WebS
阅读更多...
性能测试介绍

性能测试介绍

性能测试是一种测试方法，旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试，可以确定系统是否能够满足预期的性能要求，找出性能瓶颈和潜在的问题，并进行优化和调整。 发现性能瓶颈：性能测试可以帮助发现系统的性能瓶颈，即系统在高负载或高并发情况下可能出现的问题
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2