I'm happy to see this work going on.
I've done nothing but write code for SMP (and AMP) game systems for the last 10 years, and almost every day I have to think about parallel programming problems. Based on this experience, my personal opinion is that an Amiga SMP system will perform better than most people expect. That said, I have zero recent programming experience on Amiga so I could also be talking out of my arse.
There's all sorts of talk of Forbid/permit/enable/disable and messages flying around. I think a key concept of writing a highly efficient CPU intensive program is to reduce all interactions with the OS as much as possible. This is regardless of what OS you are coding for - OS's always have overhead. If you take something like an MP3 encoder or decoder, how often do you need to interact with the OS and thus get stuck in a Forbid? If you are smart you will malloc all your memory up front on program startup so there will only be that initial interfacing to the OS for that. You then probably only need to ask the OS to handle file IO and maybe some output to the console. 99% of your CPU should be spent on computation, outside of any kind of Forbid(). Now I think that for any type of program where SMP is useful this will generally be true. Of course, you could do a really crap job of writing an MP3 encoder where you read and write 1 byte to files at a time instead of a block of data, and there will be Forbid() calls everywhere. But I'd also bet that program would run slow on AmigaOS as it is now.
I think the main culprits that will be issuing heaps of Forbid() calls will be programs with intense GUIs. E.g. a paint program. But ... are you going to be running a whole bunch of programs like this at once, or writing a multi-threaded GUI? I would think not too much. Probably something like a movie player in one window while painting in another window could cause some conflict. But worst case I think we are basically serializing all the drawing - even on a proper SMP OS that's probably much the case anyway.
Anyway, I think in particular if Forbid() can be made to only block if another CPU is already in a Forbid() call the SMP should give a pretty darn good benefit for those cases that actually need the extra CPU horsepower. If it can't work that way then certainly one Forbid() heavy program could lock things down a fair bit and introduce additional overhead that causes a net decrease in performance.
Very curious to see the results of the experiment, good luck.
