On Tue, Jun 29, 1999 at 12:38:54PM -0700, Lawson English wrote:

> I said:
>
> [refinements to my idea include]
>
> >1) a set of quick and dirty primitives that can be called as standalones;
> >2) a full-blown (more or less) AltiVec simulator that uses a single set of
> >32 "registers" that are accessed by index, rather than by providing a
> >Smalltalk byteArray every time you use it.


> Further refinements to my pixel-handling primitives idea:
>
> In addtion to the 128-bit AltiVec simulation/primitives, it would be useful
> to implement:
>
> A set of quick and dirty AlitiVec-like primitives that only operate on
> single pixes at the various standard screen depths -32, 16, 8.
>
> A full-blown single-pixel equivalent of the Altivec simulator that would
> allow one to manipulate a single pixel's color channels
> one-pixel-at-a-time.
>
> E.g., C-based methods to separate color channels into 16 or 32-bit values,
> and manipulate them simultaneously or separately, as well as methods to
> convert them back to 8/5/whatever bits per channel and repack them into a
> single pixel.
>
> The idea is to create a bunch of primitives that can manipulate pixels
> efficiently for color-handling, as well as to speedup  DSP-like operations.
> The simulator (32 or 128-bit) would store intermediate values in virtual
> registers so that no conversion or other data-related overhead would be
> incurred until you needed to manipulate the data using standard SmallTalk.
>
> The 128-byte simulator/primitives would be suitable for long streams of
> pixels or other data. The 32-bit simulator/primitives would be suitable for
> short segments of data (or for handling edge conditions in a long stream in
> a machine that has an AltiVec-like device handy).
>
> For MMX, perhaps an intermediate 64-bit version could be implemented as
> well, or facilities created to handle 64-bit segments from within the
> 128-bit version?
>
> Comments? Criticisms? I haven't benchmarked any of this, but my intutition
> says that the time-savings from doing this could be quite good, especially
> during the prototyping phase of pixel/DSP algorithms.


Disclaimer: I haven't been keeping up with this list or this thread in
particular, so I may be re-itterating things that have already been
hashed out or just generally making clueless statements.  If that's
the case, sorry.


However, as my day job involves writing and maintaining development
tools for a SIMD DSP, I have some experience with the technology and
the related philosophy.

The basic idea behind vector processing is to do more in one clock
cycle.  As such, my particular DSP will do 4 or 8  arithmetic
operations on a swath of data in one cycle and calculate the next
address at the same time.  The ideal construct for using this kind of
thing is a big linear sequence of instructions--an unrolled tight
loop, as it were.  This give you a 4- or 8-fold increase in
performance over a scalar processor and allows realtime video
manipulation at 25MHz.

Note that you only get a significant performance boost because you're
doing an enormous number of successive basic arithmetic operations.
That is, almost every clock cycle is used to do arithmetic rather than
flow control or other housekeeping.

In contrast, executing a Squeak expression like:

        ByteArray doBy128Bits: [ :chunk | chunk someDSPOperation ]

involves several hundred (at least) clock cycles in between each piece
of arithmetic done.  The performance gained by doing 4 or 8 or 16
bytes' worth in one clock cycle rather than {4,8,16} isn't a
significant gain because the arithmetic itself doesn't use that many
clock cycles compared to the Squeak VM.

Adding extended bit-manipulation primitives to Squeak may well be a
good idea (I haven't needed them so I don't have an informed opinion
here) but you may as well go and code them in efficient C--vector
processing won't help enough.

I _can_ think of several places where vector instructions might
improve performance:  BitBLT could probably benefit from AltiVec or
MMX-based replacements for a few of the workhorse primitives.
ByteArray, FloatArray and IntArray might also benefit from
vector-based "Do-this-to-all-elements"-type primitives.  Maybe
you can think of a few others.

In any case, if you do add such primitives, please make sure that
there are portable alternates for all of them.



                                --Chris