4 ms·
I particularly enjoyed the writing style in this article, largely because of the extent that the author provided unverified and loose figures in the article - c
by personalcompute 12y ago
I particularly enjoyed the writing style in this article, largely because of the extent that the author provided unverified and loose figures in the article - cputime distributions etc. My experience is usually people are extremely hesitant to publish any uninformed, fast, and incomplete conclusions despite them being, in my opinion, still extremely valuable. It may not be perfectly correct, but that small conclusion is still often much better than the practically non existent data on the situation I start off with and allows me to additionally read the article far faster than slowing down to make these minor fuzzy conclusions myself. There is this misconception that when writing you can do two things - you can tell a fact or you can say a false statement. In reality it is a gray gradient space, and when the reader starts off knowing nothing, that gray is many times superior. Anyways, awesome job, I really want to see more of this writing style in publications like personal blogs.
[In case it isn't clear, I'm referring to statements like "So I think that means that it spends 32% of its time accessing RAM, and the other 68% of its time doing calculations.", and "So we’ve learned that cache misses can make your code 40 times slower." (comment made in the context of a single non-comprehensive datapoint)]
- josephlord 12y agoIt doesn't come across as a benchmark of a particular system or a performance tuning guide. It is a few simple experiments to get ballpark figures for just how fast a modern computer is and to trigger a couple of effects (such as cache misses) that can really slow down the system. I think the real value is to show how to start having a play with things yourself.
- deleted 12y ago[deleted]
- kijin 12y agoAgreed. At first, the writing style (too! many! exclamation! points! Are you Unidan or what?) made me think that the article wasn't serious. The fact that I immediately thought, "you're just going to be benchmarking your disk!" didn't help, either. But the author did take the disk performance into account, and the rest of the article was surprisingly interesting as well. It's a quick and dirty exposition for a quick and dirty suite of benchmarks.
- StavrosK 12y agoI don't know, I love her enthusiasm.
- mrec 12y agoSame here. I thought it helped to dispel the conception that only Very Serious People should be interested in this stuff.
- skywhopper 12y agoHer style is definitely different, but after discovering her last year and reading a ton of posts, I find it energizing. I recognize that feeling of excitement she's capturing in her writing style! I should be experiencing it more than I do! She's an inspiring writer. The exact details aren't really the point--they can be gotten easily enough. The process and the discovery are what she's documenting so well.
- drb311 12y agoThe style works because she's going on an adventure of discovery and taking us along for the ride. Loose guesses that you hope are good enough are more fun than exact calculations. It's fun watching Indiana Jones guessing how much sand he needs to equal the weight of the statue, and it makes him seem more heroic. In that case he might have been better taking his time to do it properly, though. Our minds are programmed to learn in a particular way: - Try stuff - See what happens - Try to guess at a rule that would explain why it happened - Test your guess by trying other stuff ... repeat until you know everything It's fun sharing that process with another person, and a pretty good way to learn too -- especially where precision is not important. Technical writers should use it more.
- AnimalMuppet 12y agoIn fairness, it only takes one datapoint to learn that cache misses can in fact make your code 40 times slower.