[
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