Oh wow, I had no idea that write buffers needed to be on the order of a megabyte on modern systems.
"It's not what you don't know that kills you. It is what you know for sure that ain't true" -- Mark Twain
"dd is not a disk writing tool" http://www.vidarholen.net/contents/blog/?p=479
dd is designed to copy raw block data across devices.
Sure, you can abuse both for either purpose, but seems rather misguided to call it out explicitly. What did you intend to gain by doing it?
dd is for transform-and-copy, so you're abusing dd when writing disk ISOs. The fact that most of the Internet is wrong doesn't make you any less wrong.
dd is also designed to copy data from one file to another, in blocks, with optional conversion of the data (eg, from EBCDIC to ASCII), and with optional offsets/limits to copy regions of a file.
dd is not designed to copy raw block data, it is merely a different file copy tool.
Actually, in this article, Linux writing to RAM is slower than MacOS writing to SSD. Hard to conclude that "it's just OS X being slow". I suspect the hardware used is wildly different from the one in the original article.
'In the above example it can be seen that an input block size of 128K is optimal for my particular setup.'
However, the SSD seems to be significantly slower, so the relative overhead of the syscall is going to be respectively less:
'Reading from /dev/zero and writing out to a SSD with a more optimal block size of 256K yields a throughput of 280 MB/s.'
I was getting 250MB/s with the 512 byte buffer size, although the test in the article is doing two syscalls (one read(), one write()) whereas mkfile is just doing one.
At 256KB buffer size I was already getting around 1.8GB/second writing to SSD.