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

[Jim Kuzdrall]

On Tuesday 13 October 2009 10:54, bruce.labitt at autoliv.com wrote:
> 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!
>

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

    If I can remember my C programming, you do something non-portable 
like:
...
/* number of pairs (initialize to the correct number) */
int npair=128;
/* the double does a boundary alignment */
union {
    double align;
    float  ansf[npair][2];
    char   ansc[npair*2*4]
    } answer;

/* check that they are the same size (this does not guarantee
   that they are aligned right; check the received data for that) */
printf("float array size is %d and text array size is %d\n",
        sizeof(answer.ansf), sizeof(answer.ansc));

cnt= fwrite( (char *)&answer.ansc, 4*2, npair, &output_dev);
printf("The count was %d and it should be %d",cnt,npair);
exit(0);
...

    Wow, C seems so unfamiliar after a few years away from it.  I hope 
that gives you the gist of what I am suggesting to try.  There may be a 
better choice of functions, but I thought a for-loop on fputc() would 
cost a lot more cpu cycles.

    To get this to work, you may have to get the FFT program and the I/O 
program to be separate processes - pipe or socket or something does 
that.

    Maybe somebody more experience will make a suggestion.

    I got the speed increase more optimistic than justified, but you can 
get about 4x by adding another data link.  Send the odd chunks to one 
and the even chunks to the other.

Jim Kuzdrall