模型资源加载引起的内存对齐问题

最新推荐文章于 2023-12-11 17:39:10 发布
原创 最新推荐文章于 2023-12-11 17:39:10 发布 · 1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Android #gcc #c语言 #语音识别 #人工智能

最近需要给远场降噪库编译到android 平台上运行，其中库加载了模型资源文件，考虑到库的通用性，给模型资源文件转成了c的头文件里的数组形式，这样就不需要读取文件了，如下

![(https://img-blog.csdnimg.cn/5803ec967d8b458e8749e66ff804e0fb.png)

编译后在机器上运行64位版本ok，一切正常，但编译32位版本时遇到bus error

在这里插入图片描述

总线错误？没干啥啊，给32位编译FLAGS 同步成64位后无效，Bus error继续。
查了下总的来说android 报bus error 基本是访问了未对齐内存导致，比如
0x0x5594bb4a7f 这个地址%4不等于0，说明地址不是4字节对齐。如果用int * 去取数据就会报错，但
用char* 取数据就ok。为啥64位的正常呢，打印了64位的数据也是不对齐的，为啥64位就ok呢，猜测是64位支持内存不对齐的访问。

用工具排查错误是在下面这行，那看来就是f32有问题了

在这里插入图片描述
看下f32 是个float * 地址，那应该需要4字节对齐
在这里插入图片描述
我们打印下f32的值0x0x5594bb4a7f 果然不是4字节对齐的
怎么办呢，
尝试了下memcpy处理，重新定义一个float 数组，编译器会确保iweightAll 是对齐4字节的，memcpy又可以按字节访问f32

在这里插入图片描述

再来打印iweightAll 果然ok了，但又有其他地方报错了，。。。看来这种方式治标不治本，的确可以解决问题，但需要在所有不对齐的地方使用，同时增加了memcpy的开销

看一下为什么f32是单字节，能否设置4字节对齐

在这里插入图片描述
一顿操作发现，f32是用模型资源取出来的char*赋值的。。。我去，那这肯定很难保证是4字节对齐啊

于是想到新的一招

在这里插入图片描述
重新申请个4的倍数的内存，这样会确保ptr 起始地址是4字节对齐的，给原来的值拷贝进去，ok
搞定了

想想还是有问题啊，这样内存变大了啊
到底是啥原因导致ptr不能4字节对齐呢，能否有办法搞定呢
原先以为是模型解析的时候，模型里的数据类型不确定，可能是void* 也可能是float*等等，导致赋值的时候有问题，可后来想想模型的制定应该没这么蠢吧，so继续追踪下去，打印所有解析的模型资源数据，发现都是4字节倍数，那这很明显了啊，只要模型资源起始地址对齐的，那我们需要解析的数据肯定都是对齐的，打印了下模型资源地址果然是像0x0x5594bb4a7f 这样的，对，就是不对齐，为啥呢，再看下模型资源
在这里插入图片描述
资源的里的数组大小不是4倍数啊。。。打印这个地址果然出来的地址也不是对齐4的（也是有可能对齐的），那对于这种直接定义的数组数据怎么让起始地址对齐呢，想到个简单的解决方法，那就是再扩充几个字节（注意资源长度还是原来的）

在这里插入图片描述
再次打印资源地址，ok了，重新编译代码运行，搞定

Unity3d IL2CPP 内存对齐错误
阿毛
04-13 4239
layout: post title: Unity3d IL2CPP 内存对齐错误 key: 201904131333 tags: unity 文章目录layout: post title: Unity3d IL2CPP 内存对齐错误 key: 201904131333 tags: unity unity3d il2cpp安卓包运行异常，出现信号错误signal 7 (SIGBUS), code...
关于memcpy函数安全性的一些讨论
Solititude的博客
11-29 2316
关于memcpy函数安全性的一些讨论
int在32位机器中所占的内存大小引发的问题【转】
IT_admin的博客
11-04 2002
今天看到一个资料，看到里面讲到int在32位机器中占的是四个字节的内存，我脑海里面感觉这个好像不对，然后在网上查了下资料，发现int类型的数据在32位机器中的确占的内存是4个字节，现在对一些数据结构在内存中所占的字节数总结下。 1： char a: sizeof(a) = 1; 2： int a : sizeof(a) = 4; 3: short a: sizeof(a) = 2; ...
stm32 memcpy 错位问题
nickatcsdn的博客
12-19 1836
是由于结构体没有的对齐标准未指定； 关于 #param pack n:　#pragma pack(4) 　　class TestB 　　{ 　　public: 　　　　int aa; 　　　　char a; 　　　　short b; 　　　　char c; 　　}; 　　int nSize = sizeof(TestB); 　　这里nSize结果为12，在预料之中。 　　现在
调试经验－－字节对齐
lintax的专栏
12-06 1470
调试经验－－字节对齐 在使用C语言开发时，有时会遇到内存中数据对齐的问题，如果对齐问题没有判断正确，很可能导致结果完全异于预期。 我们在调试程序时，在数据对齐方面遇到一些问题，也做了一些总结： 1，C语言默认对齐方式； 2，C语言强制指定对齐方式； 3，指针数据类型转换； 4，一个字节对齐问题的例子。
ARM程序由于字节对齐引起的问题深入分析
Graylag
09-19 729
<br /> 首先说说，什么叫对齐。如果一个数据是从偶地址开始的连续存储，那么它就是半字对齐，否则就是非半字对齐；半字对齐的特征是bit0=0,其他位 为任意值。字对齐的特征是bit1=0,bit0=1,其他位为任意值。如果一个数据是以能被4 整除的地址开始的连续存储，那么它就是字对齐，否则就是非字对齐。举例说明四字节对齐： 对内存进行操作时，被访问的地址必须为4的倍数。如果分配到的地址的地址不是4的倍数时，CPU实际访问的地址还是按照字对齐的方式来操作。也就是自动屏 蔽bit1和bit0.  
深入理解C语言内存模型：【内存对齐】背后的memcpy机制
![深入理解C语言内存模型：【内存对齐...在应用实践部分，本文讨论了结构体设计、动态内存分配中内存对齐的应用，以及在并发编程中内存模型对程序性能的影响和内存对齐的特殊考虑。最后，本文提出了基于内存模型的优化
DMA+ADC连续采样丢数据？深入ESP32底层DMA通道配置与内存对齐问题
根本原因往往并非ADC硬件缺陷，而是DMA传输链路中的**缓冲区溢出、内存对齐违规或中断延迟过长**所致。通过分析实际采集波形与DMA描述符状态，可发现数据断层多发生在缓冲区切换边界，提示DMA与ADC同步机制存在时序...
内存对齐的艺术：C语言指针与内存对齐实战解析
内存对齐是指在计算机内存访问中，数据的存储地址需要符合特定的对齐规则。这一概念对于保证系统的高效访问和运行至关重要。理解内存对齐的基础概念，对于编写高性能代码以及避免某些难以发现的错误至关重要。在现代...
DMA内存对齐问题引发I2C异常案例复盘：边界处理不当导致的致命传输错误
DMA允许外设直接与内存交换数据，而I2C作为半双工串行通信协议，常用于连接低速传感器与主控芯片。当二者结合时，DMA负责自动搬运I2C接收到的数据或待发送的缓冲区内容，实现零CPU干预的连续传输。 ```c // 示例：...
C_C++内存对齐的艺术
![C_C++内存对齐的艺术]...最后，本文关注内存对齐的调试与问题解决，并对内存对齐在新一代编译器、跨平台编程及新兴技术中的未来趋
C语言字节对齐问题详解
weixin_34367845的博客
07-18 1392
    引言      考虑下面的结构体定义： 1 typedef struct{ 2 char c1; 3 short s; 4 char c2; 5 int i; 6 }T_FOO;      假设这个结构体的成员在内存中是紧凑排列的，且c1的起始地址是0，则s的地址就是1，c2的地址是3，i的地址是4。      现在，...
一文搞懂系列——字节对齐的前因后果及应用
点滴路程
12-11 1200
通过同事偶然间遇到的一个问题，深入剖析，了解到字节对齐前因后果。也给我们警示结构体定义需要满足编译器的规则，否则可能会大量浪费内存空间。在跨平台开发过程中，我们也要考虑结构体成员long数据类型在不同平台的变化。当然也有可能会因为编译器的不同，其它基础数据的自身对齐值，也会发生变化。定义结构体成员变量时，考虑跨平台的情况。对外提供的头文件，可以通过强制设置自身对齐值。若我的内容对您有所帮助，还请关注我的公众号。不定期分享干活,剖析案例，也可以一起讨论分享。
惊天BUG-字节对齐再思考-总结
GKoSon的博客
09-02 291
总结：前面字节序有2个办法 1我自己PACK 但是速度不好 2TOUCH这样的混到数组里面 3有没有好主意？看下面 这个时候我也遇到了 可以1for=0 2如下 找一个中间的 3哈哈期待下 //像个办法优化一下 void GK_usart_clear(GK_USARTBASE_TYPE *myuart) { uint32_t temRXaddress = (uint32_t)m...
memcpy函数与结构体对齐
Ztt19990421的博客
07-09 2035
memcpy函数与结构体对齐
结构体字节对齐引起的悲伤----数据跨越丢失或出错
浮若于心
08-19 1316
对大家的建议就是当对结构体进行连续地址数据赋值时不要轻易直接赋值。 比如： 1、直接从Flash中读取数据，直接用结构体去存。 2、使用memcpy的函数直接整段数据丢进结构体。 3、使用指针指向结构体后面进行取值调用。 这几个问题都可能因为字节对齐的关系导致最后取得数据有问题。
内存拷贝和对齐读取
linux_vae的专栏
09-12 1606
一 memcpy的思考在很多的网络开发中，经常会碰到一些内存转换，如下面的场景： #define PACKAGE_PARSE_ERROR -1 #define PACKAGE_PARSE_OK 0 int parse_package( int* a, int* b, int* c, int* d, char* buf, int buf_len ) { if( !buf
遭遇内存对齐问题
Foru
09-03 2847
先说理论的：为何要内存对齐？ 1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。 2、 性能原因：经过内存对齐后，CPU的内存访问速度大大提升。 图一： 这是
字节对齐与内存访问
tietao的专栏
02-05 7922
关于字节对齐，最早是在《高质量程序设计》中看到的，当时明白一点，就是因为定义的数据字节大小不一（1字节，2字节，4字节，8字节），在内存中可能会有字节对齐的操作，就是数据在内存中的排放，不一定是连续的。因此也产生了一个疑问，就是对于数组而言，特别是结构体，如果不连续排放了。那么，当我们将结构体，当做连续的一段内存来访问时， 是不是会造成错误呢？ 当时，虽然有疑惑，但是一直没有特别明白的
同一个模型文件用CPU和GPU加载后模型大小不一样
最新发布
07-03
<think>首先，用户的问题是关于同一个深度学习模型文件在使用CPU和GPU加载时显示的模型大小不同。用户想知道原因和解决方案。 用户提供的引用包括：-引用[1]:讨论了C++调用Python深度学习模型、GPU内存释放等问题。 -引用[2]:提到GPU和CPU模型加载参数类型不同，不能直接调用。-引用[3]:关于深度学习模型在FPGA上的加速。-引用[4]:解释了torch.load()函数，如何在CPU上加载GPU保存的模型，使用map_location参数。用户意图是理解为什么同一个模型文件在加载到CPU和GPU时大小不同，并找到解决方法。 现在，我需要构建一个结构清晰的回答，使用中文，并遵循系统指令： -所有行内数学表达式用$...$格式。-独立公式用$$...$$格式并单独成段。- LaTeX语法正确。-生成相关问题。 -回答中引用的段落末尾添加引用标识。回答结构：1.**解释原因**：为什么模型在CPU和GPU加载时大小不同？-可能原因：模型参数在CPU和GPU上存储方式不同。GPU上使用半精度（如FP16）或混合精度训练，导致参数大小不同。或者，加载时涉及数据类型的转换。-引用相关部分：引用[2]提到GPU和CPU参数类型不同。引用[4]讨论加载模型时使用map_location。2.**提供解决方案**：-如何确保模型大小一致？例如，在加载时指定数据类型或使用map_location参数。-步骤：在PyTorch中，使用torch.load()时设置map_location=torch.device('cpu')或指定数据类型。3.**生成相关问题**：在回答末尾添加相关问题。关键点： -模型文件通常是相同的（.pth文件），但加载到不同设备时，参数在内存中的表示可能不同。- GPU上可能使用较小的数据类型（如float16 vsfloat32），导致内存占用不同。 -在PyTorch中，加载模型时可以通过map_location控制设备。基于引用[4]：torch.load()先在CPU上加载，但可以映射到GPU。如果模型在GPU上训练保存，在CPU加载时需map_location='cpu'。 原因解释： -当模型加载到GPU时，参数可能被转换为CUDA张量，占用更多或更少内存，取决于精度。 -例如，float32在CPU和GPU上大小相同（4字节），但如果使用float16，GPU上大小减半。解决方案：-在加载模型时，统一数据类型：使用torch.load()时指定map_location或转换数据类型。-例如：model.load_state_dict(torch.load('model.pth',map_location=torch.device('cpu')))-或者，在训练时保存模型为CPU格式。 生成相关问题：1.如何检查模型在不同设备上的参数大小？ 2.在PyTorch中，如何转换模型数据类型？ 3.深度学习模型在GPU和CPU上的性能差异？回答结构： -开头：简要介绍问题。 -原因部分：详细解释。 -解决方案部分：步骤清晰。 -结尾：生成相关问题。使用中文。</think>### 同一个深度学习模型文件在CPU和GPU加载时显示大小不同的原因及解决方案 在深度学习模型部署中，用户经常遇到同一个模型文件（如PyTorch的`.pth`文件）加载到CPU和GPU时显示的内存大小不同。这通常是由于模型参数在设备上的存储方式、数据类型转换或加载机制导致的。下面我将逐步解释原因并提供解决方案，确保回答真实可靠，基于PyTorch框架（因其在引用中高频出现）。 #### 原因分析 模型文件本身是相同的，但加载到不同设备后，参数在内存中的表示可能发生变化，导致显示大小差异。主要因素包括： 1. **参数数据类型不同**：GPU上常使用半精度（如float16）来优化内存和计算，而CPU默认使用单精度（float32）。例如，一个float32参数占用4字节，而float16仅占用2字节。加载到GPU时，如果模型自动转换为float16，内存占用会减小；反之，在CPU加载时保持float32，大小不变。数学上，参数大小可表示为$S = n \times d$，其中$n$是参数数量，$d$是数据类型字节大小。当$d$从4（float32）变为2（float16）时，$S$减半[^2]。 2. **设备映射机制**：PyTorch的`torch.load()`函数默认在CPU上加载模型文件，但会根据设备动态转换参数。如果模型在GPU上训练保存，加载到CPU时需显式指定`map_location`，否则参数可能被错误地映射到GPU张量，导致大小计算偏差[^4]。例如，GPU张量包含额外元数据（如CUDA上下文），而CPU张量更精简。 3. **内存对齐和优化**：GPU内存管理涉及缓存对齐和并行优化，可能增加额外开销。CPU加载则更直接，但缺乏这些优化。引用[3]提到，GPU加速会引入额外数据结构，影响内存占用。 4. **混合精度训练影响**：如果模型使用混合精度（如AMP）训练，保存的文件包含float16和float32参数。加载到GPU时，这些参数可能保持原样；加载到CPU时，PyTorch可能将所有参数提升为float32，导致大小增加[^2]。 #### 解决方案 要解决模型大小差异问题，关键是统一加载设备或数据类型。以下是具体步骤（以PyTorch为例）： 1. **在加载时指定设备映射**：使用`torch.load()`的`map_location`参数强制模型加载到指定设备，并确保数据类型一致。 ```python import torch # 加载模型到CPU，无论原设备如何 model = torch.load('model.pth', map_location=torch.device('cpu')) # 或加载到GPU，但统一为float32 model = torch.load('model.pth', map_location=torch.device('cuda')) model = model.float() # 转换为float32 ``` 这避免了动态转换引起的大小变化[^4]。 2. **保存模型时统一数据类型**：在训练或保存模型前，显式设置参数数据类型。 ```python # 保存模型为CPU格式和float32 model.to('cpu').float() torch.save(model.state_dict(), 'model_cpu.pth') # 保存模型为GPU格式和float16（如果需要） model.to('cuda').half() torch.save(model.state_dict(), 'model_gpu.pth') ``` 这样，加载时大小差异最小化。 3. **检查并转换参数**：加载后比较参数大小，手动转换。 ```python # 加载模型 state_dict = torch.load('model.pth', map_location='cpu') # 转换为统一数据类型 for key in state_dict: state_dict[key] = state_dict[key].float() # 强制为float32 model.load_state_dict(state_dict) ``` 4. **监控内存使用**：使用工具如`torch.cuda.memory_allocated()`或`psutil`验证实际内存占用，避免显示误差。例如： ```python # GPU内存占用 print(torch.cuda.memory_allocated() / 1024**2, "MB") # 单位MB ``` 如果问题由GPU内存不足引起（如引用[1]所述），确保加载前释放无用资源：`torch.cuda.empty_cache()`。 #### 注意事项 - **性能权衡**：统一为float32可能增加内存占用但提升精度；float16减小大小但可能损失精度。根据应用场景选择。 - **框架差异**：在TensorFlow中，类似机制如`tf.device()`和`tf.cast()`可用。 - **引用验证**：上述方案基于PyTorch文档和引用[4]，实际效果需测试模型文件和环境。 通过以上方法，您可以消除大小差异，确保模型部署一致性。如果问题持续，检查模型文件是否损坏或框架版本兼容性。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值