Originally Posted by MacRulez
FileMaker's a good use case, but I can't imagine people using a server
for the other tasks you listed. And by itself, Filemaker, fun as it is, apparently wasn't enough to keep the xServe line around, esp. in a world driven by MySQL and MongoDB.
Dude, in case you haven't noticed, the Mac Pro IS a server, it's just built into a tower rather than into a proper rack-mountable box. Those CPUs are designed with reliability in mind; they emphasize things that you don't really need in a workstation but pay premium for in a Mac Pro, such as multi-socket installations, ECC memory, and lower temperatures. These things are important in servers that run 24/7 and can actually extract some benefit from parallel processing to serve requests from multiple, independent sources. On the desktop, the only kinds of applications that can take advantage of lots of cores or CPUs are compression, encoding, and cryptography, which perform lots of processing on very small amounts of data that can easily be cached thus eliminating or mitigating the memory bandwidth and latency bottlenecks, tasks that you can and should be offloading to a server anyway; other kinds of single-user applications that require access to lots of data, such as Photoshop, will always have problems no matter how many CPUs you throw at them because all the CPUs are limited to the performance of the memory bus. While it is theoretically possible to take advantage of multiple memory busses on systems like those for this kind of job, in practice this requires the operating system to keep lots of memory access statistics and physically rearrange memory pages on the fly to make it possible, and current operating systems simply don't do that yet.
Forgot to mention that the memory bandwidth problems are even worse on x86-based systems, because for backward compatibility, x86 forces cache coherence across the board, so any writes to memory done through one cache unit have to be immediately propagated and synced in all other cache units, as well as the RAM itself, if at least one of the other cache units don't have that particular memory space cached.
And this is why multithreaded development is hard. If you thought it was only because of the need to control access to shared resources, you were only scratching the surface. I know this because I've made that mistake myself and had to learn the hard way (watching finished multithreaded implementations perform almost as poorly as single-threaded ones because I didn't know what I was doing).Edited by Vaelian - 2/1/13 at 1:39am