No, raid is not going to affect fps in general, unless you have a small amount of ram, and then you will have occasional hiccups as data is transfered from HDD to RAM when you enter new graphical areas inside the game or something. In general, a game tries to put all the data into ram because it can access it fastest from there. raid should increase load times and reduce said hiccups though.
Parallel or multi-threaded processing can be severely limited by the HDD. At work, I process terrabytes of image data at a time. It is far too much data to load into ram, so I have to read it and process it as it is read from the HDD. I've also multi-threaded the reduction software to use the 2 cores of my 4400+. You might see the problem here - how can you read data for 2 threads simultaneously from one HDD? You can't. I wrote it anyway to see what would happen, and it works out well.
1) One batch of data is loaded off the HDD and then sent for processing - all with thread 1.
2) The HDD is free to load data for the other thread 2.
3) When thread 2 is done reading a few milliseconds later, thread 1 has just finished processing its data and now thread 1 can freely access the HDD again, while thread 2 now computes.
The process is self-structuring for maximum efficiency without any programming on my part, other than setting up the 2 threads. Wicked! However, you can see it is a balancing game. I was lucky to have file sizes (hundreds of thousands of them) small enough to be read quickly enough - in the time it takes the other thread to do the computation in ram on the data. I get 100% utilization on both cores. If the file sizes were too large, then you would have threads waiting around OR the HDD trying to read 2 things at once, both of which are not efficient. Same thing happens if file sizes are too small, you will again be limited by the HDD. If the computations take longer than the HDD reads, then at least you're not limited by HDD read time. In my case, the computations are very fast and HDD access is the limit.
I have loaded small batches of data just into RAM to see how much faster it was....and it was like 20 times faster - IF it could process all the data from ram. But that data still has to be loaded off the HDD at some point, so I can't really effectively use that.
But at least I have the data reduction time less than the data collection time - if I could only interface my software to the camera then it could process the data in live time!!
One thing I haven't tried is to split my files between 2 different HDD's, and run 2 single threaded instances of my software each reading from a different HDD. At least threads wouldn't be waiting around for eachother to finish with the one HDD. However, since I was lucky and my data reduction time for each file is nearly equal to the data read time, and the process self-steps itself for maximum efficiency (implying only one thread gets access to the HDD at a time), I haven't needed to bother.
I am looking forward to getting my Q6600 system this christmas (in my informations). With 4 threads wanting HDD access, the balance I have now will definitely change...I will see how it does.
I am so intimately familiar with how fast this data should be reduced, I find it a great little way to personally bench my systems. I can bench HDD limited performance and RAM limited performance. In the ram limited case, all 4 cores can access the ram simultaneously and so I am expecting some huge improvements there. The software is a mix of FP and integer computations, so it gives a good test of the system overall - except the GPU of course!
edit: holy c**p. I just looked at the HDD performance for raid0. In my case of processing so much data off my HDD, this would make another HUUUGE improvement!! Wow. I have 4 500GB HDD's now, all their own drives, no raid. I should raid0 two of them!