3 ms·

I'm not sure about the engineering cost being minimal. My research group builds a compiler for a parallel programming language, and we have trouble getting reli

I'm not sure about the engineering cost being minimal. My research group builds a compiler for a parallel programming language, and we have trouble getting reliable performance on OSX. Many of the things you take for granted on Linux are not there: - Pinning the kernel to one core - Reliable pinning of threads (instead of just suggesting that groups be co-located on the same cache bank) Honestly, we have a fairly long list to even get to basic performance, and that's before you start hammering network stack reliability (as my distributed systems friends complain), etc. OSX on the client with Linux on the server works pretty nicely, and I'm somewhat concerned that the OSX team would have to drop client work for a whole release to focus on hardening the server experience, as well as figuring how what they need to implement to be able to support the wide variety of Linux libraries that don't quite work due to holes in the OS that performance people rely on (numactl; papi; etc.). That said, I thought most of the Apple developers have Mac Pros under their desks. If for no other reason, to maintain a highest-end client workstation, it makes sense to keep things alive. But the server sell seems a bit of a reach, engineering-wise.

jws 14y ago
I don't think you'll pry linux developers away with this. But for people adding distributed backend workers to existing OS X apps it makes great sense, even if you don't end up at the same speed as a tweaked out Linux implementation. Likewise, you probably won't beat a good Linux network stack for jamming bits through, but lots of people just need to be up and running, and if the code is shared with the client, that's great. I think its a case of "showing up", they can worry about being best later, if it makes sense, but showing up at all is important. Apple just lost a premier video production house run by a friend of mine over the Mac Pro lifecycle. They'd have stocked up on render machines and waited out the front ends if they could, but that wasn't an option. (Apple will beat my last round of 100% Intel motherboards in Linux servers which have a years old, unresolved flaw in one of their two ethernet controllers that make them reset whenever you push them too hard. They also have a good chance of beating Linux in GPU computation because the vendors actually care a bit about Macs. I've got a lot of GPU power laying around that I can't use at all in Linux.)

jws 14y ago

I don't think you'll pry linux developers away with this. But for people adding distributed backend workers to existing OS X apps it makes great sense, even if you don't end up at the same speed as a tweaked out Linux implementation. Likewise, you probably won't beat a good Linux network stack for jamming bits through, but lots of people just need to be up and running, and if the code is shared with the client, that's great. I think its a case of "showing up", they can worry about being best later, if it makes sense, but showing up at all is important. Apple just lost a premier video production house run by a friend of mine over the Mac Pro lifecycle. They'd have stocked up on render machines and waited out the front ends if they could, but that wasn't an option. (Apple will beat my last round of 100% Intel motherboards in Linux servers which have a years old, unresolved flaw in one of their two ethernet controllers that make them reset whenever you push them too hard. They also have a good chance of beating Linux in GPU computation because the vendors actually care a bit about Macs. I've got a lot of GPU power laying around that I can't use at all in Linux.)