今天用原子的767板子测试了一下运行速度，不太如意，跟写的462DMIPS还是有比较大差距。请各位大神解惑：
测试中，做了一个约30万次的循环，汇编中共使用了27个指令（已包含循环本身的指令）；总的耗时34ms左右，这算出来的大概只有56%（462DMIPS）左右的性能。分析和疑问如下：
27个指令中，有7个LDR加载指令，可能是加载内存数据时间较长拖慢计算时间，于是做了以下测试：
测试1.对比cache开和不开的差别，发现没差别（就算把指令改成从固定内存中拿出来计算，开和不开还是没差别）
测试2.对比片内SRAM和SDRAM差别，片内SRAM只有3%的性能优势。
测试3.对比片内SRAM和DTCM（程序有所修改，因为DTCM只有128KB），结果是基本没差别。
问题：（上面说没啥差别指的是差别在1%以内）
1.测试1为啥没差别？
2.测试2差别偏少啊。
3.测试3为啥没差别？手册上宣传Cache，TCM的加入，使得f7有明显的性能提升，但用跟不用一个样。
4.从汇编来看，使用了已经是最简单的“加、减、比较、跳转”，乘、除都没有，更没有浮点运算，为啥只能达到462DMIPS的56%这么少？
以下贴出具体的时间：
0x08005A92 E022 B 0x08005ADA
155: for(j=1;j<640;j++)
156: {
0x08005A94 2601 MOVS r6,#0x01
0x08005A96 E01C B 0x08005AD2
157: pt= image[0]; //1.5ms
0x08005A98 4C66 LDR r4,[pc,#408] ; @0x08005C34
158: pt+=i*640+j-640; //7ms
159:
0x08005A9A EB050085 ADD r0,r5,r5,LSL #2
0x08005A9E EB0610C0 ADD r0,r6,r0,LSL #7
0x08005AA2 F5A07020 SUB r0,r0,#0x280
0x08005AA6 4404 ADD r4,r4,r0
160: k=*(pt-1) + *pt * 2+ *(pt+1); //11ms
161:
0x08005AA8 F8141C01 LDRB r1,[r4,#-0x01]
0x08005AAC 7820 LDRB r0,[r4,#0x00]
0x08005AAE EB010040 ADD r0,r1,r0,LSL #1
0x08005AB2 7861 LDRB r1,[r4,#0x01]
0x08005AB4 1847 ADDS r7,r0,r1
162: pt+=1280;
0x08005AB6 F50464A0 ADD r4,r4,#0x500
163: f=*(pt-1) + *pt * 2 + *(pt+1); //11ms
164:
165:
0x08005ABA F8141C01 LDRB r1,[r4,#-0x01]
0x08005ABE 7820 LDRB r0,[r4,#0x00]
0x08005AC0 EB010040 ADD r0,r1,r0,LSL #1
0x08005AC4 7861 LDRB r1,[r4,#0x01]
0x08005AC6 EB000A01 ADD r10,r0,r1
166: k+=f-k; //1.5ms
167:
188: }
189: }
0x08005ACA EBAA0007 SUB r0,r10,r7
0x08005ACE 4407 ADD r7,r7,r0
0x08005AD0 1C76 ADDS r6,r6,#1
0x08005AD2 F5B67F20 CMP r6,#0x280
0x08005AD6 DBDF BLT 0x08005A98
153: for(i=1;i<480-1;i++)
0x08005AD8 1C6D ADDS r5,r5,#1
0x08005ADA F5B57FEF CMP r5,#0x1DE
0x08005ADE DDD9 BLE 0x08005A94
2024-4-30 17:15:51
首先，我们来分析一下你的问题和测试结果。在测试中，你发现实际性能与理论性能（462DMIPS）之间存在较大差距。你提到了两个可能影响性能的因素：LDR加载指令和内存访问速度。接下来，我们将针对这两个因素进行详细分析。
1. LDR加载指令的影响：
你提到了27个指令中有7个LDR加载指令，这可能会影响程序的运行速度。LDR指令用于加载内存中的数据到寄存器，这个过程可能会受到内存访问速度的影响。然而，你已经尝试了两种测试来评估LDR指令的影响：
a. 测试1：对比cache开和不开的差别。你发现开启和关闭cache对性能没有影响。这可能是因为STM32F7的cache设计和大小不足以显著提高性能，或者你的测试代码没有充分利用cache的优势。
b. 测试2：对比片内SRAM和SDRAM的差别。你发现使用片内SRAM的性能只提高了3%。这可能是因为片内SRAM的访问速度与SDRAM相差不大，或者你的测试代码没有充分利用片内SRAM的优势。
2. 其他可能影响性能的因素：
除了LDR加载指令和内存访问速度之外，还有一些其他因素可能会影响STM32F7的性能：
a. 指令流水线：现代处理器通常采用指令流水线技术来提高执行效率。然而，当遇到流水线冲突（如数据冲突、控制冲突等）时，流水线的效率会降低。你的测试代码可能存在一些流水线冲突，导致实际性能低于理论性能。
b. 指令混合：你的测试代码中包含了不同类型的指令，这可能会导致处理器的指令调度器无法充分利用指令并行性，从而降低性能。
c. 编译器优化：编译器在将高级语言代码转换为汇编代码时，可能会进行一些优化。这些优化可能会影响最终的汇编代码和性能。你可以尝试使用不同的编译器选项来观察性能的变化。
d. 系统时钟：STM32F7的性能与系统时钟密切相关。确保你的系统时钟设置正确，以充分利用处理器的性能。
为了进一步提高STM32F7的性能，你可以尝试以下方法：
1. 优化汇编代码：检查你的汇编代码，看看是否有优化的空间，如减少流水线冲突、提高指令并行性等。
2. 使用更高效的数据结构和算法：选择更适合STM32F7的数据处理方式，如使用寄存器数组而不是内存数组，以减少内存访问延迟。
3. 调整编译器选项：尝试使用不同的编译器选项，如开启或关闭某些优化，以找到最佳的性能平衡点。
4. 调整系统时钟：确保你的系统时钟设置正确，以充分利用处理器的性能。
5. 使用硬件加速器：如果STM32F7提供了硬件加速器（如DMA、FPU等），尝试使用这些硬件加速器来提高性能。
通过以上分析和建议，希望能帮助你找到提高STM32F7性能的方法。
首先，我们来分析一下你的问题和测试结果。在测试中，你发现实际性能与理论性能（462DMIPS）之间存在较大差距。你提到了两个可能影响性能的因素：LDR加载指令和内存访问速度。接下来，我们将针对这两个因素进行详细分析。
1. LDR加载指令的影响：
你提到了27个指令中有7个LDR加载指令，这可能会影响程序的运行速度。LDR指令用于加载内存中的数据到寄存器，这个过程可能会受到内存访问速度的影响。然而，你已经尝试了两种测试来评估LDR指令的影响：
a. 测试1：对比cache开和不开的差别。你发现开启和关闭cache对性能没有影响。这可能是因为STM32F7的cache设计和大小不足以显著提高性能，或者你的测试代码没有充分利用cache的优势。
b. 测试2：对比片内SRAM和SDRAM的差别。你发现使用片内SRAM的性能只提高了3%。这可能是因为片内SRAM的访问速度与SDRAM相差不大，或者你的测试代码没有充分利用片内SRAM的优势。
2. 其他可能影响性能的因素：
除了LDR加载指令和内存访问速度之外，还有一些其他因素可能会影响STM32F7的性能：
a. 指令流水线：现代处理器通常采用指令流水线技术来提高执行效率。然而，当遇到流水线冲突（如数据冲突、控制冲突等）时，流水线的效率会降低。你的测试代码可能存在一些流水线冲突，导致实际性能低于理论性能。
b. 指令混合：你的测试代码中包含了不同类型的指令，这可能会导致处理器的指令调度器无法充分利用指令并行性，从而降低性能。
c. 编译器优化：编译器在将高级语言代码转换为汇编代码时，可能会进行一些优化。这些优化可能会影响最终的汇编代码和性能。你可以尝试使用不同的编译器选项来观察性能的变化。
d. 系统时钟：STM32F7的性能与系统时钟密切相关。确保你的系统时钟设置正确，以充分利用处理器的性能。
为了进一步提高STM32F7的性能，你可以尝试以下方法：
1. 优化汇编代码：检查你的汇编代码，看看是否有优化的空间，如减少流水线冲突、提高指令并行性等。
2. 使用更高效的数据结构和算法：选择更适合STM32F7的数据处理方式，如使用寄存器数组而不是内存数组，以减少内存访问延迟。
3. 调整编译器选项：尝试使用不同的编译器选项，如开启或关闭某些优化，以找到最佳的性能平衡点。
4. 调整系统时钟：确保你的系统时钟设置正确，以充分利用处理器的性能。
5. 使用硬件加速器：如果STM32F7提供了硬件加速器（如DMA、FPU等），尝试使用这些硬件加速器来提高性能。
通过以上分析和建议，希望能帮助你找到提高STM32F7性能的方法。
举报
