Multiple Array Read, using Assembler

[HughBanton]

I seem to use FA2P prims all over the place .. must be the way my mind works. I noticed I had a group of 5 operating in parallel (from the same index) in a sketch, so I naturally wondered if I could make a DSP version that did them all in a single code block to simplify & speed up the setup.

From that inevitably came the Assembler version, inside which I've achieved some rather drastic pruning. Good news is it still works, which is rare - I usually mangage to mess them up completely

So I really just wanted some Assembly Wiz to tell me a) if this is legitamate or not, and b) presumably it is much faster, yes? Because it seems very compact and is likely to prove most useful. (To me anyway ...!) And although I get the basic principles enough to prune and rearrange away, (thanks to FS Guru) I've never been taught ANY of the rules so I confess I'm working somewhat in the dark.

In particular, I wonder about the push eax; and pop eax; pair. The original text has a pair bracketing every section but I actually discovered, early on, that I could remove them entirely and it still seemed to work - which I feel sure must be wrong. What is their purpose, and am I OK just keeping a pair at each end of the code as shown?

One day I'll have to buy the instruction book

By the way, I've often read warnings on't Forum about the instabality of memin (as in : Don Not Use!!) but here I've had no problems at all. I assume that's because the arrays are only small, just 72 entries. Could that be it?

multi-array-read.fsm

(2.93 KiB) Downloaded 1010 times

[wlangfor@uoguelph.ca]

I imagine it will be useful. Thanks

I'll test it with a parallel EQ model where I reroute the bands locale dependent on drag and I will let you know. Thanks

[tulamide]

I seem to use FA2P prims all over the place .. must be the way my mind works. I noticed I had a group of 5 operating in parallel (from the same index) in a sketch, so I naturally wondered if I could make a DSP version that did them all in a single code block to simplify & speed up the setup.

From that inevitably came the Assembler version, inside which I've achieved some rather drastic pruning. Good news is it still works, which is rare - I usually mangage to mess them up completely

So I really just wanted some Assembly Wiz to tell me a) if this is legitamate or not, and b) presumably it is much faster, yes? Because it seems very compact and is likely to prove most useful. (To me anyway ...!) And although I get the basic principles enough to prune and rearrange away, (thanks to FS Guru) I've never been taught ANY of the rules so I confess I'm working somewhat in the dark.

In particular, I wonder about the push eax; and pop eax; pair. The original text has a pair bracketing every section but I actually discovered, early on, that I could remove them entirely and it still seemed to work - which I feel sure must be wrong. What is their purpose, and am I OK just keeping a pair at each end of the code as shown?

One day I'll have to buy the instruction book

By the way, I've often read warnings on't Forum about the instabality of memin (as in : Don Not Use!!) but here I've had no problems at all. I assume that's because the arrays are only small, just 72 entries. Could that be it?

multi-array-read.fsm

I hope Martin will see this, as I think, he currently has the most insight regarding DSP on this low level!

[HughBanton]

I have ploughed on. I still don't really know what I'm doing but I'll carry on until teacher tells me where I'm going wrong / or to cease and desist

Anyway .. meanwhile, at your own risk with this stuff I guess, but I've had no nasty surprises here so far.

First thing I found was I could ditch the four shl eax,4 lines by inserting the SSE equivalent where the index is created - pslld xmm0,4; .. a slight saving.

But two further enhanced versions attached here : the first uses the standard 'hop' arrangement that DSP outputs, (definitely not possible with a standard FA2P prim), and the second is even faster because it skips the entire code if the index hasn't changed from sample-to-sample. Such as when you sustain a note or chord. 'Skip' is not yet available in dsp at all, as far as I know.

Massive cpu saving achievable with these versions, if applicable. I dare say they could both be much more elegant if I had The Knowledge and was't just tinkering.

(Possibly I should have started this topic in DSP, not in General, so feel free to move it Mr Moderator! )

multi-array-read_+hop.fsm

(3.08 KiB) Downloaded 1014 times

multi-array-read_+skip.fsm

(3.27 KiB) Downloaded 1002 times

[martinvicanek]

Hugh, you're moving faster than we can respond!
I have ony a slight optimization to your first version: you can write directly to out1...5 instead of writing to the intermediate variables smIntVarTemp1...5 and then copying to outs. Oh, and the push/pop eax instructions are a safeguard in case that you use the eax outside the code block for something else. You don't, so you can leave them out.

Caution: the attached is untested! See, I am one of those memin refusenicks

[HughBanton]

That works fine here, many thanks as always for the tip Martin.

I look forward to your take on my 'skip' method, which is maybe a bit clunky the way I've done it. This is the mod that really seems to make a massive cpu difference, since in my scenarios (well, most of them anyway) the intention is that the module will now only do new table lookups when a note is changed, rather than continuoulsly recalculating the same things a billion times - the ideal optimisation.

I'm still persuing multiple organ ranks, so an organ with 50 stops (arghh!) needs some seriously low %ge to work on your average PC. But that horizon is definitely coming into view at last!

I must have landed in the 'Memin zone'; so far I've found nothing untoward with memin at all, totally stable! (Famous last words).

[martinvicanek]

Two comments on your skip method:

Code: Select all

// Skip everything if there's no index change:
movaps xmm0,index;
subps xmm0,indexOld; // from last time (at end)
movaps indexCompare,xmm0;
mov eax,indexCompare[0];
add eax,indexCompare[1];//add up the 4 channels
add eax,indexCompare[2];
add eax,indexCompare[3];
cmp eax,0; //zero? ..so "nothing has changed"
jz skip;
[...]

1. index, indexOld and indexCompare are floats whereas eax is an integer, so it is a bit of a hack when you mov eax,indexCompare[0]; Which is OK since you are only checking against zero.
2. When you add all indexCompare[] there is a remote possibility that the sum will be zero even if there is actually an index change. You could rule this out by squaring indexCompare but is is probaly not necessary.

[HughBanton]

2. When you add all indexCompare[] there is a remote possibility that the sum will be zero even if there is actually an index change. You could rule this out by squaring indexCompare but is is probaly not necessary.

Yes I can see that's true, but trying to figure out how to try and deliberately simulate such a situation made my head spin, so I think I'll just keep it in mind in case of future oddities

I also wondered if, since it's running on MIDI generated note indexes, possibly MIDI speed (and one note at a time) prevents the possibility anyway?

Is there not some kind of 'proper' way of making an assem flag that can check for 'no change''? I tried an approach using cmpps but couldn't find a solution. Which may well be because I hardly speak the lingo! But it's good fun when it works ...

Thanks again.

[HughBanton]

multi_table_array_read_with skip.fsm

(2.16 KiB) Downloaded 983 times

A jump triggered by 'no change' - I think I've figured this out now. With some virtual help from KG's FS Guru assembler tutorials. Seek (again & again & again) and ye shall find

Using shufps and orps twice it's possible to OR all four SSE index numbers together, and use that result (=0) to jump over the entire code whenever there's no change, such as when holding a chord. Well, literally most of the time! It's a most un-obvious trick but I got my head around it eventually. Marvellous.

So a new version attached. I've made this one to read just 2 arrays, but it's easy to add as many as required, like my earlier ones.

I've separated out the 'changed?' section for several reasons : in my application, where I'm now using my new assem version of FA2P everywhere, I now just have a single 'changed' module wirelessly linked to all of them (mostly 5-way & 2-way versions, & 1 single), another cpu saving. And I dare say it can be used in other applications too.

It's easier to see how it works on its own too; reasonably straight forward to put it back inside if preferred.

[martinvicanek]

Does it work in the poly section? I found that shufps somehow gets messed up with FS' voice management. You might want to check with at least 5 piano keys pressed.