Ben,
> Using the union appeared to work well ( and I'm primarily interested here as
> I want to introduce a variable size by copy message for my queue which a
> union makes easier)
Yes. I was thinking of introducing the union myself. The problem is that
changing the zmq_msg_t layout would break some of the language bindings,
so it has to be done carefully...
> The pack(1) was interesting and had a greater cost than I expected , that
> being said it made messages smaller which provided a benefit to the smaller
> ref based tests.
At the level of optimisation going on here there are no magic solutions.
The structure of zmq_msg_t has to crafted by hand to get the best
performance.
> A better option may be to just use a int for a flags and size field .. use
> the first 8 bits for size and just cast it to a byte from an int the flags
> can work on the higher bits. Alternatively you can make the size 24 bits and
> flags 8 bits removing the need for a separate size field in the ref based
> message ( unless anyone can see a reason for > 24 bit messages?).
>
> You then have small messages up to size 28 and still fit in 32 bytes ( even
> on 64 bit machines) , may try that now and force 16 byte alignment..
I though of something like this:
struct zmq_msg_t
{
union {
void *ptr;
struct {
...
} vsm;
} content;
unsigned char type;
unsigned char flags;
}
In theory, it would make VSM messages smaller (no content pointer).
However, in practice, you'll get 6 bytes (x86_64) of padding following
the structure -- because of compiler aligning it to CPU word boundary.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
