Comment by drewg123
9 years ago
" I did not check on other operating systems, but my guess is that the results would be similar."
Actually, no. Irrespective of mkfile being mostly MacOSX specific, most sycalls on MacOSX are just plain slow as compared to Linux (or FreeBSD). I think this is partially an artifact of performance not being a major metric for most system calls on MacOSX. The systems calls where performance is a critical metric (like timekeeping) use a kernel / user shared page interface to avoid the syscall entirely in the vast majority of the cases.
I recall doing benchmarking roughly 10 years ago to find the best interface to communicate with a mostly in an OS-bypass HPC driver. MacOSX ioctls were some multipler more expensive than Linux, but the native IOKit Mach IPC was even more expensive than that. Sigh. There was a similar story for sockets in non-OS bypass mode, where simply writing on a socket was far more expensive than Linux.
Somebody needs to resurrect lmbench & do a comparison of the various x86 kernels available these days. Maybe that would shame Apple into focusing on performance.
Drew
Using mkfile compiled for Linux on a tmpfs gets me 1550 MiB/s.
I'm pretty sure that even at their slowest, syscalls aren't going to match IO overhead. It's not like the mkfile is CPU bound.
The point of the article is that I was also "pretty sure" about exactly that, and advances in hardware performance meant I was wrong...
2GB/s is pretty damn fast, 0.5 nanoseconds per byte.
That's not what the article showed. It showed that synchronous IO latency was the limiting factor. By arranging your IOs into little 512-byte chunks, you don't make it terribly easy for the filesystem to efficiently use the underlying device --not surprising, given that it doesn't even want to work in 512 byte sectors, and operates more efficiently with lots of a parallel io operations.
2 replies →
>> most syscalls on MacOSX are just plain slow as compared to Linux (or FreeBSD). I think this is partially an artifact of performance not being a major metric for most system calls on MacOSX
This. When flat out milliseconds per syscall is deemed to trump actual functionality and usability of the operating system as a whole, your priorities are simply wrong. Nerding out over obsessive metrics is literally that - nerding out over useless micro-details rather than real-world needs. When your loyalties fall solely upon a race-to-the-bottom speed on POSIX standards that are 40 years old... sigh.
We come across this kind of thing whenever someone releases a new pre-alpha, first-time-endeavour, operating system. Arguments like "It's not 100% POSIX!". Excuse me, but if you think that POSIX is the only valid foundation for an operating system, you're pushing your previous experience as the only facet that matters, rather than any actual measure of quality or merit. The ability to easily port existing applications is not the only metric that is going to dictate the operating system of the future. POSIX is so ancient at this point that it should have been iterated upon a multitude of times by now. It's so out of date it's almost a joke - we're basically still building our operating systems with horses, without even considering that a mechanical or electrical engine is even a possibility.
For 99.9% of use cases, this kind of metric is so far beyond worth even mentioning that it sounds like a farce. Nobody cares about the performance of mkfile. Nobody. If you're one of the very few people wasting your energy on such a thing... holy shit... get over it and modernize your way of thinking. We're not living in 1980; and no, it's not that the "reasonable old ways no longer gain any respect or recognition" - it's that you are trying to live in the past. Move on.
Bloated syscall times wind up being a death by a thousand cuts when your workload is syscall heavy.
One simple, common, example is plain old autotools configure scripts. I have no love for autotools generated configure scripts (and in fact hate them with a passion), but I've long observed they crawl on MacOSX and go much faster on Linux. They do lots of syscalls (tons of fork/exec/open/close/stat).
Reason for downvoting?
Because I speak in a condescending tone that irritates people. I'm quite used to it. I fully admit it's rare that I can present my point of view in a way that is a) concise rather than a rant, and b) doesn't use phrasing that is abrasive. I should have been able to summarize my point in two sentences without negative coloring, but instead it took me three verbose paragraphs with assaulting language. I'm trying to work on it, but old habits die hard. shrug
(Also sshhhhh, it is anti-HN to discuss downvotes)
7 replies →