Use DSP for heavy floating-point calculation

Hi All,

I'm writing a program for stock trading simulation to verify something.
But it will take 400 days for a simulation in my notebook (Centrino
1.6G).
Big part of my program is floating point calculation/compare.
My idea is transfer the loading to DSP but I'm not sure this idea is
OK.

Thanks for your suggestion.

Jack

Jack Huang wrote:

> Hi All,
> 
> I'm writing a program for stock trading simulation to verify something.
> But it will take 400 days for a simulation in my notebook (Centrino
> 1.6G).
> Big part of my program is floating point calculation/compare.
> My idea is transfer the loading to DSP but I'm not sure this idea is
> OK.
> 

You'd be much better of looking at exploiting a SIMD extension such as 
SSE on x86 or PowerPC on AltiVec.

Paul

Paul Russell wrote:
> Jack Huang wrote:
>
> > Hi All,
> >
> > I'm writing a program for stock trading simulation to verify something.
> > But it will take 400 days for a simulation in my notebook (Centrino
> > 1.6G).

What is the simulation envirionment? Matlab / Scilab / Octave / R / S
or the like? If so, then you'll get substantial speedup if you write a
compiled program in C/C++.

> > Big part of my program is floating point calculation/compare.
> > My idea is transfer the loading to DSP but I'm not sure this idea is
> > OK.

If you need double precision (depends on what you are doing in your
simulation), then DSPs are not the solution. What type of computations
are used in the simulations? FFTs? IIR/FIR filtering? Dot products?

> >
>
> You'd be much better of looking at exploiting a SIMD extension such as
> SSE on x86 or PowerPC on AltiVec.

This will at best reduce the simulation time to 200 days :-).

Regards,
Andor

Jack Huang wrote:
> Hi All,
>
> I'm writing a program for stock trading simulation to verify something.
> But it will take 400 days for a simulation in my notebook (Centrino
> 1.6G).
> Big part of my program is floating point calculation/compare.
> My idea is transfer the loading to DSP but I'm not sure this idea is
> OK.

I don't know if there is anything to be gained by using the DSP, but
I discovered notebooks by default run on half the max CPU frequency.
There is an option under the "power adminstration"(?) tab in the
control panel under windows, you can switch to let the CPU run at
full speed. If you haven't flicked that switch already, you can save
200 days...

Seriously, for a program on that sort of scale, I would look very
carefully
into programming languages (C/C++, maybe even assembly), maths
libraries tailor-made for whatever HW/OS combo you are using, and
maybe most importantly, parallelization.

If your simulation can be parallelized (not all simulations can) then
get access to, say, a large linux cluster and run your simulation
there. 

Rune

Dear All,

Single precision.
Not FFT/IIr/FIR, only simple multiply/add/compare.
Sorry, I use VB........that's easier for others reading.
OK, I'm porting it to C.

AI know, DSP is strong in ALU (that's what I want) and weak in other
functions.
Use Harvard architecture.
But all of this is memory 10 years ago.
I don't familiar in DSP field, but I need a lot of arithematic
calculation power now.
After searching internet, I found TI has a starter kit and cheap enough
that I can afford it.
So, I guess if I can porting my program to DSP, and use more then 1 DSP
starter kit, then I can reduce my simulation time.

Am I right? or wrong?

Sorry for my bad English and thanks for your fast response.

Jack

Dear Rune,

Yes, it runs at full speed.
and yes, I'm thinking about that (use BOINC.....and not setup
successfully yet. Fighting.......)
Anyway, I don't have much resource to run this simulation, and I found
TI's 6711 starter kit is cheap enough that I can buy some to run this
program.
I hope so.

Thanks.

Jack

"Jack Huang" <rhuang@ms2.hinet.net> writes:

> Dear Rune,
>
> Yes, it runs at full speed.
> and yes, I'm thinking about that (use BOINC.....and not setup
> successfully yet. Fighting.......)
> Anyway, I don't have much resource to run this simulation, and I found
> TI's 6711 starter kit is cheap enough that I can buy some to run this
> program.
> I hope so.

I would port it to C first and see how it runs on your notebook before
spending the money on a development kit, since in either case you need
to port it to C. The C implementation could be significantly faster than
VB.
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

Randy Yates wrote:
> "Jack Huang" <rhuang@ms2.hinet.net> writes:
>
> > Dear Rune,
> >
> > Yes, it runs at full speed.
> > and yes, I'm thinking about that (use BOINC.....and not setup
> > successfully yet. Fighting.......)
> > Anyway, I don't have much resource to run this simulation, and I found
> > TI's 6711 starter kit is cheap enough that I can buy some to run this
> > program.
> > I hope so.
>
> I would port it to C first and see how it runs on your notebook before
> spending the money on a development kit, since in either case you need
> to port it to C. The C implementation could be significantly faster than
> VB.

Definitely. My guess is that the algorithm runs faster on the 1.6GHz
notebook than on the 150MHz DSP card, once it is coded in C (as there
are no fast dot-products required by Jack's algorithm, which could
bring the DSP up to speed with the notebook CPU).

Regards,
Andor

Andor wrote:
> Randy Yates wrote:
> 
>>"Jack Huang" <rhuang@ms2.hinet.net> writes:
>>
>>
>>>Dear Rune,
>>>
>>>Yes, it runs at full speed.
>>>and yes, I'm thinking about that (use BOINC.....and not setup
>>>successfully yet. Fighting.......)
>>>Anyway, I don't have much resource to run this simulation, and I found
>>>TI's 6711 starter kit is cheap enough that I can buy some to run this
>>>program.
>>>I hope so.
>>
>>I would port it to C first and see how it runs on your notebook before
>>spending the money on a development kit, since in either case you need
>>to port it to C. The C implementation could be significantly faster than
>>VB.
> 
> 
> Definitely. My guess is that the algorithm runs faster on the 1.6GHz
> notebook than on the 150MHz DSP card, once it is coded in C (as there
> are no fast dot-products required by Jack's algorithm, which could
> bring the DSP up to speed with the notebook CPU).

So you think he needs to get in touch with his inner product? :-)

Steve

"Randy Yates" <yates@ieee.org> wrote in message
news:oe2q4x3t.fsf@ieee.org...
> "Jack Huang" <rhuang@ms2.hinet.net> writes:
>
> I would port it to C first and see how it runs on your notebook before
> spending the money on a development kit, since in either case you need
> to port it to C. The C implementation could be significantly faster than
> VB.

FWIW for grins I did a quick test of a loop on my trusty 700MHz laptop with
each iteration including an int to double prec conversion, a double
precision multiply, and a double precision add in VB and VC:

VB 6 Dbg 2.8m iterations/sec
VB 6 Exe 4.3m iterations/sec
VC 6 Dbg 77m iterations/sec
VC 6 Rel 140m iterations/sec

So, C can be up to 50 times faster than VB for this test.

VB:

Private Sub Command1_Click()
    Dim t
    Dim l As Long

    t = Time

    Sum = 0

    For l = 1 To 10000000
        g = l * 3.123
        Sum = Sum + g
    Next l
    Label1.Caption = Time - t

End Sub

VC:

#include <math.h>

void main(void)
{
 double dSum=0.0;
 int n;

 for (n=0;n<1000000000;n++)
 {
  dSum+=n*3.123;
 }
}

Cheers, Howard