Yep, thanks for correcting me there. I was half asleep and without coffee :-) It is write-back cache that enables a massive speed boost when using InnoDB and the fully ACID settings. (parent probably knows this, but im putting the rest of this message here for anyone else reading the thread)
Write back-cache is possible without a battery, however having a working battery makes the write-back cache safe; when power is lost in the middle of a write, the cache keeps this data until the computer regains power, then it is written to disk. It is possible but ill-advised to have a write-back cache and no battery :-) If you do that you shouldn't bother with InnoDB's ACID safe settings. According to the manual, some drives and controllers have write-back cache (and no battery) which is not configurable, so be careful putting your fancy ACID applications on cheap SATA controllers/drives.
My test setup is a Dell 2950 2G ram RAID 1 SAS drives. The controller has a battery and 256m of cache. I had to turn write-back on, as it is configured to write-through by default. I did several unplug tests while I had 50 threads updating different records in the table on one machine while unplugging the DB server. After each unplug test the number of successfully committed transactions matched the data when the machine came back up. Switching between write-back (fast) and write-through (slow) had a very significant impact on the number of write transactions per second.
Disabling the syncs altogether boosted the performance several fold, MySQL was maxing all 4 CPUs and was not bottlenecked on I/O at all. If you can afford to lose 1 second of transactions with these fly-by-the-seat-of-your-pants settings then go for it. Stuff like web forums, content sites, etc could probably survive. Places where the worst case is that someone has to repost is not going to kill you. Online stores, etc should not go that route, as losing a second of transactions could leave you with a lot of billed and not shipped customers! Some people will tell you that with these settings you will have inconsistent state, but they are full of it. You will have state that is transactionally consistent, you just might have a slightly older version of it as the last second of transactions may have been lost. Uncommited transactions are rolled back. InnoDB crash recovery still works fine.
I have not found any significant read performance difference between innodb and myisam on identical tables.