At 03:05 PM 4/27/2000, Eric Scheirer wrote:
>Sampo wrote:
>
> >What makes me worry is the abundance of
> >data types and the strength of computation needed to implement quality
>lossy
> >compression. I'm not sure anything but handcoded assembler or C will do for
> >a realtime architecture.
>
>I continue to argue (although of course I have no empirical proof
>yet) that compiled SAOL for accelerated architectures will be
>faster than compiled C, and at least competitive with hand-coded
>assembler, on equivalent algorithms. Particularly for DSP
>architectures, a SAOL program embodies the assumptions made by
>the hardware much more effectively than does a C program,
>and the fundamental processing units of SAOL (delay lines,
>signals, table read/writes) are exactly those that map most
>effectively onto a DSP implementation. Because of this, it
>will be easier to write very effective optimizing compilers
>for SAOL->DSP than is C->DSP and especially C++->DSP.
>
>I wonder if some of the folks (John, Giorgio) that have been
The comment on my side is that I can say the whole SAINT concept
and project is built around this idea. We focus especially on DSP
applications on DSP or Multimedia processor platforms, where a
compiling process is carried on in a general purpose CPU, but the
execution engine is conceived for superscalar optimizations. In
particular I personally view the scheduler as an M-DSP (master
DSP) that executes an "hardwired" program, while instruments
(and instances) turn on one or more vDSP (virtual DSP) that, once optimized
in its instruction set, can provide great speedup even over a not-so-bad
c code. Meaningful results in this sense will be presented in a few
weeks at ISCAS 2000. Two faints points in all this are a very large
amount of k instructions (since saint is interpreted) and a heavy use
of the fracdelay opcode, for which I am still not able to find a sistematic
parallelization strategy.
For common DSP applications I am pretty sure that a good SA decoder
will run fast, even if "partially" interpreted. Consider in fact (or so it seems
to me right now), that the more you generate static macroblocks of code
the more you move the interpreter towards a mixed interpreted/compiled
solution, and conversely, the more you introduce real-time "exposed fields"
in an application, as in true MPEG-4, the more you move a compiled code
towards an interpreted control. Opinion from sw experts ?
Best regards,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:39 EST