Slashdot Mirror

http://ridiculousfish.com/blog/archives/2006/08/24 /hex-fiend-11/

Maybe this will help - maybe not.

Here is a little bit about how malloc works in OS X:

http://ridiculousfish.com/blog/archives/2006/05/16 /36/

"It just so happens that Mac OS X's default malloc does the "switch" at 15 KB (search for LARGE_THRESHOLD) whereas Lea's allocator does it at 128 KB (search for DEFAULT_MMAP_THRESHOLD). Sekhon's 35 KB allocations fall right in the middle.

So what this means is that on Mac OS X, every 35 KB allocation is causing a round trip to the kernel for fresh pages, whereas on Windows and Linux the allocations are serviced from the application heap, without talking to the kernel at all. Similarly, every free() causes another round trip on Mac OS X, but not on Linux or Windows. None of the defragmentation benefits of using fresh pages come into play because Sekhon frees these blocks immediately after allocating them, which is, shall we say, an unusual allocation pattern."

He's member of Apple's AppKit team (i.e. he develops both the AppKit and Foundation frameworks).

OS X w/Quartz isn't as efficient as a 'basic' Linux or *BSD kernel.
Check http://ridiculousfish.com/blog/archives/2006/05/16 /36/#comment-805m and

http://www.anandtech.com/mac/showdoc.aspx?i=2436&p =8 for details

The Anandtech article isn't apples-to-apples [sorry, bad pun].)

SGI's better option is to partner with a firm like DRC Computer Corp, and link lots of
high-speed Opterons with FPGAs and GPUs, all on a high-speed interconnect.

SGI systems have to beat the Cell processor (with better software) to stay relevant.
SGI could focus software on providing gaming dev. platforms that allow you to
develop for multiple platforms. Would that require another processor change? Probably.

Whatever that turns into, it's not the "Unix engineering/visualization market", anymore.

Good luck, SGI.

Wrong. Look at the replies to the "debunking" here: http://ridiculousfish.com/blog/archives/2006/05/16 /36/

Before anyone starts spouting off again about Mac OS X being "slow by design" or somesuch, read this article by an Apple engineer that investigates those claims.

This has nothing to do with "simple horsepower" and everything to do with how malloc works and piss poor coding on the associate professor's part. See http://ridiculousfish.com/blog/archives/2006/05/16 /36/

Here are the official compiler flags for OS X as well as a performance hint for heavy loads:
http://dev.mysql.com/doc/refman/5.0/en/mac-os-x-10 -x.html

Here is some discussion on the issue and how performance could be affected by programs written with a focus on linux which does tend to take short cuts for the sake of performance.
http://ridiculousfish.com/blog/archives/2005/06/03 /mystery/

I think you should reread what I wrote. I was wondering why they did not include Oracle in their test suite. Perhaps, they did not include it because it performs better on OS X than linux and they were writing with a pro-linux/anti-OS X slant?

You're way behind the times on that one. The results of that "performance" evaluation have nothing to do OSX threads. Anandtech got it wrong. You can find out more here!

I also must say I'm a bit worried about OS X for servers after that report that showed such terrible performance for MySQL (was it at Anadtech?).

I think it's been pretty well established by now that there were a number of pretty fishy things about that test. From the compilers used to the differences between the Linux and OS X versions of MySQL to the author's lack of understanding of the terminology...the book is not really closed on that benchmark. Please don't give up on OS X Server just because of a single test that appears to have been flawed in a number of ways.

More on this at this (Apple employee's) blog entry.

I like a suggestion I saw on ridiculous fish (http://ridiculousfish.com/blog/) - Intel Chip Based Macintoshes. Or ICBMs for short ;)

You can't mention the anandtech article without mentioning the ridiculousfish article:

http://ridiculousfish.com/blog/?p=17

be sure to read the first comment, since it points out the Anandtech test was read-only.

> Maybe MySQL is using F_FULLSYNC?

http://ridiculousfish.com/blog/?p=17 seems to think so, too. I also agree with him on some other errors in the AnandTech review