No More Apple Mysteries Part Two 319
UltimaGuy writes "Anadtech has an article up comparing the IBM G5 with Intel's CPU. This gives us insight on the strength and weakness of Mac OS X. It also has some thoughts of what they perceive to be OS X's Achilles Heel." From the article: "That is what we'll be doing in this article: we will shed more light on the whole Apple versus x86 PC, IBM G5 versus Intel CPU discussion by showing you what the G5 is capable of when running Linux. This gives us insight on the strength and weakness of Mac OS X, as we compare Linux and Mac OS X on the same machine. The article won't answer all the questions that the first one had unintentionally created. As we told you in the previous article, Apple pointed out that Oracle and Sybase should fare better than MySQL on the Xserve platform. We will postpone the more in-depth database testing (including Oracle) to a later point in time, when we can test the new Apple Intel platform." This is the sequel to another article, reported on in June.
Neon Lights Help (Score:5, Funny)
Re:Neon Lights Help (Score:4, Interesting)
Re:Neon Lights Help (Score:3, Informative)
The binary format of Carbon application is either CFM or Mach-O.
CFM was the binary format of Mac OS "classic".
Mach-O is the native binary format of Mac OS X.
When the OS loads a CFM application, it does so through a "LaunchCFMApp" process instance wich loads the CFM binary and links up in one huge vector table all the system calls being made to Mach-O libraries (including Core Foundation & Carbon).
A CFM application is therefore double-inderected for all system calls.
Mach-O Carbon applications thou
MySQL? (Score:5, Interesting)
Re:MySQL? (Score:5, Informative)
Maybe because MySQL is where they have the most exp.
Maybe because they have a huge database and testing tools already setup for there main site they can use for testing, which again is MySQL
Why do the testing with MySQL? Ohh I don't know Maybe they just can
Re:MySQL? (Score:5, Insightful)
Re:MySQL? (Score:2)
Because they wanted to find out why it has problems on the Mac. And they seem to have found the answer in the way OSX handles threads.
Re:MySQL? (Score:2)
Re:MySQL? (Score:4, Insightful)
Arguments about when OS X got native threading (which is what your link there is about) are moot. What is at issue is the performance of the OS X threading architecture. From the article (by way of Apple):
"POSIX thread (commonly referred to as a "pthread") is a lightweight wrapper around a Mach thread that enables it to be used by user-level processes. POSIX threads are the basis for all of the application-level threads."
So the use of lmbench to get an idea of how fast OS X handles thread and process creation is valid. Therefore, your link does not invalidate the lmbench results of Johan's tests [anandtech.com], which were done as part of a search to find out why MySQL performed so much worse in OS X than in Linux on the same hardware. People can whine and say MySQL is broken, but you can't argue with the lmbench results. Process and thread creation in OS X is simply slow.
Re:MySQL? (Score:3, Informative)
Yes, Mac OS X has lousy fork performance. Yes, this is a problem. No, that doesn't say anything about thread performance. Which might be lousy or wonderful, but is probably lousy.
That said, you can pry my Powerbook out of my cold, dead hands. I'm looking forward to x8
Re:MySQL? (Score:3, Informative)
Look, we know it has a problem around process creation. That's not been news for a very long time. Where am I in denial about this?
My only comment amounted to wondering what the basis was to believe that this benchmark tested thread creation performance, which is distinct from process creation performance. Heck, I even said I was sure that thread creation performance was
Re:MySQL? (Score:3, Insightful)
They are not beating a dead horse, They saw a problem with either the platform or there testing methodoligy and did all they could to find the issue
LAMP (Score:2)
Mostly because of that. It's not just Anand that uses MySQL primarily. They could use Postgres, but the acronym exists for a reason.
You could have OSXAPP - OS X, Apache, Postgres, [Perl, PHP, Python, $P_Script_Language], but then you'd start wading into WebObjects waters..
Speaking of, where is WebObjects in all of this? Does it factor into the bias? Apple lists the following Database Servers:
* Microsoft SQL Server 2000 8.00.194 (?!)
Re:MySQL? (Score:5, Informative)
It's just that unlike pretty much everything else out there Apple GUARENTEE that fsync won't return until the drive has actually written the data to disk, not just to its cache. To do this they require specific drive firmware from their vendors. In their docs they point out exactly how to stop this, it's just that mysql obviously made the decision that data integrity is more valuable then speed.
(Oh, and OS X's task switcher sucks)
Re:MySQL? (Score:5, Informative)
I was referring to the bug in MySQL, not the Mac. The Mac's behavior is correct. That's why PostgreSQL works fine. MySQL relied on Linux-specific behavior, and got burned.
In their docs they point out exactly how to stop this, it's just that mysql obviously made the decision that data integrity is more valuable then speed.
Just be glad that we get secure data out of MySQL at all. Last time I tried to install MySQL on my Mac, there were big warning signs all over the place saying, "The Mac is buggy, your data is not safe! Run away, run away!" Of course, then an Apple guy stepped up and pointed out the fact that fsync worked exactly as it should, and that MySQL needed to fix their code. They've changed the code for better data security, but AFAIK they still haven't optimized for "correct" data integrity behavior.
Oh, and OS X's task switcher sucks
Amen. Drives me nuts, too, because the FreeBSD switcher really wasn't that bad. Here's hoping that Apple gets that fixed one of these days.
Re:MySQL? (Score:2)
Apple told us that the problem lies in Apachebench (the client side), which stalls from time to time and thus generates too low of a load on the (Apache) server.
This sounds like a flat out lie from Apple. Not the kind of behaviuor you should expect from a *nix vendor.
Re:MySQL? (Score:3, Funny)
Uhh, you've never worked with Sun Microsystems, have you?
Re:MySQL? (Score:2)
Re:MySQL? (Score:2)
Re:MySQL? (Score:2)
mysql obviously made the decision that data integrity is more valuable then speed.
That would be a first for MySQL.
Re:MySQL? (Score:2)
That'd be a first. Next thing they'll be implementing ACID features. Where will it all end?
Re:MySQL? (Score:2)
When has MySQL ever done that?
Re:MySQL? (Score:2)
if (DB == "mysql") {
whyNotPostgreSQL();
}
Re:MySQL? (Score:2)
MySQL has its uses, but if it's broke, either fix it or try something else.
Comment removed (Score:5, Funny)
what about the apache and lmbench numbers? (Score:2)
Re:MySQL? (Score:3, Interesting)
Actually, if you have the Apple Remote Desktop Admin tools installed, you do have PostgreSQL installed. Only you don't have full access to it!. ARD uses it to store any collected stats you've pulled from your ARD clients - and they even provide you with directions on how to access that DB from outside ARD (eg, from a command line script). So far, pretty cool.
Unless, that is, you actually want your own installation of PostgreSQL for othe
I am of two minds regarding this (Score:5, Insightful)
But I should step back from that statement. It shouldn't be that way. We should have a truly world-class server combined with our desktop experience. I should be able to go from prototyping my web apps right to production, without a bunch of migration or guesstimation.
I really like Mac OS X, but I'm not above recognizing if it's flawed in certain aspects. Any word on whether Mac OS X Server performs these types of operations better than the client? That would be interesting - somewhat troubling, but interesting (and perhaps not even that troubling.)
Re:I am of two minds regarding this (Score:3, Interesting)
I agree, but you have to look at Apple's stance with the Xserve. The earlier article that is listed in the post was devastating, almost to the point of 'who would want to deploy an Xserve as a server?' type of deal. If they deal with that
Re:I am of two minds regarding this (Score:2)
The next thing that jumps to mind is...
http://en.wikipedia.org/wiki/Straw_man [wikipedia.org]
priorities (Score:3, Insightful)
Re:I am of two minds regarding this (Score:2)
I should be able to go from prototyping my web apps right to production, without a bunch of migration or guesstimation.
I agree with you in principle, but in practice nobody should ever be doing prototyping on the production system - period. Anyone who is doing that (or even doing general desktop tasks) on a server system that is intended for heavy-duty use has bigger problems. It's true that Apple have "focussed their resources on" the end-user experience for desktop use rather than on optimising for heav
RE: IBM vs Intel....arg... (Score:3, Insightful)
I like the g5 chips, and sure the intel ones are okay. But it just seems like AMD would have been a better match for Apple.
Oh well, I'll take what I can get.
And I can't wait to move over a bunch of older intel's to mac os X.
Re: IBM vs Intel....arg... (Score:3, Insightful)
One word: laptops.
C//
Re: IBM vs Intel....arg... (Score:2)
AMD has, and always will be, something of an ugly duckling in the industry. Intel is the giant, the name every investor recognizes. Also, I seriously doubt AMD gave Apple a better offer pricing-wise than Intel.
I agree, it's disappointing, but among other things, there's nothing to guarantee that Apple won't, at some point, switch to/also offer AMD.
Re: IBM vs Intel....arg... (Score:2)
If Apple were releasing a server today, it would probably make sense to have Opteron in it. We don't know what Apple's first Intel based Mac will be, and it sure as hell isn't being released today. The Pentium-M derivative that will apparently run the first Intel Macs will, by all accounts, be 64 bit. It will also be dual core. What's more, it should be entirely competitive with what AMD
Why Apple Didn't Choose AMD (Score:5, Interesting)
Apple didn't choose AMD for a couple big reason. One of them was given by Steve Jobs when he announced the transition - Intel's roadmap offers better performance per watt of power than AMD or IBM can. Because laptops are taking a greater marketshare than desktops, it only makes sense for Apple to have a portable chip that produces the most bang for the least amount of power.
The other issue is fab capacity. AMD doesn't have the capacity that Intel does. Apple got burned more than once by a lack of chips coming from Freescale/IBMs fabs. They do not want to go through that again, and AMD has trouble delivering large volumes of their top-of-the-line processors. They've gotten better, but Apple doesn't want to be held back by a lack of fab capacity.
I use AMD for Windows and Linux, but Apple's business plan makes Intel the best fit for their future directions.
Re:Fab capacity -- or not? (Score:3, Informative)
AMD sold 36 million processors in 2004 [deccanherald.com].
They are opening the new Fab 36 in 2005/06, which should roughly double AMD's production capacity (their two current 8-inch fabs produce less than the new 12-inch fab can).
Intel should have 375 million per year capacity in 2005/06 [businessweek.com], thanks to 5 new 12-inch fabs.
Apple's sales in 2004 were about 3.3 million computers.
So, you do the math: roughly 5-10% of AMD's capacity (depending on how troublesome Fab 36 is) is a pre
Re: IBM vs Intel....arg... (Score:3, Insightful)
I would have rpefered Apple going with AMD opteron's or contracting one of their other beefy 64 bit chips. Why intel?
Currently Steve Jobs is using Intel to beat IBM over the head. Officially PowerPC is out of the picture, but it hasn't been announced just when G5 will stop - will it go dual-core? How about low-voltage?
Similarly, when Apple is largely x86 at some time in the future, Steve will have AMD to keep Intel honest.
I expect we will see regular rumors of Apple switching to AMD, followed by nice p
Where are the workstation tests? (Score:4, Insightful)
And calling OS X's threading its "Achilles heel" is a bit short-sighted and belies an ignorance of OS design choices. Mac OS X adds an extra layer of communication for threading, so you can have user-space threads. This of course, comes with a performance penalty. In Linux, everything is a kernel thread. This gives it a big performance advantage, making it appropriate for servers operating under controlled conditions, as the tests indicate. However, OS X's design choice makes for more secure communication between user-space threads and the kernel, which gives an advantage in the workstation-space, since you can keep a user process from running amok in the kernel.
I've always said that Linux is a great server OS, and these tests certainly show that. But they're very tilted toward Linux's strengths and OS X's weaknesses, so OS X comes out looking like a ball-and-chain on Apple hardware. The author made a fundamental mistake in assuming that server stress tests were the be-all and end-all of performance computing, and that's just not true. OS X's designers made different design choices than the Linux designers did. These aren't choices that can be "fixed".
All he's shown here is that OS X is not appropriate for a high-demand, single-application server, and that's not really news to anyone. At the desktop level, no one's going to be working with thousands of simultaneous threads.
Re:Where are the workstation tests? (Score:4, Funny)
Although, that would explain the quality of
jk... I think it works quite well in general.
Re:Where are the workstation tests? (Score:2, Interesting)
I agree with you, but only to a certain point.
It might be okay to make the arguments you're making, except that Apple is increasingly marketing its systems as performance "serverish" machines in competition with other UNIX systems. I'm not saying that this is correct or incorrect, but
Re:Where are the workstation tests? (Score:5, Informative)
Except that people who implements M:N-style threading like mac os x believe that it can be fast (reasonabily fast)
Not having achieved it (still) is a "achilles heel" indeed. Apple has to work on that and make their threading implementation performant
There's a very good post [theaimsgroup.com] from Ingo Molnar explaining why linux chose 1:1 and not M:N, and he points out a possible "users-space threads" issues:
"Plus there are other issues like security - it's perfectly reasonable in the 1:1 model for a certain set of server threads to drop all privileges to do the more dangerous stuff. (while there is no such thing as absolute security and separation in a threaded app, dropping privileges can avoid certain classes of exploits)"
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Unlikely .. (Score:5, Informative)
Also, expect desktop apps to start using threads heavily (in the future) to use multi-core CPUs
Unlikely. Just because you can, doesn't mean there is any good reason to, and most desktop application developers will have absolutely no reason to bother with threads at all. The vast majority of desktop apps just sit idle most the time, and even the odd moment when they're busy it's mostly just to do basic things like redraw buttons etc. Thus threads will provide a grand total of zero benefit in almost all desktop applications --- yet they come at a cost to developers in that they increase software design complexity and make debugging harder. Most desktop application functionality is inherently synchronous too (driven by user interaction), so I think very few applications will benefit from being multi-threaded. Applications that might are e.g. word processors with background spellchecking and grammar checking, but really, these are still only going to launch a small handful of threads at most. Even CAD apps and applications like Photoshop that do occasionally require lots of CPU when activating certain functions will draw comparatively little benefit from increased design complexity in making a few processor intensive functions utilise multiple threads.
Message passing-cooperative multitasking (Score:3, Interesting)
What I like about it is the granularity. When you are responding to a message, you are in control until you go back to the queue for the next message, effectively doing a yield to other processes until you are given the next message. That way you don't have to worry about locks, and semaphores, and protecting "this data structure" while worry
Re:Where are the workstation tests? (Score:2)
Um... what? Linux migrated away from userthreads because it sucks. OS X has also migrated away from userthreads and now uses kernelthreads. Both use pthreads.
"The author made a fundamental mistake in assuming that server stress tests were the be-all and end-all of performance comput
Re:Where are the workstation tests? (Score:3, Insightful)
This is just plain incorrect. You have been misinformed. (And who modded that up? Shame on you.)
Both OS X and Linux threads share the parent thread's address space in exactly the same way. Both OS X and Linux subprocesses (malicious or not) are denied access to the parent process's address space in exactly the s
Fork and IPC times (Score:3)
Avie Tevanian & the CMU Mach Microkernel (Score:2)
The most interesting parts for me were the fork() times and IPC benchmarks. 0SX was considerably slower in these areas. Is this an nptl issue?
Boy, I'd give my left - ah - ear hair maybe? pinkie fingernail clippings? whatever - if Avie Tevanian and/or some of the FreeBSD committee members would get on here and talk about the Carnegie-Mellon/Utah/Whosesoever's microkernel and the FreeBSD threading layer and all the cool stuff that I've always wished I knew more about ever since I cut my teeth on a NeXTstat
Real world performance (Score:4, Insightful)
Re:Real world performance (Score:2)
Me either
Re:Real world performance (Score:2)
The one advantage of bluetooth on windows albeit with the severely bloated widcomm stack is that it offers a boatload of profiles and services compared to the mac side. On windows you can use the computer as a bluetooth headset or DUN target.. Try as I might I have never figured out how to use my powerbook as a speakerphone, which would be a killer app for me.
Really... (Score:4, Insightful)
I think it tells you something about the mentality at AnandTech that the only criteria they have for choosing a computer are: 1) performance in a benchmark that has nothing to do with any normal user's needs and 2) the shininess of the case.
I think I speak for most Mac users when I say that I couldn't possibly care less how many MySQL transactions my computer could (but doesn't) run per second. There is undoubtedly a more cost-effective way of building a dedicated MySQL server, and they should be used -- as long as I get to keep a Mac on my desk to connect to it.
Re: (Score:2)
Re:Really... (Score:5, Insightful)
That's all nice and all for you, but Apple does sell these things the call XServe's that are supposed to be "servers". And they run an OS called OS X "Server". Some of us really do run servers and it's informative to us for deciding if we should include a G5 or OS X Server as an option for new servers we need. I'm terribly sorry it doesn't interest most Mac users, but it certainly interests some of us. If you don't care, just skip the article.
Re:Really... (Score:3, Informative)
"Again, we are focusing on workstation and server applications" Their bolding, not mine.
They also state...
"The 64 bit Apple Machines were running OS X Server 10.4.1 (Tiger) and Yellow Dog 4.0 Linux version 2.6.10-1.ydl.1g5-smp." Again, their bolding, not mine.
It certainly seems they are discussing OS X as a server.
As to your second point, they probably had a G5 box handy. The CPUs and motherboard arc
Hrmmm (Score:3, Insightful)
The problem is that this correction is still wrong. OS X has never been based on FreeBSD's kernel. Although it has strived to ensure its BSD API matches FreeBSD, and has even ported over some custom extensions (such as kqueue), OS X's kernel has always been based on OPENSTEP's--a Mach microkernel with custom Unix services above it. OS X has had native threads since OS X 10.0 through the NSThread and Carbon Multiprocessing APIs. I don't know whether POSIX threads followed a different route, but the statement that OS X only got native threads in Tiger is simply wrong.
Re:Hrmmm (Score:5, Informative)
Better, but still imprecise. The Mach kernel isn't actually a full kernel. It's a super-kernel on top of a traditional Unix kernel. For testing, the Mach research project used the BSD 4.3 and 4.4 kernels as the basis for the Mach code. By the time of Rhapsody (later OS X), however, BSD 4.x was an extremely old codebase and was in dire need of updating. So Apple did what any smart programmer would do. They grabbed the most recent evolution of the kernel source (FreeBSD) and used that as the core.
That being said, the FreeBSD part doesn't do a whole hell of a lot. Apple has mostly replaced the traditional Unix bits with NextStep Frameworks. The advantage to these frameworks is that they're much more object oriented and easier to work with than their rather primitive ancestors. The downside is that these frameworks are written in ObjectiveC, which means fun times for driver writers.
Re:Hrmmm (Score:2)
s/used the BSD 4.3 and 4.4 kernels/used the BSD 4.2 and 4.3 kernels/g
The earlier versions of Mach required a Unix license to experiment with, while the later versions were completely free thanks to the 4.3 version being completely free from USL source.
More info on the Mach kernel (and why it was actually not a good implementation) here [wikipedia.org]. Note that the OS X XNU kernel has been changed to eliminate the most problematic performance issues.
Re:Hrmmm (Score:3, Insightful)
4.4 was the branch that split into the Lite and Encumbered branches. Most BSD development from that time has progressed from the BSD-Lite branch.
More Info Here [wikipedia.org]
What most people think of when they think of 4.4 as being the first unencumbered version is that the settlement with USL explicitly pr
Re:Hrmmm (Score:2)
Either way, Apple certainly goes out of their way to bring an ObjC "flavor" to their driver kits. Oh, and their documentation for the IOKit is *terrible*. At least in the Jaguar documentation I have on my laptop.
Wait, WTF? (Score:5, Informative)
And where do you think those UNIX services come from?
Because the answer is, FreeBSD [kernelthread.com].
Mach isn't a kernel by itself, it provides very low level services and "hosts" the rest of the kernel (though Darwin blurs this line somewhat, such that the mach microkernel and hosted freebsd kernel are technically the same entity). FreeBSD isn't the entire kernel (and its portion of the kernel isn't the part that provides threading services, see link above) but it is still in the kernel and still provides crucial functionality, and serves as a replacement for certain things which in the pre-OS X kernel used to be provided by OpenStep code.
Re:Hrmmm (Score:2)
- Architecture of MacOS X [kernelthread.com]
- XNU: The Kernel [kernelthread.com]
and then some more from Apple on Darwin:
- Darwin Documentation [apple.com]
not quite (Score:2)
VFS, the filesystem, the whole TCP/IP layer, the POSIX API, all of that cames from FreeBSD code and that's quite a lot of code.
Yes, mac os x uses openstep's kernel. But then, openstep kernel used freebsd code aswell....
I remember a presentation from apple showing percentages of how much code comes from each variant. BSD code was most of it, with the IOKIT being second and MACH-derived code being the last - less than 10%. Shame that I didn't bookmark it...
Interesting, but let's sum it up: (Score:3, Insightful)
It seemed that the authors were trying to make a point about the G5 vs. X86, and why Apple switched, but unless I missed it, there isn't any discussion of OSX Server on X86, or the opportunities that brings. It only seems to discuss OSXS vs. YDL on G5's. OK, Linux is faster. So? I don't get it.
Um. (Score:2)
I assume this is because you cannot legally get OSX Server on X86 right now, nor is it even finished, making it simultaneously impossible and silly to include it in a series of performance testing articles?
Re:Um. (Score:2)
I agree with the grand parent, I expected a nice comparison of G5 to X86 by using the same OS and applications on each. Obviously this wouldn't be a conclusive experiment as there's always optimizations which usually favor the more popular X86 platform, but still, it would be interesting.
Re:Interesting, but let's sum it up: (Score:2)
Umm
Software (Score:2, Interesting)
Re:Software (Score:2)
Non-Apple G5 hardware (Score:3, Interesting)
The question is, is it possible to get a non-apple G5 system since Apple will go the (W)intel route?
I know about Genesis/Pegasos PPC systems but the current ones uses G4s and the not-in-a-distant-future will use the PPC7448(?). But what about PPC970, can we expect them from Genesis aswell or does IBM or someone else make machines with them?
iSQL (Score:4, Funny)
Re:iSQL (Score:2)
Re:iSQL (Score:5, Funny)
Re:iSQL (Score:3, Insightful)
i'm confused ... (Score:5, Funny)
Sam
Mac Mini (Score:2)
Plus I wanna get one.
And now a word from... (Score:5, Informative)
I have a dual 2ghz PowerMac G5, a 3.4ghz Dell Opitplex and a 3.6ghz Developer Transition Kit. I use my G5 as my main computer at home and my Dell and DTK as my main machine at work.
The DTK smokes my dual 2ghz badly, and runs PPC apps in Rosetta at seemingly only slightly slower speeds than my G5. Graphics functions on the DTK smoke my dual G5 with the high-end (at the time) NVidia card it came with. Apps load much faster, Safari is much faster, everything I use is much faster.
The DTK's UI responsiveness is quicker than my Dell 3.4ghz running Win2003 with all hardware accel turned on. OS X has always been more sluggish for me than Windows, but I had to chuckle when I logged into my Dell after using the DTK for a week exclusively and noticing the Dell UI responsiveness slightly lagging.
It's also important to note that the NeXT ABI is probably much more suited to x86 than PPC.
This is a great thing for Apple, and their Intel-based machines are going to impress and wow people.
Slow fork is why I don't use OS X (Score:2)
Why not write a pthread() benchmark?!??!?!?! (Score:5, Insightful)
how hard would it be to write an extremely simple program that calls pthread() in a loop, counts the threads, and issues a timestamp?
If you think the bottleneck is in thread creation, test thread creation, not fork(). They're not the same, and OS X does enough odd stuff with processes that I'd not be shocked in fork() had a bunch of extra process-related overhead that pthread() does not.
I'm not saying that thread creation isn't slow on OS X- it likely is... but please, if we suspect that's the problem, *that* is what we want to see tested! This article and AnandTech's testing methodology somehow explicitly misses the point of what they think the problem is... and it doesn't seem like it should be difficult *at all* to write a simple test to address *exactly* that problem.
Write a simple pthread() benchmark. The code could probably fit on one screen. Publish the code, run the test, file a bug with Apple, be done with it. A simple pthread() benchmark will tell us if the problem is in pthread() or fork() at this point, wouldn't that be nice to know *for sure*, so we don't have to speculate?
All this mucking about with MySQL doesn't tell us where the problem is, and I don't understand what's so difficult about coming up with a simple, pure pthread() benchmark... again, I *do* agree with the author and think OS X pthread() is the problem, I'd just like to see a simple, pure test that *shows* that it's *the* problem, so I can file a bug with Apple...
Re:Why not write a pthread() benchmark?!??!?!?! (Score:4, Insightful)
Heck, it'd not be shocked if fork() on Linux had extra overhead that pthread_create() didn't. It might, for example, be duplicating the address space; fork() is copy-on-write (on most if not all UN*Xes, including OS X and Linux) so that the data in the address space doesn't get copied, but the address space data structures might have to be duplicated, and resident writeable pages would have to get marked non-writeable in the MMU so that an attempt by parent or child to store into them would provoke a copy.
OS X lacking (Score:4, Interesting)
Much as I would prefer to use OSX on a daily basis to windows, and somewhat prefer it to Gnome or KDE, it seems hard to escape the impression that Apple created an OS to run iSoftware (iTunes, iLife, etc.) and photoshop.
Re:OS X lacking (Score:4, Informative)
Some are switching back.
I switched and then switched back not because Linux is technically better but because of the reliability problems, hardware and software. The performance and lower prices are a bonus.
For example, my G3 iBook had about 10% downtime from all the bad logic boards and a few other things (eg they were out of replacement power bricks). I've also had problems with bugs and updates that break things. Some Linux distros are bad about this as well (eg Gentoo), but others are much better than OS X (eg Debian).
Some PC OEMs make better support than Applecare available. For example, Dell offers next-business-day or even same-day onsite support. In the alternative, a user can take responsibility for themselves and get instant service every time.
Ultimatley, I found that Apple simply didn't make a machine I could rely on.
And to sum up every test ever done for any platfor (Score:3, Insightful)
Some things run better on some machines than others.
The End.
Seriously this article and the last and tons of other comparisons always end up with the same conclusions that we have known since the beginnning of time.
Apple's G5's with OS X run some apps really well and some apps poorly. Just like Windows XP runs some apps really well and some apps poorly. With Linux on both hardware platforms some apps run better on the Intel chips and some apps run better on the IBM chips.
There are bugs, sure, but these aren't them. (Score:5, Insightful)
For example:
- Under 10.4, you need to ensure sockets get TCP_NODELAY, and that you don't try and use corking via TCP_NOPUSH or TCP_CORK. Memcached users are watching stuff *crawl* when they hit it, depending on the buffer size you happen to be using.
- Whinging about thread creation overhead ignores the fact that just about everything that uses heavily threaded environments use a thread pool and/or worker system - so thread creation overhead is pretty much a red herring in most app design. Sure, it's not brilliant that it's there, but it's also pretty pointless to talk about.
- As anyone who used poll() under heavy load knows, Panther could core dump; Tiger has improved, but it's poll() implementation is still suffering.
- There is, actually, a hidden cost on Macs - POWER state load/store is a lot more expensive, and the context switches are much higher. Tasks which cross the kernel barrier heavily do indeed pay a higher cost on the mac. This requires that folks who are used to 'cheaper' system calls think a bit more about how they can efficiently move their data in the smallest number of syscalls.
- And let's not forget to mention the exponentially more expensive cost of misaligned data access on PPC, easily invoked accidentally in code.
I mean, even once you get past the worse-than-one-might-want performance of the poll() causing problems, you've got the critical problem with TCP latency stepping in.
Strangely enough, all the tests they did that actually show problems are either known bugs, with known workarounds, or are known differences in behavior...
At some point, someone needs to call a spade a spade - was Apache built using TCP_CORK? You betcha. Was he using a fixed version of MySQL? Nope. Did the form of the tests for MySQL also succumb to the TCP_CORK problem? Almost guaranteed.
A poor test. Next time, pay some monkey to *write some code* if you're trying to prove the 'cost of latency'; if you're trying to prove that most Unix software isn't brilliantly optimized to work around issues which have existed on the mac for some time? Well, everything takes time, doesn't it.
Re:There are bugs, sure, but these aren't them. (Score:4, Insightful)
Apple's not special, and just like every other vendor, they ship bugs. And just like every other vendor, they build, test, and ship the applications that come out in a pretty identical way you get to when you
So, here's the question: Are we talking about the operating system, or someone's ability to run
Because, for a moment, I thought the whole point of the article was to point out the huge, gaping flaws in the kernel - and someone with the right nail (let's point out the flaws in a kernel) ended up with the wrong hammer (let's run a bunch of applications that don't behave well in standard installs or are old enough to be missing important dev fixes.)
Nowhere did I strain to stick my nose up apple's arse - yet your reaction says it all. You're not actually interested in the point of the article, either, and neither was the author.
You're just looking for a way to stick it to Apple for being crap.
Congratulations, you're a winner - Apple's just another OS vendor, shipping just another set of unusual bugs around, just like the FreeBSD it's built on. It's got a 'colourful' TCP implementation, just like FreeBSD, it's got bugs, just like FreeBSD, and it's got its problems with overhead on PPC, just like FreeBSD.
And Linux 2.4, which also had that TCP bug for a while. And 2.6, which now has a different one. Because, quite frankly, if we all wanted the perfect OS for performance, we'd all be running Solaris, wouldn't we. They don't *ever* get bugs in their kernel.
Wanker.
Re:There are bugs, sure, but these aren't them. (Score:3, Interesting)
As opposed to monolithic kernels, where bugs are unusual?
BTW, there's not much "microkernelish" about OS X; it's not as if the kernel's spending lots of time sending messages to random server processes to implement every system call - that code path is a Boring Old Monolithic Kernel code path.
Re:There are bugs, sure, but these aren't them. (Score:3, Insightful)
As for the "microkernel"... You do know it's not Mach in microkernel mode, right? It doesn't mean it doesn't have its problems, but it does mean that Mac OS X doesn't have a microkernel.
There are bits that suck - but these aren't them.
Re:There are bugs, sure, but these aren't them. (Score:4, Insightful)
All of us.
So this whole "OS X sucks as a server" thing can be justified on a lot of grounds, but NOT THIS ONE. Cry more about how bog standard vendor installs aren't high performance monsters. Cry more about how application developers shouldn't have to work around bugs in vendor operating systems.
Then go back to Basic on your Colecovision, because that's probably the only OS I can think of that didn't ship with one.
Re:MySQL and other animals... (Score:5, Interesting)
Re:MySQL and other animals... (Score:5, Interesting)
Given that the Mac community are more concerned over Photoshop than databases its not really suprising that they haven't concentrated massively on transactionally written files (lots of small writes) and may have chosen to focus on optimizing the writing of big files and the maths and graphics processing that goes with graphics work.
More and more I consider the "Mac users are primarily photoshop users" to be somewhat of a strawman. I work at a Java shop, and many of our programmers, myself included, use Macs. So does our change management guy and much of netops. Yes, the graphics designers use Macs, but Macs are used throughout the company by many people for different reasons.
Re:MySQL and other animals... (Score:2)
Macs are branching out all over.
-WS
Re:Features vs speed (Score:2)
Actually they're all about speed sometimes, but only when they have it.
"I wouldn't be too surprised if "Leopard" could run win and linux apps each in their own window, thus the need to keep the app threads separate from the kernel threads."
er... what? That doesn't make sense.
As the article says, each application thread is also a kernel entity in OS X. Also, the number of windows has nothing to do with the number of threads. It doesn't really h
Um, yeah... (Score:2, Insightful)
Which is funny, because they took the fastest available G5s and pitted them against the second fastest available single-core Opterons.
I also don't buy the gcc as an equalizer assertion given in the test. They've already shown that gcc doesn't produce apples-to-apples results, and now they've shown that it doesn't produce improving (or even consistent) results in newer versions.
I'm willing to accept that they've produced some real-world t
Re:Features vs speed (Score:3, Insightful)
Huh? What about all those ads saying a G5 was a "supercomputer"? And what about those Pentium snail ads? How could you possibly say that?
By the report the G5 processors are just as fast as the fastest x86.
But Steve Jobs said they were much much faster, before he caved in and switched architectures. You can't rewrite history! (Well, you can, if you use the Wikipedia, but that's another topic.)
Re:Features vs speed (Score:2)
Sorry, unsupported assertion. Opterons *50 aren't the fastest Opteron procs around, as some already pointed out. But nevermind that. Look at how gcc 4.0 lowers the x86 fp scores. Also, consider the fact that gcc 4.0.0 introduced changes in handling x86 vector code that apparently were not all for the better judging from the numbers (bugs too - see this one [gnu.org] for instance) and that IBM made significant contributions on the Power/AltiVec side o
But there's so much more! (Score:5, Funny)
But there's so much more here at slashdot! Let's add "Companies are also suing other companies over patents/trademarks/copyrights they don't actually have." That covers SCO and the recent LMI stories.
We also have the occasional:
"Somone built a PC out of weird parts,"
"Big brother gained new, over-reaching powers that will bring society to its knees,"
"Some OSS figurehead (Stallman, Raymond, etc) said something idealistic/naive/irrelevant/stupid/arrogant,"
"Researchers at a small University made some irrelevant, impractical advance in so-called nanotech that will never affect anyone but makes us crap our pants,"
"Europe is far more enlightened than the US because...,"
"Some government switched from Windows to Linux,"
"Some government used Linux as a ploy to get cheaper Windows pricing,"
"Someone at Google farted,"
"Roland Piquepaille got a story on his 'blog' accepted by ripping off the AP feed,"
"Fudged TCO studies show that OS 'A' is cheaper than OS 'B,' and far cheaper than OS 'X'..."
"Microsoft is still evil,"
"An exploit is discovered in Windows that allows...,"
"Will we be able to do in 100 years some ridiculous thing that I've read about in tons of sci-fi novels but is completely pointless in real life?"
... etc. Yes, this is our slashdot.
well... (Score:3, Insightful)
People using servers are probably very interested in seeing how server-oriented programs perform in a given hardware
Those are called "real-life benchmarks". They're much better than lmbench and tiny C programs running whatever microbenchmark in a tight loop because they measure what you actually are going going to do with your system.
It doesn't matter if your lmbench numbers are great, if the apps you're going to run don't run well what's the poin
Re:Not A Good Benchmark (Score:3)
Re:Blasphemy! (Score:2)