从字节缓冲区转换结构 [英] Cast struct from byte buffer

查看:43
本文介绍了从字节缓冲区转换结构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用 castpack 从二进制 byte buffer 读取 struct.我试图从内存缓冲区中跟踪最坏情况下的读取时间,因此我决定保留一个 chrono 高分辨率时钟 nano 计时器.每当计时器增加时,我都会打印该值.它给了我一个大约 20 微秒的最坏情况,考虑到结构的大小,这是巨大的.当我测量平均花费的时间时,结果大约是 20 纳秒.然后我测量了我突破 50 的次数.结果是在大约 2000 万次中,我仅突破了 50 纳秒 500 次.

I am trying to read a struct from a binary byte buffer using cast and pack. I was trying to keep track of worst case read time from in memory buffer so I decided to keep a chrono high resolution clock nano timer. Whenever the timer increased I printed the value. It gave me a worst case scenario of about 20 micro seconds which was huge considering the size of the struct. When I measured the average time taken it came out to be ~20 nanoseconds. Then I measured how many times was I breaching 50. And it turns out of the ~20 million times, I was breaching 50 nanoseconds only 500 times.

我的问题是什么可能导致这种性能波动:平均值为 20,最差为 20,000?

My question is what can possibly cause this performance fluctuation: average of 20 and worst of 20,000?

其次,我如何确保恒定的时间性能.我正在使用 -O3 和 C++11 进行编译.

Secondly, how can I ensure a constant time performance. I am compiling with -O3 and C++11.

 // new approach
 #pragma pack(push, 1)
 typedef struct {
    char a;
    long b, c;
    char d, name[10];
    int e , f;
    char g, h;
    int h, i;
} myStruct;
#pragma pack(pop)


//in function where i am using it


 auto am1 = chrono::high_resolution_clock::now();
 myStruct* tmp = (myStruct*)cTemp;
 tmp->name[10] = 0;
 auto am2 = chrono::high_resolution_clock::now();
 chrono::duration<long, nano> arM = chrono::duration_cast<chrono::nanoseconds>(am2 - am1);
 if(arM.count() > maxMPO.count())
 {
     cout << "myStruct read time increased: "  << arM.count() <<     "\n";
 maxMPO = arM;
 }

我使用 g++4.8 和 C++11 和一个 ubuntu 服务器.

I am using g++4.8 with C++11 and an ubuntu server.

推荐答案

什么可能导致这种性能波动:平均为 20 和最差的 20,000 个?

what can possibly cause this performance fluctuation: avg of 20 and worst of 20,000?

在 PC(或 Mac,或任何台式机)上,存在以太网中断、计时器、内存刷新以及许多其他您无法(或几乎无法控制)控制的事情.

On a PC (or Mac, or any desktop), there are Ethernet interrupts, timers, mem-refresh, and dozens of other things going on over which you have no (or very little) control.

您可以考虑更改目标.如果您使用只有静态内存的单板计算机 (SBC)、可以关闭和断开连接的网络连接、计时器和时钟以及软件控制下的所有其他类型的中断,您可能会获得可接受的结果.

You might consider changing the target. If you use a single board computer (SBC) with only static ram, and a network connection which you can turn off and disconnect, and timers and clocks and every other kind of interrupt under your software control, you might achieve an acceptable result.

我曾经与一位为 8085 SBC 编写软件的女孩共事.当我们接上示波器,看到软件控制位的波形稳定性时,我想她一定是加了逻辑芯片.这是惊人的.

I once worked with a gal who wrote software for an 8085 SBC. When we hooked up a scope and saw the waveform stability of a software controlled bit, I thought she must have added logic chips. It was amazing.

您根本无法在桌面上实现无抖动"行为.

You simply can not achieve 'jitter' free behaviour on a desktop.

这篇关于从字节缓冲区转换结构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆