FWIW: The bigger picture... Or why I have been asking a lot of questions lately...
Jim Kuzdrall
gnhlug at intrel.com
Tue Oct 13 08:13:12 EDT 2009
Greetings Bruce,
Still thinking about your problem...
On Sunday 11 October 2009 17:01, Bruce Labitt wrote:
> I did do an experiment that had curious results. Instead of sending
> double precision binary data, I sent single precision or 'float'. I
> was expecting to halve my transmission time, since it is half the
> size. Instead, there was only a 10-15% speed increase, not a 100%.
> This result is telling me something, although at this time, I'm too
> brain dead to really ascertain what it really means.
The "float" option should work to get you a factor of two.
First, make certain that "float" is 4 bytes for your compiler by
printing out "sizeof(float)" from a compiled program. The C Standard
defines float as having a range of 10^+38 to 10^-38 and at least 6
decimal digits precision, but that leaves the door open to use doubles
for floats in the compiler.
More significantly, C promotes floats to doubles when it passes them
to a function. I am guessing that is what happened.
Assuming you have the data in a float array, cast the array to an
array of 4 byte character arrays. Send it as if it were characters
rather than the numeric values. The receiving end should not care what
the bytes represent. When the array is retrieved as characters, cast
it back to the floats. Since it is the same compiler, byte order
should not cause a problem.
As a second enhancement, try sending the number pairs as they are
generated, rather than waiting for them all to complete. The
relatively slow communication hardware has its own formatter and shift
register - and most likely a FIFO. It will take care of issuing the
bits while the processor does other things - like computing FFts.
To make this work, you might divide the FFT computation into 16
parts. Start sending the first part as soon as it is completed.
If both of these things worked, you would be 4X faster. Better than
standing pat.
Jim Kuzdrall
More information about the gnhlug-discuss
mailing list