“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.”
…I didn’t RTA (read the article) yet but would like to mention that Mac OS X is a feature rich OS compared to Linux. It’s these features and eye candy built into Mac OS X that generate sales of hardware, so it’s a lot different than Linux with it’s more slimmed down and customizable approach.
Well, the article has nothing to do with features and slimmed down OS:es. It has to do with raw speed.
Even an modern OS as macos X is badly written to be used as server. Linux AND Windows kicks ass when compared to macosX when it comes to server tasks.
OS X Server is poor, sure it makes UN*X user friendly but it also brings on the baggage with it.
Windows Server is great, its a stable Windows system… Linux is also great as well. Apple have a long way to go to make OS X Server a dominant leader.
But as it says, if Apple can make the server with a Linux core andx cutdown on its gui SPX it would be a great server indeed.
And yes i am a mac user… so IMHO Linux and Windows are better server OSes. I’m also thinking about ditching OS and going to another OS but thats another story
Since you hadn’t read the article, why did you post. No one cares about your general views. This forum is for discussing the article, not that you think OS X is “feature rich”
This was an very good review to read.
It shows how big impact the OS has. So, even if people sits with an machine that is very fast, the OS can drag it down completely.
And, the best part, AMD is still the fastest system om them all three. hehehehe
Apple should have chosen AMD instead of Intel for their next gen. Macintoshes.
Looks like Apple is best at making desktop OSes, not server OSes…
Maybe you’re right (I’ve used OSX once), but having such performance hit is worring. It’s not like threads are only used by server applications.
Poor threading and SMP support in kernel. Some results are really lame. Maybe Apple should reconsider XServer ’till the issues would be resloved?
I don´t think Apple has to reconsider any of their hardware, they have to make an better job with macosX.
You can still use your macintosh hardware to run YDL.
Umm. Sorry! I said XServer as a software solution, not a HW one. My fault! 🙂
I remember that Apple invited Linus to speak about
the possibility to use the Linux kernel for their new (MacOSX)
OS.
I am not sure why it never happend but i guess Apple had problems with the license model or something like that.
How know how thing wold worked oot if the builded OSX aoround the Linux kernel….pitty.
Ok, I’ll bite. Let’s see the proof.
“Ok, I’ll bite. Let’s see the proof.”
Steve Jobs, founder of Apple, invited Torvalds to join Apple in helping it develop OS X back in early 1997.
I will give you some links to make sure you will even considier it to be true.
http://www.geek.com/news/geeknews/2001apr/gee20010406005271.htm
http://news.com.com/2100-1040-255450.html?legacy=cnet
http://www.linux-mag.com/content/view/197/2254/
Linus apperantly already knew the MacOSX kernel would be not that good, i even have thought about Apple switching to the Linux kernel when going to X86, that would be something..
Well, I’ll be schnuckered!
Linus was invited to work on MacOSX… not Linux as MacOSX. He turned it down because he didn’t want to work on a different OS; he wanted to work on his own. He even talked about how Jobs assumed all he cared about was beating Microsoft and figured he would put that above working on Linux.
Bobby
Linus wrote about it in his autobiography.
I remember that Apple invited Linus to speak about
the possibility to use the Linux kernel for their new (MacOSX)
OS.
As another poster pointed out, Torvalds had a meeting with Jobs about working at Apple. There was never any discussion about using the linux kernel. I doubt that Apple would ever seriously consider using a GPL kernel.
I doubt that Apple would ever seriously consider using a GPL kernel.
Wanna bet? Google MkLinux. I’m not sure if it was considered for use in Mac OS (I think it was during the Copland days but I’m probably wrong), but Apple was the main developmental force behind it.
I’ll bite since I worked for both NeXT and Apple after the merger.
The MKLinux kernel was used as a model to port Openstep to PowerMacs at the time.
It was never going to replace the Mach Microkernel and if you are a kernel developer the XNU kernel is a new kernel that draws from some work on MKlinux, NeXT Mach microkernel and other kernel technologies that has been developed since 1998.
“How know how thing wold worked oot if the builded OSX aoround the Linux kernel….pitty.”
Who know how things have worked out if they builded OSX around the Linux kernel..pitty
Who knows how things would have worked out if they built OSX around the Linux kernel, pity.
Apple should then update the slogan they chosen for Mac OS X : “Open Source made Easy… ehm, Slower”
(http://www.apple.com/server/macosx/)
oh why should i use the not so matured linux on ppc when i have the superb macosX ? i dont get it ..
Not so matured?
Perhaps you should read the article: if you run a server you will get better performance from Linux than Mac OS X. Significantly better performance if your server is under heavy loads.
Also, Linux on the PPC felt as mature as Linux on the x86 (I was using it a lot in the pre-Mac OS X days and continued using it afterwards). To this day, Linux remains the better alternative if you want run open source software seeming as the Mac OS X package managers rarely cover all of the applications which you would want to run. Then again, that isn’t the point of this article.
…I have now read the article and have this question.
If Apple, with it’s history of integration, was going to produce a next version of Mac OS X with the ability to run other platforms programs in shells/windows, wouldn’t it be necessary for some seperation of the application threads from the kernel threads?
The Mac OS X of the future may be even more feature rich and diversive, at the sacrafice of raw speed.
Anyway this kind of fit’s with Apple’s MO over the years.
From the article:
A low power Power 970FX is also available and consumes about 16 Watts at 1.6 GHz; so it seems that IBM, although slightly late, could have provided everything that Apple needs. The G5 with its 58 million transistors and 66 mm² die size is not really a hot CPU. The Xserve (2 x 2.3 GHz G5) was by far the quietest 1U air-cooled server that ever entered our lab in Kortrijk.
That is the crux of this article. These two articles (this was actually a follow up) prove that there is a lot more behind Apple’s switch to Intel than Jobs & Co. are willing to admit.
The comming years are going to be very interesting.
What are you suggesting, Thom? That Apple is switching to Intel so that they can integrate Wine in MacOS X 10.5?
I’m thinking about this:
http://arstechnica.com/columns/mac/mac-20050710.ars?85674
To me, everything points in the direction Jon “Hannibal” Stokes lined out. The Anandtech articles confirm Hannibal’s ideas.
Yes, this is the point that leaps out at me too. There is apparently nothing whatever wrong with the ppc processor in terms of performance. Changing processors is not going to do anything for performance – in fact, it may lower it. There is something wrong with the OS apparently, and whatever it is, it is not wrong with Linux, and it is not getting fixed at all fast. And there may be cost advantages to the move, though perhaps, not clear, at some performance hit. That is really very interesting, and it does indeed promise a most interesting couple of years ahead. The miraculous marketing machine is going to have a harder and harder time turning on a dime and taking all its customers with it. And it doesn’t have so many it can afford to lose any. And it is going to have a harder and harder time demanding a premium on either OS or hardware or both.
One suspects that Jobs and Co are back in the eighties in more ways than one. They are following the old BCG model, where what you do with a cash cow is milk it for all its worth.
too much blabla in this article.. This prevented me to reach the end…
It was very intersting article to read !!
I am curious if they can do one for Solaris 10 say on AMD and INtel compared to Linux …..if you know an article like that please post the URL ..
The only benchmark I found that includes Solaris and Linux is this one:
http://www.newsforge.com/article.pl?sid=04/12/27/1243207
They use MySQL too for the test.
Kleraly the problem lies in the Kernel, not the feature-rich eye-candy everyone likes to point out. If I’m not mistaken, Darwin can run on x86 hardware, so why didn’t they test it too?
This is a well known and documented problem with OS X. the hybrid mach/BSD kernel has very poor thread creation performance. This considerably slows down database, and server performance.
We knew this a month ago. And the overall results are exactly what I was expecting them to be.
http://www.anandtech.com/mac/showdoc.aspx?i=2520&p=2
So did they, but they wanted to go into more detail about a problem they had found in the article which taught you a month ago.
I put Yellow dog on my Mini and it works great.
.V
Fedora Core 4 on Mac Mini works great as well. YDL will be glad to use FC4 or FC5 source code for their future version.
The title does not say it was on servers ??????????
So basically Apple have been lying through their teeth when complaining about IBM and the G5s. There is absolutely nothing wrong with a G5 machine whatsoever in terms of performance (as everyone has known really), and the only reason why Apple wanted a 3GHz+ G5 was because their OS is simply too damn slow and crap. And Apple are talking about power per watt?! Hell yer! It’s called a G5, and it’s power management is better than anything Intel will have over the next few years.
It’s going to be amusing to watch all these Mac enthusiasts drooling over their new fast Intel workstations when they will still continue to see benchmarks where Linux and Windows continue to kick their backsides, but this time on exactly the same hardware. The arstechnica article about Apple’s bulging memory requirements and compilation settings are interesting also.
It’s also become clear that the only reason why Apple have moved is simply for Intel’s supply (previous chip partners have been driven to despair by their constant stripe changing) and volume discounts. Their desktop business isn’t going to attract anywhere near something that Dell gets, but if they go for Intel inside iPods they might.
All that moving to yet another hardware platform and all sorts of bogues reason as to why Steve? Oh dear.
XScale in the iPod
XScale in the iPod
XScale in the iPod
Also, steeeeep chip discounts, virtually unlimited supply, assistance on R&D and motherboard design, and early access to the new, post-Netburst, low-power, high performance, x86-64, Conroe achitecture.
Too bad the OS still needs more work. It’s hard enough on PPC, but now they are competing against *BSD, Linux and Windows: 3 classes of OS that have had the most x86 optimized lovin’ since the 1990’s. Yes, I know they are using GCC 4.x.x and will have MANY of the advantages Linux and *BSD but not nearly all. Good luck Apple with competing with them on their own turf.
Here’s hoping that Apple at least delivers x86-64 exclusively on their MacTels, as there is still time to make this decision and the performance benefits are proven (due to the added registers). This will at least give them a marketing avantage, for a while, until Windows Vista x64 becomes default for all new computers in 2-3 years.
–JM
The competition won’t be so bad. When Apple starts shipping x86 Macs you can be sure that their bar graphs for poorly-specified benchmarks will show that they are superior to Windows and Linux for desktop and server performance. To the faithful that’s all it has taken since the return of Steve Jobs, and I doubt that will change much.
Linux AND Windows kicks ass when compared to macosX when it comes to server tasks.
A simple task such as recording a CD brings the explorer to a crawl… Windows needs help.
Try adding ram, I do lots of things on my single amd cpu box while burning cds. Also learn how to properly distrubute your hdd’s and cd-rom’s on your ide and or sata buses. (Yes I know sata isn’t supposed to have the limitations of pata)
A simple task such as recording a CD brings the explorer to a crawl… Windows needs help.
Of course thats a task that is done on servers all the time!
you might want to look at how your hardware is configured. The only time I had the problem you are describing was when I had IDE driver issues.
A simple task such as recording a CD brings the explorer to a crawl… Windows needs help.
Um… it’s more likely that you need to stop trying to burn CDs at 52x in Win98 on a P3 450.
Um… it’s more likely that you need to stop trying to burn CDs at 52x in Win98 on a P3 450.
Actually… on Win2K on a Sempron 2200+ with 1 GB of RAM, a freezing Explorer is still a problem. Windows has a less-than-optimal scheduler, and this _is_ a known fact. And MS _is_ making it better from release to release. Win2K3 Server has a better scheduler.
Anyway… Win9x/ME is no platform to use, if you like secuiry, stability and performance. It’s build on a too old and primitive system (DOS).
dylansmrjones
kristian AT herkild DOT dk
Windows I/O scheduler is remarkably weak. Come on in 2005 writing a file to a floppy disk should not freeze the system for a couple of seconds.
Come on in 2005 writing a file to a floppy disk should not freeze the system for a couple of seconds.
That’s the reason it was not worth fixing. Microsoft knew eventually floppy disk would not be necessary anymore
I don’t think it’s the scheduler performance, but rather the overall I/O design. In WinXp inserting a damaged/unreadable CD into the drive will often cause a serious GUI lock-up for a decent amount of time. This feels like 1995 really.
You forgetted about MacOSX. If you insert corrupted/unreadable CD, it bacomes invisible for OS, so you cannot trash it. How can you solve the problem?
Restart -> then press command-shit-F (or something like this, I do not remember precisely) and if you succeeded to access firmware (did not miss the precise time) you have to input three commands to eject this God damned CD.
On Windows boxes, in worst case you should restart and upon BIOS boot you can just press CD-ROM button and it is over. (Generally, you can get CD from running Windows after delay, sometimes long, that’s correct or by forced ejection with the management console).
So guys, now you want to tell that I/O design is better in MacOSX??????????????
while im not saying that your solution to booting into open firmware _wont_ work, i do think its a bit excessive..
in the worst case scenario you can reboot and hold down the mouse button.
or there is the paper clip..
I once had to remove part of the front panel of a beige G3 because a zip disk had become stuck in it (inserted, OS didn’t mount it, so couldn’t unmount it). There was a paperclip hole in the front bezel, but it didn’t f*&$ing line up with the eject hole on the internal zip drive.
Actualy you have to restart and hold mouse button for about 15 seconds or so during Bios or Firmware or whatever.
While, in my casual reality, I hate Apple even though I own G5 and G4.
Though the paper clip does not work on all models. I think removing the button from the CD tray (for design consideration?) is dumb. Having to reboot a system to remove a CD in 2005 is unacceptable.
As said, this has nothing to do with scheduler performance or Windows. It deals with the design of the application or application feature. I/O and other slow operations can cause the UI to not respond if such operations are run on the UI thread rather than on a different thread than the UI.
Windows I/O scheduler is remarkably weak. Come on in 2005 writing a file to a floppy disk should not freeze the system for a couple of seconds.
Right. And (un)mounting a floppy shouldn’t either, mmm?
Gee could this be because the Floppy drive is directly tied into a hardware interrupt on the CPU? This has been known for a long time to be the reason for slow fdd’s. It is an architechual limitation.
Gee could this be because the Floppy drive is directly tied into a hardware interrupt on the CPU? This has been known for a long time to be the reason for slow fdd’s. It is an architechual limitation.
No, it isn’t. The floppy drive is not directly tied into a hardware interrupt on the CPU – it has an interrupt request line on the interrupt controller chip like all other hardware. Also, it’s the floppy CONTROLLER that generates the interrupt, not the drive. The floppy controller also uses DMA to transfer all data and has since the VERY FIRST PC.
Other OSes on the same hardware have no trouble with the floppy interfering with the overall operation of the system, so it must be a problem with how Windows handles the floppy.
hi this is zenlunatic.
for as long as i can remember now ive been running gnu/linux on my ibook. started with debian, then gentoo, then ubuntu and I’ve stuck with ubuntu. i usually dual booted Mac OS 10.1 because i needed to use my modem but now i have broadband.
to make a long story short i am going to purchase 10.4 next week after i find out what new product apple is releasing at there press conference (my guess is a itunes phone).
im so tired of “free software” zealots and linux users who think their OS is ready to be used by everyone (its not). bsd license is better anyway i should add.
I don’t trust this guy since I saw the movie “Pirates of Silicon Valley”.
The reason Steve Jobs and Apple changed to Intel is because IBM couldn’t deliver in a TIMELY MANNER. End of story. It isn’t whether they can. The problem is that IBM, for whatever reason, wouldn’t.
IBM was supposed to deliver a 3 ghz computer over a year ago. Apple -still- doesn’t have those chips. Do you need to know anything more than that? I don’t think so. IBM has screwed Apple many times in the past. I think Steve Jobs finally got Apple in a place with Mac OS X and Intel to do the switch. I think he wanted to do this five years ago but for unknown reasons couldn’t. Having said that, I don’t think we’ll know the real story for at least five or more years, if ever.
“We’re all sorry here that physics got in the way of a 3GHz G5. We’ll be sure to correct the universe in the next version.” -IBM
I can comment that the people here at IBM Austin (the POWER/PPC/Cell/PS3/XBOX/Nintendo chips are designed here) aren’t particularly moved by losing Apple as a customer. It’s pretty much a non-issue. In the halls during the week after the announcement, you might hear:
“Hey, did you hear about the Apple thing?”
“Yup.”
The following is my own opinion and does not (necessarily) the opinion of IBM:
As Hannibal points out in his opinion piece, dealing with Apple is like dealing with your little sister. She whines and complains until you give her exactly what she wants, and if you don’t, she tells on you. It’s an abusive relationship. IBM has plenty of more profitable customers for POWER5 and upcoming POWER-based systems, and they have plenty of more profitable customers contracting for tens of millions of custom processors for gaming consoles. Not tens of thousands for Apple. It’s best if they don’t have their little sister tagging along.
Proprietary platform zealots and slaves: Who is your daddy now? A straggling bunch of weekend code warriors led by a kid from the arctic circle has just dusted the “coolest and hippest” multi-billion dollar operating system that “just works”. Who is next? This is one of the times I get a big kick out of rooting for the underdog
“Proprietary platform zealots and slaves: Who is your daddy now? A straggling bunch of weekend code warriors led by a kid from the arctic circle has just dusted the “coolest and hippest” multi-billion dollar operating system that “just works”. Who is next? This is one of the times I get a big kick out of rooting for the underdog”
1. Calling people zealots and slaves is immature and idiotic, to put it mildly.
2. You don’t seem to have noticed, but there are many uses to an OS and OSX having performance problems with certain server tasks doesn’t mean it isn’t a good OS for other purposes.
3. “A straggling bunch of weekend code warriors led by a kid from the arctic circle” sounds nice, but was true around 1995, but certainly not anymore.
4. You should be concerned if you get kicks out of mysql benchmarks.
As has been mentioned, for a single user, Mac OS X isn’t too bad, and as a single user machine is how Apple has focused on Mac OS X.
Seriously, there’s isn’t a Soccer Mom out there that’s going to buy one of these things because of its threading performance, but rather the entire user experience.
So, this is where Apple has put their focus.
As Apple tries to get out of the Dens of America and into the corporate back office, they will have to focus more upon this kind of base OS infrastructure, but that will be a tough fight against the Linux and Solaris boxes fighting for the space. A Mac OS X MySQL client will run against a Linux box quite handily.
multithreaded use doesn’t just apply to servers.. and especially considering how many times slower OSX is in fundamental system calls could mean a huge difference when, for example, running a custom script on your box to automate some administrative tasks.
(think about it, every external command in a loop, every piped command, every subshell e.g. the “ or () or $(), etc)
That’s a matter of process creation and IPC overhead than a matter of threading performance. While the overhead is greater due to the design of XNU, whether it’s noticeable at all for normal shell scripting is another thing entirely. The locking overhead in the kernel of course matters for all systems and the granularity is important for scaling in syscall-heavy multiprocessor systems independent of threading.
>Proprietary platform zealots and slaves: Who is your daddy now? A straggling bunch of weekend code warriors led by a kid from the arctic circle has just dusted the “coolest and hippest” multi-billion dollar operating system that “just works”. Who is next? This is one of the times I get a big kick out of rooting for the underdog
…..Well said
Actually, it really isn’t “Well said”….
That like a Hybrid kicking the crap out of a Ferrari because it conserves gas, or a Ferrari kicking the crap out of a pickup because it’s faster….
Apple kicks the crap out of Linux in usability, wile Linux kicks the crap out of Apple in threading performance, while Microsoft kicks the crap out of both of them in market share.
– Kelson
Sweet Zombie Jesus, can Apple be mentioned once without someone bringing up cars?
No….not really
The analogy was correct tho, in spite of the car reference, in that there are different design goals, which does not make a straight comparison possible.
– Kelson
Apple should just admit that OSX is just lipstick on a pig and the objective-C on which which it is written is a bunch of garbage. Apple need to buy a linux distribution like Xandros learn how to do it right.
I wonder what took so long to discover that Linux outperforms Mac OS X on Power architectures e.g. G5. I know which OS I am going to use now…
1) I wonder what took so long to discover that Linux outperforms Mac OS X on Power architectures e.g. G5. I know which OS I am going to use now…
With marketing spin you can sell a melting igloo to an Eskimo
Apple and Microsoft do that for a living and most people just lap it…..Get the facts?
Tried Linux many times. Sorry, it doesn’t cut it unless your time is worthless. But hey, I guess it’s easier to just claim everyone else is stupid. Get the facts?
But everyone is stupid..
prove me wrong, please..
Well if my time isn’t worthless, OSX is sure as hell costing a lot more money while I’m waiting for my database query or web page to load.
On the other hand, Linux is sure as hell costing a lot more money while I’m waiting for my Airport Driver to even exist; I have to connect a cable every time I turn the powerbook on. That takes me from 1-10 seconds, depending where the cable is. So you see… your query may take a few more milliseconds… but I waste much more time.
<hope you can see the sarcasm, because there was a little bit of it>.
As the car analogy said, each tool must excel at what it was designed to excel. OS X is a -at least for now- desktop OS. And it rocks.
He spends a lot of time discussing fork and rationalizing why it’s suitable for at least hypothesizing about thread performance. I don’t see why they just didn’t construct a specific threading benchmark and save themselves a lot of space used on explaining why they felt fork figures are relevant. Process creation is also much more expensive with NT than Linux, but I couldn’t in good conscience tell you that is directly useful for comparing thread creation performance.
Instead of this:
“LMBench gives us a rough indication that we might be right, but it doesn’t give us cold hard facts. We need to look elsewhere for those.”
Also what’s also rather important–perhaps more so than creation, especially when not dealing with green threads at all–about a lot of threads doing roughly similar tasks that call into the kernel a lot, is locking performance.
I’d like some cold hard facts. I’d say “find the hard facts and then report,” but on the other hand I think these articles highlight important performance aspects of MacOS X. I can only hope that a third installment will provide data.
There’s also the part where he discusses signals. MySQL doesn’t use signal-driven I/O, and to the best of my knowledge its signal handling is only used for explicit remote client termination and process control.
“Despite the FreeBSD heritage, the TCP signals are very slow (4 times slower!) on Mac OS X.”
This makes me go, “Huh?” Is “sig tcp” really the time reported for catching a signal, or has lmbench changed? I suppose I’ll have to investigate what exactly that’s supposed to be.
From what I can tell Apple doesn’t really give a damn about the webserver market. Linux Apache and Windows IIS pretty much has a stranglehold on that market. Granted, there is some growth in that market, but that isn’t a market that would go OSX anyhow. Let’s face it, for the money an XServe server isn’t a cost-effective solution. However, for large server farms and other High Performance Computing areas the XServe seems to be well recieved. Looking at Apple’s Xserve page http://www.apple.com/xserve/ Apple knows their exact market and targets the areas of scientific HPC. Also, with Xgrid, setup for ad-hoc supercomputing on OSX is incredibly easy. Now, in terms of easy management of HPC I don’t Windows or Linux even come close to OSX. Apple as always is fighting the smart fight and is not even worried about the apache/mysql webserver market. Perhaps in a version or two the threading issues will be minimized. Until then, run linux for all your webserver needs. However, in terms of everyday use of email, www, chat, Office, and anything multimedia, OSX is an awesome system. Also, in an unrelated topic, the new iBook 12″ is an awesome deal for a very solid laptop.
Did you just spin XNU’s performance limitations as a strategic victory for Apple? And then because Virginia Tech created a large cluster (ranked 14th now, afaik) suggest that the Xserve is largely intended for HPC? Is that why Apache is mentioned on the product page? Or why they state:
“Xserve is ideal for file and print, desktop management, web, and media streaming services, as well as cluster computing.”
http://images.apple.com/xserve/pdf/20050504_Xserve_G5_TO.pdf
Be sure to look at the NetBench and WebBench figures.
Kelson:
Re:
Apple kicks the crap out of Linux in usability
That is the biggest lie that ever floated out of the US West Coast. I believed it until I used Xandros Linux. And remember that these proprietary OSes are factory-installed and configured by crack hardware teams led by engineers with 2 to 3 university degrees and I did mine in my installation in my basement. It took all of 20minutes and gave more more wows and more usability and choice of software than any OS I have yet seen.
I don’t consider it to be a lie….I’ve used Linux…for a very long time, since 1991/1992….In the interest of full disclosure, I did migrate from Linux to Solaris x86.
I certainly think that Linux has it’s pluses and minuses, but overall, it is NOT as usable as OS X. You obviously look at this from a geek perspective, even fitting the cliche of doing it from your basement….but since you are so busy in your basement….let me clue you into how the real world works….
Your other posts and comments indicate that you are really just one of these FSF/GNU people. Linux always wins…because it’s “free” and has more “choice” between a bunch of half written programs.
You talk about “choice”. I would submit that most of the programs you get to choose from are deficient enough that not one would ever PAY to use them. It dosn’t matter that they are free, their quality is such that no one but geeks would pay $5 to be able to use them.
Yes, I do use some OSS software, such as Adium, Subversion, Trac, gcc, etc. But I’m glad I’ve got enough quality commercial software that I only have to supplement my commercial applications with OSS, not rely entirely on it.
Consider this a flame if you like, but I think our requirements are different enough, that what you consider usable, for me is completely unacceptable, and vice versa.
– Kelson
Usability is subjective.
If I don’t read the language the OS is localized for its not very usable for me.
If it doesn’t offer the features that I regularly use as a geek, its not very usable for me.
Both OSX and Windows fail the usability test, for me.
For someone with too many X chromosomes, Windows or OSX is probably more user-friendly.
But I have a cat that walks on keyboards and she still prefers Linux.
You’re a strange person… (It’s hard to be polite)
Alright. Let me pick this apart.
First of, OS X is a Mach kernel, not a BSD kernel.
The BSD subsystem runs as a service (process, thread) ON TOP of the Mach kernel.
pthreads is a common (often lowest common denominator) threading library. There are pthreads implementations for BSD, Linux, etc.
It’s reasonable to assume that the pthreads implementation that MySQL is running upon is running on the BSD subsystem in OS X, which is most likely (from what I understand) running as a single process on the Mach kernel. See how this is going?
Mach
|-> Mach Thread (BSD subsystem)
| |-> Pthread
| |-> Pthread
| |-> Pthread
|-> Other Mach thread (Native OS X application)
|-> Other Mach thread
|-> Other Mach thread
Now let’s say that Mach only knows about the mach threads (totally reasonable to assume) it’s going to schedule the BSD subsystem as a single process (which it is). This means anything running the BSD subsystem is going to be splitting up the time used by a SINGLE Mach thread. Performance hit? Uh. YEAH.
I’m completely unsure of the state of the OS X BSD subsystem in relation to the BGL from FreeBSD, which may further complicate I/O functions in regards to everything getting scheduled as a single process in the Mach kernel.
Linux, on the other hand has a native pthreads wrapper that maps pthreads 1 to 1 with linux threads.
Compare a compile of MySQL on OS X that uses a pthreads -> Mach thread wrapper, and uses native OS X / Mach (not BSD subsystem) API’s to MySQL on Linux and _then_ I’ll consider this a valid comparison.
Untill then, you’re bitching that a platform emulation layer isn’t working as fast as the real platforms do.
No, your understanding of the BSD subsystem in XNU is completely wrong. The BSD subsystem is responsible for managing processes, users, networking, the VFS, and numerous other things. This is largely why OS X has such coarse locking, despite using Mach 3.0 as the base. Much of the actual user-level operating system is provided by the BSD subsystem in terms of Mach primitives, and when XNU moved from FreeBSD/NetBSD/NeXT code it used they were all lacking fine-grained multithreading and Apple has had to gradually improve this. POSIX threads in XNU are implemented in terms of Mach threads (they’re not green threads, which would probably improve their performance characteristics in certain ways and remove the seen scaling performance improvement at 2 cuncurrent connections among decreases elsewhere).
Thank God. I was hoping I was wrong. 🙂
So what we’re seeing is terrible thread creation times, scheduling problems, and perhaps even leftovers of the BGL?
I think that it’s likely a combination of the coarse locking (which Apple has been improving continually, but it’s a long complicated process as Linux and the BSDs will attest to) and also Mach (which suffers from various performance problems remedied by modern microkernels like L4).
Pretty good discussion of it here:
http://lists.freebsd.org/pipermail/freebsd-smp/2004-September/00061…
Of course, the situation in OSX is far better than what it was with NeXTSTEP. It’s better than it was on FreeBSD 4, for that matter. Apple has taken an approach somewhat similar to FreeBSD’s; whether it works remains to be seen. OSX 10.4 is very stable for me, while FreeBSD 5 has left much to be desired (including simply refusing to boot on several of my machines, and hard crashes on others).
The other route is that which the DragonFly developers are taking — making essentially everything rely upon in-kernel messaging. That makes distributing the LWKTs among processors very easy.
The reason, of course, that Apple stuck with Mach is because the Cocoa/ObjC frameworks are designed to use Mach IPC natively. On any kernel that doesn’t support them, the message calls have to be emulated by libraries and translated to native system calls (see: OpenStep for Solaris or Win32 and GNUStep). At the time that Apple was updating NeXTSTEP to become OSX, nothing that wasn’t Mach supported them. NetBSD has added Mach IPC support, but that was in order to provide Darwin binary compatibility.
The summary of this for me is that the open source model works as well and sometimes much better than the closed source software development even if the latter is backed by billions of dollars. Show me a deficiency of Linux and I will show you a problem that will solved openly and honestly with time and community effort (not swept under the rug with marketing dollars)
The summary of this is that Apple’s design has performance tradeoffs that they don’t necessarily see an immediate reason to remedy, and also that the processor architecure currently in use is not resposible for the performance problems Anandtech previously noted. This may or may not matter to you depending on what you intend to use your XServe or desktop Mac for. These performance tradeoffs aren’t at the level of proprietary software, but rather stem with tradeoffs with using Mach (open source and not particularly high-performance) in conjunction with the manner BSD code (open source) has been integrated into the kernel of XNU (open source as part of Darwin).
Please “fix” XNU for us in the true spirit of open source.
“The summary of this for me is that the open source model works as well and sometimes much better than the closed source software development even if the latter is backed by billions of dollars.”
The summary of your post is that you don’t have the slightest clue about what you are talking about. Not to mention that one example doesn’t show anything really, you don’t seem to be aware of the fact that all the stuff relevant to this tests on OSX are open source, as someone already pointed out.
Please stop embarassing yourself and especially other open source users and advocates.
P.S.: Isn’t Xandros the company with the propietary file manager?
I like how all the Linux geeks get all excited and think this means the end of Apple, and that Linux is The Best OS Ever, and that all Mac users may as well go kill themselves now. The fact is, I could care less about mySQL performance on my iBook. What I like is that OSX makes all my computings tasks easy and enjoyable. Reguardless of how slow MySQL is, my iBook still “just works” for me. I am not brainwashed by Apple’s magic benchmarks, or Steve Jobs, or pretty iPod posters. I just like how well my computer fits my needs, and how much fun it is to use. If I am tinkering at the command line, it is because I want to, not because my OS isn’t working, and I read in some forum that I need to edit this or that config file. That being said, it is very clear that at this point that if I wanted to run a MySQL server, OSX would certianly not be my OS of choice.
Who’s talking about what you’re doing with your ibook? I agree with you about OSX and Linux, bat that isn’t the point of the article.
IMHO Apple has very nice products, but they can’t hide lies behind marketing and Steve Job’s oh-so-nice face.
Get the facts.
Oops! I hope Microsoft don’t sue me for using that!
No one ever said that OS X was perfect, or that there aren’t improvements that need to be made to the infrastructure.
I personally can’t wait to see how much better the OS X experience gets as Apple increases focus on the underlying ‘plumbing’ of the OS.
– Kelson
Very nice article with a decent level of info.
I am curious to know how this bottleneck affects workstations.
On my old G4 (733 Mhz), I can burn a disk, watch a quicktime movie and surf the web at the same time with little hangups, while my PC colleague will not do anything while burning a CD for the fear of creating coasters.
This is in agreement with the study in which the author(s) state that for general use Mac Os X is more than adequate.
I still like this study since it points to a possible hurdle for using Os X as a server for MYSQL. Once this is fixed- which it will be- then Os X will beat the crap out of all other Oses!
Linux is the OS. Apple could easily layer their GUI over top of Linux and you as the user would NEVER KNOW except for the fact that you got more performance out of the same hardware.
Get a grip! Linux is just an OS kernel.
Did I miss something? Wasn’t the point of these two articles to try and nail down the elusive issue of comparing performance between ppc and x86 ? The thread handling issues of OS X weren’t primarily brought up as a deficiency of OS X vs. linux, they were brought up to hilight the fact that the previous test may not have been a fair comparison under the scope it was conducted.
Personally, I applaud the authors for trying to make the test as un-biased as possible. No doubt there are technical points that could be nitpicked (as they pointed out themselves) but at least they tried to cut through the hype. I’m not an Apple fan by any measure, but I have been morbidly curious for some time to see how the ppc really does measure against x86, and I guess this is as close as I’ll come to a seemingly unbiased view.
Save the OSX vs. Linux vs. Windows arguments for Mactel, to me that’s when we’ll actually see how the different software architectures playout when they’re running on a truly common platform. Until then it seems academic.
Well, doesn’t Mach use message passing instead of direct function calls?
I highly doubt that Apple is really worried about competing with Linux, Solaris, Windows, and the BSDs on the server front.
People use Windows and OSX for the desktop, and Linux, Solaris, BSD for the server. Right tool for the job.
>Tried Linux many times. Sorry, it doesn’t cut it
>unless your time is worthless. But hey, I guess it’s
>easier to just claim everyone else is stupid. Get
>the facts?
Nope, not everyone is stupid. Just you, bubba.
The fact is, I could care less about mySQL performance on my iBook. What I like is that OSX makes all my computings tasks easy and enjoyable. Reguardless of how slow MySQL is
Maybe not for you working with an i-book.Allthough i like to use MythTV now and than to record some concert movies or series,all stations are stored in a MySQL database.
This makes OSX server a pretty lame bird to say the least,and will certainly not give Apple the prestige they want and deserve.
I don’t know about you, but is it just me or does a lot of this article fumble around trying to guess where the bottlenecks for Apache/MySQL on Apple’s servers are (BTW, the results are so poor that the XServe looks like a dud for a “MAMP” solution as far as I can see)?
I’m a bit surprised the article didn’t mention Darwin (on which Mac OS X is based), because at least the source code is available for that and would probably give some clues in the source tree as to why there appear to be some nasty bottlenecks in Mac OS X.
As it stands, I don’t think anyone could recommend an XServe for anything but lightweight tasks at the moment (wasn’t that the situation Linux was in over 5 years ago?). It is a bit depressing that even the latest Mac OS X release hasn’t fixed these quite serious issues – I dread to think what Oracle or Sybase would perform like on an XServe with Mac OS X – probably not too well I bet…
Before declaring how it works.
http://developer.apple.com/documentation/Darwin/Conceptual/KernelPr…
Excerpt:
Using Mach Scheduling From User Applications
There are three basic ways to change how a user thread is scheduled. You can use the BSD pthreads API to change basic policy and importance. You can also use Mach RPC calls to change a task’s importance. Finally, you can use RPC calls to change the scheduling policy to move a thread into a different scheduling band. This is commonly used when interacting with CoreAudio.
The pthreads API is a user space API, and has limited relevance for kernel programmers. The Mach thread and task APIs are more general and can be used from anywhere in the kernel. The Mach thread and task calls can also be called from user applications.
However MySQL is designed, I can guarantee it isn’t designed with Mach Threads as one of its thread scheduling models.
I would love to see a comparison between postgresql8 on O S X Tiger Server and Linux.
Then I’d love to see how much optimization is need within postgresql 8 and mysql 5
I’d love to see how their platform performs on OS X and Linux.
http://store.openbase.com/downloads.html
I think that this article is full of mistakes that are done by purpose (i dont know, maybe!!) or are due to the misunderstanding of those guys about many computing ideas and principles. I really think that such articles that claim to be informative should not be allowed to be on internet as it is simply saying wrong things.
My big concern about their tests is that they are not fair and they never tend yo be fair to the apple side and osx. For example i believe that everyone who pretend to make precise testing should realize that if they got results that differ so much and are so unexplained, well the best thing is to try different testing methods and tools. So tools may work well for a given platform, others may not work well. So any tempt to highlight any os design flaw should be done after testing many different benchmarking tools. They don’t do that, instead they try to find some reasons that are completely meaningless in the sense that they are saying things that are technically wrong. Trying to find such whatever threading problems in osx in order to hurt the platform is not really fair……
So to begin with, let me comment on the Apache results. Well they use Apachebench to test osx, and they get rather low request per second with osx. Well ok, but why don’t they try something else to test Apache performance, in that case they could figure out that the problem is either the os or the benchmarking tool (they recognize themself that apple did tell them that thre is a bug in ApacheServer, while running it on osx, maybe? i did not test it).
Try to run WebBench on osx and linux ppc or x86, and have a look to the results. Well WebBench is a largely accepted benchmarking tool for test Apache performance, so it make sense to use it too. pcmag.com have tested a Xserve G5,
http://www.pcmag.com/article2/0,1895,1630329,00.asp,
and their result show something like almost 8000 request per second for 60 clients for a static configuration test.
Ohhhh!!!! What’s going on here? What we have here is something completely different, a completely different image compared to their results. What does this tell us? Well two different bench tools can produce very different outputs. But moreover everything that follows in their article simply collapse because nothing tell us that the tools that they use for MySQL testing are not having a problem too. Moreover WebBench involve as weel many threads creation, so their theory about this threading problem of osx collpase too.
We simply dont get any global image of osx performance in server applications with their limited set of bench tools. Did they never think that the problem of those results could come from the benchmarking tools or the app itself that may have performance problems while running on osx.
Here is the comment of pcmag.com
“Performance-wise, the dual-processor Xserve G5 compares well with Linux-based x86 servers. This is not surprising, considering that Mac OS 10.x is based on FreeBSD UNIX. Using the included Apache server, we ran the Xserve G5 through our standard WebBench tests. It did quite well on the static WebBench test, outperforming a competitor’s dual processor x86-64 server running Apache server on SuSe Linux-64.”
Something rather different to their general statement, isn’t it?
So now about MySQL. So first they mention fsync(). Let me correct. What are they talking about is wrong?, fsync() behaves the same as it does on all unixes: it writes the data from the host to the drive. However this is not good enough because drives will buffer the data and potentially write it in a different order than the app did.
To deal with this, MacOS X provides an fcntl() called F_FULLFSYNC which does what fsync does and in addition asks the drive to flush all buffered data to disk. This is the only way for an app to be able to make any guarantees about things like transactions which is why InnoDB in MySQL uses it! And i think that because its an os feature it works whenever you use MyISAM or not.
And i don’t understand why their benchmark should lower the pressure on the disk. A database app like MySQl has to write and read data on disk while running, so what they are saying is simply wrong.
to be continued….
Not very specfic with “X86-64″….
Lets now talk about their insane theory about threading in osx. Here is their statement
“Readers pointed out that there were two errors in this sentence. The first one is that Mac OS X does use kernelthreads, and this is completely true. My confusion came from the fact that FreeBSD 4.x and older – which was part of the OS X kernel until Tiger came along – did not implement kernelthreads; rather, only userthreads. It was one of the reasons why MySQL ran badly on FreeBSD 4.x and older. In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. ”
What does it mean this? What does it mean that os x prior to Tiger did not implement kernel threads, my God! what are they saying, they should just go and take some os design course.
Kernel threads are of course in previous version of osx and in Freebsd. Mach itself implements a multithreaded VM layer for example, and anyway i mean, every thread that access the kernel runs in the kernel. An app that makes files IO or network task has one of its threads dealing with that which enter in the kernel space and runs in the kernel until it resumes. So i dont really understand what does it mean to say that and what is their aim to say that osx did not have kernel threads. I think they seem to confuse kernel thread and fine grained locking.
When a thread enters the kernel, it shares the same memory space as the entire kernel itself as well as any other interrupts which run in the bottom half of the kernel (kenel thread are said to run on the top half). So os designers had to implement many technics (i don’t really enter in the details here) to protect the data being manipulated by the kernel. One of them and still partially used by FreeBSD was a giant lock which protects the kernel of any threads which wish to enter inside its memeory space. Actually Giant Lock was implemented to protect the kernel space particularly in case of multiprocessor machines where the principle of not preemptable kernel was not enough anymore to protect the kernel in such hardware. OS X before Tiger used something similar to the Giant Lock although not identical. Os x implements funnels that serialize the access to the Bsd portion of the kernel.
Funnels are built on top of Mach mutexes, and are used simply because Mach is thread safe, the bsd protion was not, they needed something to serialize both of them. Funnels are sleeps locks, and each funnel backs to into a mutex, and one a thread gains a funnel is is holding that funnel while is executing. The difference between a funnel and a mutex is that a mutex is hold across rescheduling.
There were a funnel for the file system and one for everything else, mainly the network code. In Tiger the funnels are gone and the BSD portion of the kernel implements now fine grained locking in order that SEVERAL threads can exist in the kernel at the same time. So they confuse both ideas, of course kernel threads did exist prior to Tiger otherwise the system can not do any file system or network operation. What Tiger does is that it allow better scaling for multiple processors architecture for threads that run in the kernel space (this scaling requirement did not concern threads that runs in the user space) with fine grained locking. Right now the the network stack and the file system in the BDS portion in Tiger are thread safe.
“In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. ”
That’s not true, many os today offers a 1:1 mapping for executing the threads whatever they are. So any threads including user or kernel thread are managed by the kernel. What a hell is this app running on top of the kernel in the user space? Thats simply dont make sense…..
Now lets come to their process and thread theory.
“However, it is important to understand that threads and processes are not completely different, but they are related to each other. In the case of Linux, creating a thread is very similar to creating a process. In fact, you use the same procedure, only with different flags or parameters. Linux implements all threads as if they were standard processes. You create a new thread with the clone() call, and the necessary flags, which describe the resources (memory) to be shared. The process creation is done with fork(). But fork() is nothing else than a clone() without the flags that describe the resources that must be shared. So, if you test fork() on Linux, you also get a rough idea of how fast threads are created.
What about Mac OS X? Well, when the Mach kernel is asked to create a Unix process (fork()), the mach kernel creates a task (which describes the resources available) and one thread. So, thread creation time is included in the fork () benchmark of Lmbench. ”
That’s not true at all. An os calls fork() for creating process (or Task), right! An application is also a process, actually it is a the child of a parent process which is launched when logging in.
A thread, right! ,shares the same address space as the process that launch it and share the same address space as the another threads launched by the same application. But what Lmbench measures is process creation not thread creation.
Thats not the same thing ,creating a process and a thread are two different things. The first one is created by the os, the second is created by an application with a system call, and why are they talking about clone() to create threads, that does not happen like this in osx. Yes Mach creates a process if it is asked to do so, and one thread belonging to this process. But after that any new threads is created by the app, not by the os. When MySQL runs, it creates threads, right, but the latency or performance hit that they are talking about can not be measured by Lmbench as MySQL creates threads and this tools measures process creation.
to be continued….
How can they measure anything about any thread problem in osx running this tool that does not tell anything about what they are talking about. They try to explain an obscur relation between thread and process, but they completely miss the point…..they just dont understand how it works….
Threads are not sequential flow control within a program (what does it it anyway to say that!!!!), they are lightweight peace of code that are time-sliced by the kernel. Advice too them: Take a book about threads, and read it…..
“And although MySQL is only one process, it must cooperate with other process via IPC. ”
Which over process is this. Any other process means an application or any other os proccess. Which one are they talking about? why to measure IPC in case of MySQL? Generally, their test about IPC and signaling are completely meaningless, because i really dont understand what they try to measure and besides that fact that they try to confirm a theory about threads in osx that comes mainly from their imagination and misunderstood.
”
relatively high TCP Latency that we measured
the implementation of the threading system. Does the pthread to Mach threads mapping involve some overhead? Or is this the result of the traditional performance problem of the micro kernel, namely the high latency of such a kernel on system calls? While Mac Os X is not a micro-kernel, the problem might still exist as the Mach core is deep inside that kernel. Is there IPC overhead? Lmbench signaling benchmarks seem to suggest that there is.
the finer grained locking in the current version of Tiger that is not working for some reason and we still have the “two lock” system of Panther.
”
Everything that comes from theitr Lmbench seems not to give trustable results about performance on ox. A given benchmarking tool can give you very untrustable results, see the apache test too.
God damm!!!! there is no thread mapping overhead why should there be? Osx use a 1;1 model for every thread, user or kernel space maps directly to Mach without any overhead. Or do they try to find any reasons even it does not make sense….. There is not high latency on system calls in osx, they just try to convince themself about it to support their ridiculous theory that simply comes from bad testing. Darwin is not a micro-kernel, xnu is monolithic. BSD does not run as a servie on top of Mach as i could also read in this forum.
And PLEASE dont say that i am wrong or that you know better than me. I am a damm Darwin coder……
Since macos x was not intended to work as a multi-server. and a crash of the BSD server was equivalent to a system crash from a user perspective, the advantage of protecting Mach from BSD were negligible. Rather than simple collocation, message passing was short circuited by having BSD DIRECTLY call Mach functions. The abstractions are maintained within the kernel at the source level, but the kernel is in fact monolithic. Saying that the problem might still exist as the Mach core is deep inside the kernel is simply meaningless, what does mean this? Again they just try to find stupid argument that have no technical meaning and proof. Their Lmbench simply seems to give bad results on osx, or whatever reasons, but right now nothing can alllow them to say such things with a single test.
Moreover some people seems to confuse where threads are handled in osx. Threads has to run, right? They have to get ressource to run (cpu ressource), so they are time-sliced by the kenel. Some people seem to think that it is the bsd portion of xnu that manages threads, not at all. Everything comes to the Mach portion of xnu where the threading management code is. Any call to a Cocoa, or a Carbon multhreading API, or any call to the Posix threads API which belongs to the BSD code mapps directly to Mach. Osx offers diffrent way for the programmer to create a thread, and to deal with them, but at the end everything is managed by Mach.
The fine grained locking is working in Tiger. The test that they did do not show anything about whether its working or not. Nothing can allow them again to say such stupid things. The funnels in Tiger are gone, believe it or not thats not my problem, but please i cant support that they try to make believe people about such wrong statement.
You may say me now that i just talk about the bads point of the bench that they did, and i just forget the rather good results done by the G5 with flops test. Well the same comment can be done, they are unfair because you take a very old floating point performance bench tool that is more suitable for x86 chips than for G5. Look at the code of flops, there is a lot of to do in the code to optimize it like unrolling the loops for better parallelism. You may say that the code is not optimized for x86 either, yes but it runs better on those chips as it is now than on G5. And why a hell they use such poor testing for floating point performance, why not using Linpack much more suitable for such task. So their conclusion about floating point performance on G5 compared to x86 is simply not true. Any reasonnable testing of floating point performance can not be done with a such limited tool like flops, its ridiculous…. Each G5 is capable of a fused, multiple-add operation per cycle, so you get 2 flops per cycle. This means that 2GHz corresponds to 8 GFlops, so each dual 2.0 GHZ G5 can deliver a peak of 16 GFlops of double-precision performance. An Opteron gives you 4 GFlops at 2.0 ghz. This does not correspond very well to their “as good as x86” statement, does it?
Well, well a lot of things isn’t? I mean their text is so full of mistakes of any kinds mainly due to their poor understanding about os design and computer principles in general, and they come up with such interpretations that are so wrong…..
to be continued…..
And why dont they use Xserves for servers benchmarking. I mean, just forget about the osx/linux comparison and focus on the hardware comparison in server applications. The powermac is a not a server and it not designed as a server. that means that it is not designed to run server applications effectively. A power mac has an ethernet controler, which is directly connected to the I/O controler K2. This K2 controler manages every other I/O operations (except the PCI-X slots) like disk out and input, etc…. What does it mean is that the networking flow of data has to share the bus with I/O disk data with is a major and very important bottleneck in aplications like data base as they perform a lot of network and disk operations.
Network operation has then to share a 1.6 GBps bus from the K2 to the PCI-X bridge with everything else. And yet data has to go until the northbridge before to be put in memory or to be computed the cpu. Well this design is good for any desktop worstation, because this kind of machine don’t deal with server network performance bounded applications. Now look at the Xserve. The Xserve has first a dedicated Ethernet ASIC controller, the powermac not. This ASIC provides many network tasks optmizations, like hardware-generated TCP, IP, and UDP checksum to detect packet corruption and transmission errors, 802.1q VLAN (Virtual LAN) tags let you group systems on different physical LANs and provide discrete services to them — as if they were on separate, physical LANs and a 64KB buffer supports jumbo frames, or packets up to 9KB, to reduce system overhead and increase throughput of all network activities.
Quiet a lot of things, isn’t? Moreover the advanced ASIC includes two independent 10/100/1000BASE-T Ethernet interfaces, each with its own interrupt, on a dedicated 64-bit, 133MHz PCI-X bus. The Ethernet controler is linked directly to the PCI-X bridge which communicates at 4.8 GBps to the controler system. This makes a huge diffrence in networking performance, because the ethernet interface can communicate very quickly with the rest of the system in order that data can be processed much faster than a powermac. Thats a server design. Apple dont sell the Xserve just for fun…. And the amazing thing is that they talk about “The Xserve Server Platform”, but they dont test the Xserve at all, something is wrong here!!!! Now i guess that they were saying in their first article that it was more fair to use a powermac than a Xserve for comparison with x86 boxes because the powermac shipped with a G5 that have higher frequencies. They totally missed the point, the performance of a server platform depends fisrt on how it is optimized to handle network communication.
I am sure that they wont, but i asked them to remove this article because it has so many mistakes, misunderstandings, etc, …. that any reader will misunderstand their statement, and Os X. Thats really insane and maybe dangerous to publish such articles which their content relies on people that do not understand everything about what they are writing.
Its really funny to see some small boys with still some acne on their face who think that they can teach you computers and computing, how it works and so on…..because they got a bunch of computers in a classroom.
This is just crap……..
Have a nice day……
Hakime.
Isn’t there a little logic fallacy? Yes, they could have tested a server, and yes, it could have given different results. But to do that would not have answered their question. Their question was, is there a performance difference between YDL and OSX running on the same hardware. What they seem to have shown is that there is, and that the cause is something to do with threading. There is a separate and very interesting question, whether the XServe configuration is as good or as bad as an x86 server configuration, and whether it is better than the desktop version they tested, as a server, but that is not really the question they tried to address.
They also seem to have shown that performance was not a valid reason for the move to Intel, and that is maybe even more interesting.
Wow, reading about operating systems is fun. Using them is quite something as well. I choose the later and finding things out on my own.
Quiet a lot of things, isn’t? Moreover the advanced ASIC includes two independent 10/100/1000BASE-T Ethernet interfaces, each with its own interrupt, on a dedicated 64-bit, 133MHz PCI-X bus
Doesn’t help a bit if you hook it on to a 56k6 modem.Neither does it increase threading performance inside the server OS.
While there is a serious amount of latency left in OS X, a fact that should be considered whenever you’re making prognostications about the future is this: Every version of Mac OS X since initial release, every one of them, was faster on the same hardware. Same Hardware, every one. 400mhz iMac. Faster in Tiger. So, if somebody wants to make predictions, try using historical data before choking on your own tongue with “Da Future ifh Maks R mor purty buht swower”.
“Doesn’t help a bit if you hook it on to a 56k6 modem.Neither does it increase threading performance inside the server OS.”
Read again what i wrote. I said without considering any OSX/Linux comparison, it means that i am not talking about any threading performance when it comes to hardware comparison. I was talking about server application performance as a whole, and dont say me that the networking hardware design has nothing to do with server application performances. An application lika Apache or MySQL use network communication to work, thats all their story, isn’t?, so any hardware optmization and design for networking play in their performances.
I said without considering any OSX/Linux comparison
Isn’t the FQDN of this site http://www.osnews.com?OSNEWS right?
The network adapter you described sure is relevant for a server but do you think Apple is the only one who knows this?It goes without saying that the hardware is evidently important.It’s not relevant to discuss the xserve hardware,the article clearly stated that there’s nothing wrong with the xserve hardware,in fact the praised a lot of components.It’s easy to change the hardware configurration of the Xeon and opteron platforms.But the quest was how well the OS’s react under various load conditions in conjuction with client server requests.
The test conditions might have been not quite optimal.But it’s peculiar to say the least to see MSQL perform on *only* OSX poor.So if the benchmarks are flawed or not the right ones doesn’t matter, because it affects all platforms.
Most important,Apple is proud to state OSX being UNIX.Well take any UNIX decendant exept OSX and you will see how well any major relational database can be integrated and performs and it goes without saying you can certainly connect more than 5 clients.
So how much UNIX is there in OSX?