example),
300 GHz.ready in the morning.
contrary,
take advantage of those
improvement.
incredibly nice features,
Rendering is embarrassingly parallellizable, i.e. you can get nearly an N-fold speedup from N cores. Database updates are another story. When I was at IBM, I used to kid the mainframe guys that if anyone figured out how to parallellize database updates really well, they'd be out of work. Most of them agreed, IIRC.
Multicore isn't very different from ordinary multithreading, except in the details of managing resource contention, where you have to use spinlocks sometimes. My 3D electromagnetic simulator code runs on a Linux or Windows cluster built out of multicore machines. IIUC newer multicore architectures are even more like single-core multithreading since instead of spinlocks you can put the core to sleep for awhile, which is pretty similar to a thread blocking on a mutex.
I found it fairly hard to make a serialization model that worked on symmetric multiprocessors as well as clusters, in Windows, Linux, and OS/2. (I started writing it in 2003, but there's a debugger that I
*love* that only runs in OS/2, so I wanted to support it too. RIP.)To make a portable solution, I eventually used a combination of mutexes and file handles. Linux filesystem semantics are really loosey-goosey--any number of fopen() calls on a file will succeed if they're from the same process, which makes file pointers useless as synchronization elements in Linux, whereas they're pretty good in Windows and especially OS/2. And then there's NFS, but don't get me started. That's why I wound up with a combination of mutexes and file handles as the portable solution.
So in general multicore is a problem mostly from those being dragged kicking and screaming from the single-thread world. No?
Cheers
Phil Hobbs
(Who wrote his first 32-bit multithreaded app under OS/2 2.0 in April
1992, while Windows was just eye candy on top of DOS, and Linux was still a gleam in its father's eye.)