News for hackers. Stuff that matters.
Re:Mkfile(8) is severely syscall limited on OS X by drewg123 on Sunday February 12, 2017 @08:59AM (#13628320)
" 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

Re:Mkfile(8) is severely syscall limited on OS X by 3wisemen on Sunday February 12, 2017 @05:58PM (#13631627)
Using mkfile compiled for Linux on a tmpfs gets me 1550 MiB/s.
Re:Mkfile(8) is severely syscall limited on OS X by cbsmith on Sunday February 12, 2017 @05:53PM (#13631587)
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.
Re:Mkfile(8) is severely syscall limited on OS X by mpweiher on Tuesday February 14, 2017 @12:36AM (#13641423)
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.

Re:Mkfile(8) is severely syscall limited on OS X by cbsmith on Thursday February 16, 2017 @10:31AM (#13660625)
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.
Re:Mkfile(8) is severely syscall limited on OS X by mpweiher on Sunday February 19, 2017 @11:50AM (#13680540)
OS X does write-coalescing.
Re:Mkfile(8) is severely syscall limited on OS X by cbsmith on Sunday February 19, 2017 @03:28PM (#13681800)
You can't write coalesce IO operations that haven't been called yet.
[dead]
Re:Mkfile(8) is severely syscall limited on OS X by drewg123 on Sunday February 12, 2017 @03:42PM (#13630639)
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).

Re:Mkfile(8) is severely syscall limited on OS X by kebolio on Sunday February 12, 2017 @10:08AM (#13628629)
Reason for downvoting?
Re:Mkfile(8) is severely syscall limited on OS X by developer2 on Sunday February 12, 2017 @10:18AM (#13628696)
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)

Re:Mkfile(8) is severely syscall limited on OS X by Waterluvian on Sunday February 12, 2017 @11:22AM (#13628998)
I was the same. Probably still am sometimes. The most helpful reminder to myself was that this isn't a shame or punishment thing. It's simply that most people aren't receptive when spoken to that way. So instead of feeling like I was being shamed into being polite, I just reminded myself that it's my loss if I can't communicate my thoughts, no matter what the transport mechanism looks like.
Re:Mkfile(8) is severely syscall limited on OS X by Razengan on Sunday February 12, 2017 @11:51AM (#13629139)
Language is such a horribly inefficient and inconsistent medium of communication..
Re:Mkfile(8) is severely syscall limited on OS X by Waterluvian on Sunday February 12, 2017 @08:18PM (#13632376)
It's unbelievably flexible though.
Re:Mkfile(8) is severely syscall limited on OS X by Razengan on Monday February 13, 2017 @10:51AM (#13636129)
Ambiguous, I would say.
Re:Mkfile(8) is severely syscall limited on OS X by gpvos on Sunday February 12, 2017 @12:50PM (#13629490)
Actually it is neither forbidden nor uncommon to see a comment by the downvoter explaining their reasoning for the downvote. But complaining about being downvoted, or inviting discussion about it, is frowned upon.
Re:Mkfile(8) is severely syscall limited on OS X by kebolio on Sunday February 12, 2017 @04:37PM (#13631038)
I just wondered seeing as it had been flagged dead within an hour I believe.

I believe however that this is one of the fundamental flaws of Reddit-style websites. On an imageboard you are obliged to make your disagreement in words, constructive or otherwise. Here, you can passive aggressively click the downvote button and leave the post in limbo.

Re:Mkfile(8) is severely syscall limited on OS X by wott on Sunday February 12, 2017 @07:07PM (#13632029)
Well, sometimes it is better to just click to downvote, because the only other possibility that makes sense is to leave a message saying that the guy is a scumbag shithead. In such (common) cases, the simple downvote is better for the health of the thread and of the protagonists.

(I am not at all talking about the present case, let it be clear :-) )