Reading and writing are less symmetric than you (probably) think

Pannoniae 4 hours ago | parent | next [-]

Great article :D The rabbithole actually goes even deeper because buffering on the read side is almost always good, but reads are often way more latency-sensitive than writes. Which leads to the paradox that increasing the buffer size / prefetching more with mmapping can lead to worse performance due to the added latency. And decreasing the buffer size can have the same effect due to issuing more calls, so in order to squeeze in the optimal throughput/latency ratio on reads you have to tune it per workload.... or just try a few different buffer sizes and see which one works better.

Writes are the opposite, they're usually not RAW (read-after-write), they're "fire and forget", so you don't really care about latency, but you do care a whole a lot about your writes actually arriving... again two competing parameters because the more you batch the writes, the faster they are but the bigger chance of a torn write or data loss. And unlike reads, writes are not idempotent on the application level so ideally you'd want some logic to atomically write a meaningful amount of data so it won't get torn, even if it crashes.

Now in practice just about no one actually does any of this but it's a fun thought :D

▲

Insimwytim 3 hours ago | parent | next [-]

I have committed a sin of starting with the comments without reading an article, assumed it was about reading and writing text by humans and was increasingly confused by your first paragraph.

I tried to translate it as metaphor at first, but it didn't end up being coherent.

	▲	psdndown 2 hours ago \| parent [-]
		As did I. My happy impression that I was to be commended for reading slowly was turned upside down by the same realization.

▲

plasticchris 33 minutes ago | parent | prev [-]

Makes sense. If you are reading something you need it to make progress, if you are writing you are finished.

▲

1317 5 hours ago | parent | prev | next [-]

oh i thought this would be about language and how the brain works, that article sounds more interesting to be honest sorry

▲

prmph 5 hours ago | parent | next [-]

Indeed, that's what I also thought this would be about; What a bummer.

Someone should post that article instead, lol. I'd love to discuss why I am able to comprehend and read a language almost fully but cannot speak it.

▲

chrisweekly 5 hours ago | parent | next [-]

Search for "Broca and Wernicke" to learn more about the distinct areas of the brain responsible for producing vs processing language.

▲

kekebo 3 hours ago | parent [-]

I probably don't have the best reference at hand, but reducing language to a handful of brain areas like Wernicke and Broca seems to be in flux recently (while more research seems needed)[0].

[0] https://psycnet.apa.org/fulltext/2024-11707-001.html

	▲	chrisweekly 2 hours ago \| parent [-]
		Sure - just a decent place to start

▲

todowhatexactly 5 hours ago | parent | prev [-]

Production is different from reception.

Compare the ease with which you recognize a bicycle and the difficulty of drawing one.

It’s not the mechanics of the pencil alone although that plays a role a well. But even if you could somehow imprint perfect lines like you imagine them, the bicycle and the lightening etc will not be realistic unless you are a trained artist.

▲

tbrownaw 5 hours ago | parent | prev [-]

Or even something about how writing usefully on a topic requires higher expertise than reading and understanding what was written.

	▲	verdverm 4 hours ago \| parent [-]
		or how if you want to write better, read more

▲

vatsachak 6 hours ago | parent | prev | next [-]

This is true even at the CPU cache level so it's probably going to trickle down all the way.

For example Jon G gave a talk at Jane Street about how he had a mysterious performance bug that was later attributed to cores fighting over the same cache line

https://youtu.be/tND-wBBZ8RY?is=624w3YoDN2QYBWuD

	▲	rwmj 4 hours ago \| parent [-]
		False sharing is pretty well known isn't it? I learned about it at university. It's the whole reason why the Linux "dwarves" tools were written, so you can check struct field alignment / grouping against cache line size and make sure you don't accidentally have two adjacent fields used by different cores.

▲

rwmj 4 hours ago | parent | prev | next [-]

In any discussion of read, write & sync, I'd want to talk about write amplification (read/modify/write cycles), and also in Linux the sync_file_range syscall which is a useful way to sync part of a file.

▲

mightyham 4 hours ago | parent | prev | next [-]

> the data may have made it to storage, but that doesn’t necessarily mean it’s actually visible, because the metadata necessary to reach it might not have been written yet.

The author should clarify here that this fsync wrinkle only affects newly created files, not updates to existing ones.

▲

tbrownaw 5 hours ago | parent | prev | next [-]

Yep, reading something doesn't invalidate your caches. Or everyone else's caches.

▲

adrian_b 3 hours ago | parent [-]

I am not sure if you mean what you have written, or you mean the opposite, but reading a big file when there are no available free memory pages will flush memory pages from the disk cache, which previously were caching data from files accessed by your user, or by other users.

In high performance applications, you must not let the kernel choose randomly what pages should be invalidated, but you must use madvise for memory_mapped files or posix_fadvise for files accessed with read/write, with appropriate arguments so that cache memory pages that are not needed any more will be freed with enough time in advance before reading more data.

	▲	tbrownaw an hour ago \| parent [-]
		It can evict other things for space reasons, sure. But it doesn't make their contents invalid.

▲

chrchang523 2 hours ago | parent | prev [-]

(2015)