Re: On data structures and parallelism

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 17 May 2009, Linus Torvalds wrote:
> 
> That said, on my laptops, CPU time really _never_ is the issue. Every 
> single time something is slow, the issue is a slow 4200rpm disk that may 
> get 25MB/s off it for linear things in the best case, but seeks take 
> milliseconds and any kind of random access will just kill performance.

Side note - I've several times desperately tried to see if IO parallelism 
helps. It doesn't. Some drives do better if they get many independent 
reads and can just do them concurrently. Sadly, that's pretty rare for 
reads on rotational media, and impossible with legacy IDE drives (that 
don't have the ability to do tagged queueing). 

So when I try to do IO in parallel (which git does support for many 
operations), that just makes the whole system come to a screeching halt 
because it now seeks around the disk a lot more. A similar issue that 
often kill parallelism on CPU's (bad cache behavior, and lots of 
outstanding memory requests) kills parallelism on disks too - disk 
performance simply is much _better_ if you do serial things than if you 
try to parallelize the same work.

It would be different if I had a fancy high-end RAID system with tagged 
queueing and lots of spare bandwidth that could be used in parallel. But 
that's not what the git usage scenario often is. All the people pushing 
multi-core seem to always ignore the big issues, and always working on 
nice trivial problems with a small and well-behaved "kernel" that has no 
IO and preferably didn't cache well even when single-threaded (ie 
"streaming" data).

			Linus