Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Payload buffer alignment in C/C++ clients

Hi Frank,

It's an interesting point, but I'm not sure whether we necessarily
need to do anything. After some searching on various malloc
implementations I've found:

glibc guarantees 8 bytes alignment on 32-bit machines and 16 bytes on 64-bit
uclibc uses the larger of __alignof__(double) and sizeof(size_t)
Visual Studio aligns to a double (8 bytes or 16 bytes)
FreeBSD libc aligns suitable for use by any object

Cheers,

Roger


On Fri, Jan 23, 2015 at 3:07 PM, Frank Pagliughi
<fpagliughi@xxxxxxxxxxxxxx> wrote:
> Hey All,
>
> Here's a strange one.  In the C/C+ clients, can we (or should we) make an
> alignment guarantee on the incoming payload buffers for an application?
>
> I know that the payloads are supposed to just be binary byte blobs, so a
> byte alignment is all that is to be expected. But with a modest alignment
> guarantee, a subscriber can make use of the payload buffer directly rather
> than incurring a copy penalty on each incoming buffer.
>
> For example, say that an app is publishing a native array of 32-bit int's:
>
> int32_t arr[N];
> ...
> MQTTClient_publish(cli, topicStr, (int) (N*sizeof(int32_t)), arr, ...);
>
> Assuming that the receiver has verified that it is using the same byte
> ordering, it could do this:
>
> int msg_arrvd(void *context, char *topicName, int topicLen,
> MQTTClient_message *msg)
> {
>     size_t i, n = msg->payloadlen / sizeof(int32_t)
>     const int* arr = (const int*) msg->payload;
>
>     for(i=0; i<n; ++i)
>         do_something_with_int(*arr++);
>
>     // ...
>     return 1;
> }
>
> This will work on many platforms, including a PC, but if the incoming
> payload buffer does not have at least 4-byte alignment, it would cause a
> severe performance penalty, and some CPU's like an ARM will generate
> alignment faults.
>
> So maybe the libraries could make some guarantee about alignment for the
> payload buffers? Aligned to the native word size? Or the native "long" size?
> Or to a 4, 8, 16, 256 byte boundary, etc?
>
> Just a thought.
>
> Thanks,
> Frank
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev


Back to the top