4 Byte Padding

[Angelo Fraietta-2]

Why is the OSC messages and addresses padded to multiples of 4 Bytes

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page


http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
     Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

>Why is the OSC messages and addresses padded to multiples of 4 Bytes

For computational efficiency: data will be word aligned in memory of the sender and receiver this way. This means that a copy-free "pass by reference" is possible. This may seem irrelevant in occasional gesture messages but remember that OSC is used for moving multichannel audio and video streams and robot control sequences at Disneyland etc. The benefits are even observable in fast inner loops for oscillators and resonances controlled from OSC messages  ......

http://msdn2.microsoft.com/en-us/library/aa505951.aspx

alignment like this has been a common feature of data formats, e.g.:
http://www.martinreddy.net/gfx/2d/IFF.txt
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Angelo Fraietta-2]

Sos in these instances, the data is being stored in the original OSC
message packet similar to storing a struct as a char buffer? So instead
of typecasting each data parameter, you are just getting the pointer to it?

If so, what happens when you go to 64 bit machines?

Adrian Freed wrote:

>>Why is the OSC messages and addresses padded to multiples of 4 Bytes
>
>
> For computational efficiency: data will be word aligned in memory of the sender and receiver this way. This means that a copy-free "pass by reference" is possible. This may seem irrelevant in occasional gesture messages but remember that OSC is used for moving multichannel audio and video streams and robot control sequences at Disneyland etc. The benefits are even observable in fast inner loops for oscillators and resonances controlled from OSC messages  ......
>
> http://msdn2.microsoft.com/en-us/library/aa505951.aspx
>
> alignment like this has been a common feature of data formats, e.g.:
> http://www.martinreddy.net/gfx/2d/IFF.txt
> _______________________________________________
> OSC_dev mailing list
> OSC_dev@...
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>
>

--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page


http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
     Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

>Sos in these instances, the data is being stored in the original OSC
>message packet similar to storing a struct as a char buffer? So instead
>of typecasting each data parameter, you are just getting the pointer to it?

well typecasting involves no copies either. The key is not to move the data if you don't have to and not to realign at great cost to cache performance.

>
>If so, what happens when you go to 64 bit machines?

Yes, there are now architectures where there is a performance benefit to 64-bit alignment although it will be years before application and OS software catch up to the point where this is an important issue for OSC.
_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Angelo Fraietta-2]

Adrian Freed wrote:
>>Sos in these instances, the data is being stored in the original OSC
>>message packet similar to storing a struct as a char buffer? So instead
>>of typecasting each data parameter, you are just getting the pointer to it?
>
>
> well typecasting involves no copies either. The key is not to move the data if you don't have to and not to realign at great cost to cache performance.
>
Don't you move it out of the OSC buffer when you receive it as a packet?
  Or is it already optimised for a 32bit machine from the sender's end?


>
>>If so, what happens when you go to 64 bit machines?
>
>
> Yes, there are now architectures where there is a performance benefit to 64-bit alignment although it will be years before application and OS software catch up to the point where this is an important issue for OSC.

Is there a short code sample where I can see how you get the arguments
out if you are not just doing a typecast based upon the arguments.  I am
having difficulty seeing how you are doing it.


--
Dr Angelo Fraietta
A.Eng, A.Mus.A, BA(Hons), Ph.D.

PO Box 859
Hamilton NSW 2303

Home Page


http://www.smartcontroller.com.au/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
     Bernard of Clairvaux (1090 - 1153)

_______________________________________________
OSC_dev mailing list
OSC_dev@...
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev