[openbeos] Re: app_server: MMX/SSE help wanted

On 2004-08-08 14:19:19 [+0000], Adi Oanca wrote:

>     What about SSE, SSE2, SSE3? what can you tell us?
>     Knowing they use 128bit registers, do they deliver a 4x performance 
> gain over the CPU?

In some cases, probably. I wouldn't count on that being the general case, 
though. But even if it's only 2-3x, that's still a serious speedup which 
can be had for 'free'.

> These have support for floating point instructions isn't it?

All SSE instruction sets and 3DNow! offer this. Probably very useful for 
doing OP_ALPHA stuff, and all other cases where you want to mix MMX and FP 
operations. I can't judge how useful that will turn out, that really 
depends on the particular tasks to be performed.
 
>> I'm not really a SIMD pro, but I'll gladly help with whatever I know. 
>> And I already have a few suggestions about data alignment of bitmaps, 
>> which would help SIMD coders a lot in writing efficient code.
 
> Good, let's hear them. Before that: do you want to write some code 
> for Haiku project?

Absolutely. To do SIMD coding for a good purpose would make me very happy.


About data alignment issues (short version):

Most CPUs prefer if they can perform reads/writes on natural alignmnent 
borders, i.e. a boundary of 2 bytes for a word (int16), 4 bytes for double 
word (int32), 8 bytes for quad word (abstract MMX datatype), etc.

When doing unaligned accesses, it'll take the CPU some extra cycles to 
perform the read/write operations. As these delays happen very often when 
reading lots of data, this will incur a significant slowdown.
AFAIK the worst case is a P4 doing an access across a 16- or 64-byte 
boundary; Intels docs state a penalty of up to the pipeline depth. The P4s 
pipelines have a length of 20-30 stages (depending on P4 model), and if you 
run into a 20 or 30 cycle delay... that's very bad.
But even if you're 'only' loosing a few cycles during each mem access that 
can hurt performance quite badly. 

The problem with current BeOS is that it doesn't provide any kind of 
control over alignment when allocating bitmaps, they'll only be aligned to 
4-byte boundaries. In order to get optimum memory throughput, I have to 
write special code which reads 32bit values until I reach a well-aligned 
address (8/16 bytes for MMX/SSE), then do full-width accesses until there's 
only a 'remainder' of data left which has to be read in 32bit chunks again. 
The resulting code is messy.

So from the SIMD coders perspective, it would be very good if Haiku would 
offer some control over data alignment for bitmap allocations.
This includes not only the base address of the bitmap, but should ideally 
extend to each bitmap row, in cases where each row has to be processed 
separately (e.g. by blur routines:). 

Of course there'd be some 'waste', but I don't think this would matter too 
much on modern systems. Binary compatibility shouldn't be a problem either, 
as the BeBook already says that BytesPerRow() are decisive on determing a 
bitmaps actual size.

This might be implemented by an additional constructor without too much 
fuss, I'd guess. It would be great if you could implement this, as this 
would make SIMD coding much easier and less bug-prone.

Bye,
Chris

Other related posts: