FWIW: The bigger picture... Or why I have been asking a lot of questions lately...

bruce.labitt at autoliv.com bruce.labitt at autoliv.com
Tue Oct 13 10:54:50 EDT 2009


gnhlug-discuss-bounces at mail.gnhlug.org wrote on 10/13/2009 08:13:12 AM:

> Greetings Bruce,
> 
>     Still thinking about your problem...

Well, thank you for that!

> 
> 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.

I would agree...  It really makes me think that, either there is an 
unknown bottleneck in the client, or a misconfiguration of the socket, or 
the OS,... or more likely some combination of all of the above...

> 
>     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.
> 

printf tells me sizeof(float) = 4 for both client and server

>     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.
> 

Data is converted to string prior to transmit.  This is an area for 
improvement.  However, the timing numbers I've indicated 'should' be just 
the transmission of the string buffer.

As for 'the same compiler', well, It is gcc on both, but to make things 
more fun, the client is little endian, and the server is big endian.  So 
byte order does matter. 

>     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.
> 

I will see if I can do something here.  As it stands, the FFTs are broken 
up...  For one calculation I need to do 80-100 FFTs.  Hence my desire for 
reducing any of the large time consuming processes.

>     If both of these things worked, you would be 4X faster.  Better than 

> standing pat.

Much better than standing pat!

> 
> Jim Kuzdrall

Thanks for thinking about this,
Bruce


******************************
Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail.  Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
******************************



More information about the gnhlug-discuss mailing list