Rob Pike’s Rules of Programming (1989) • Hacker News Board

Re: Rob Pike’s Rules of Programming (1989)

#41

Post by _urga » Wed, Aug 12, 2020, 8:07 PM UTC

Rule 1 and 2 depend on context, whether you're working on an existing program or a new program. They can be true or false. They can really help or they can really hurt. Are you going into an existing system to do performance optimization? Sure, don't guess, measure. Are you designing a new system? Throw out those parroted premature optimization mantras... you are responsible for designing for performance upfront. You will always measure but depending on context you will design for speed first and then test your prototype with measurements. There's no way around an initial hypothesis when you're designing new systems. You have to start somewhere. That's where Jeff Dean's rule always to do back of the envelope guesses will pay off in orders of magnitude, many times over.

Rule 3 and 4 are gold and always true.

Rule 5 is the key to good design.

Re: Rob Pike’s Rules of Programming (1989)

#42

Post by NewEntryHN » Wed, Aug 12, 2020, 8:08 PM UTC

sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

Re: Rob Pike’s Rules of Programming (1989)

#43

Post by svec » Wed, Aug 12, 2020, 8:09 PM UTC

Pike himself says "there's a 6th rule": https://twitter.com/rob_pike/status/998681790037442561?lang=...

(6. There is no Rule 6.)

And points to the best source he finds for it on the web: http://doc.cat-v.org/bell_labs/pikestyle

Re: Rob Pike’s Rules of Programming (1989)

#44

Post by lliamander » Wed, Aug 12, 2020, 8:12 PM UTC

kens wrote: post #39

lliamander wrote: post #9

Rule 5 seems to mirror one of my favorite insights from Alexander Stepanov: > In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other wo…

In case you've wondered what a monoid is, that's a monoid. Something with an associative operation (and an identity), so you can do the operation on chunks in parallel, like addition.

Yep. And if what you have is an Abelian Group, then you also get distributed computation as well (thanks to commutativity).

Re: Rob Pike’s Rules of Programming (1989)

#45

Post by krzat » Wed, Aug 12, 2020, 8:13 PM UTC

dragontamer wrote: post #22

terandle wrote: post #7

Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity? Sure when n is small the O(n^2) one will be faster but when n is small /anything/ you do is fast in absolute terms so I'm trying to not leave traps in my code just waiting for n to get bigger than initially expected.

> Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity Are you sure that std::unordered_map is faster than std::vector? Did you measure? Every time you access an element in std::vector, you also access nearby ones (thanks to L1 cache, as well as CPU-prefetching of in-line data). In contrast, your std::unordered_map or hash-table has almost n…

Worrying about performance of small collections is premature optimization.

Using maps or sets nowadays is mostly for clarity, as they are used to solve certain kind of problems.

Re: Rob Pike’s Rules of Programming (1989)

#46

Post by chubot » Wed, Aug 12, 2020, 8:13 PM UTC

NewEntryHN wrote: post #42

sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

You made an optimization for the future when enough bottlenecks have been fixed such that this one part becomes the bottleneck.

Except that there are infinite such non-bottlenecks, and all the effort you spend on there is effort not spent on the real bottlenecks.

In other words, all engineering is time- and cost-constrained. Anybody can build a good chair for $10,000 or a good PC for $100,000. Doesn't mean it's good engineering.

Re: Rob Pike’s Rules of Programming (1989)

#47

Post by nix23 » Wed, Aug 12, 2020, 8:14 PM UTC

sethammons wrote: post #19

A quote from one of our founders that I've always liked: If you make an optimization that was not at a bottleneck, you did not make an optimization.

That's a bit broad i think, talking about pure speed of your task you are right, talking about energy consumption then it's not always the case. Or small but often repeated task should be optimized no mater if they are bottlenecks, when the system grows they will become bottlenecks, optimize like a Vulcan is what my boss once said...be logical and nothing else (my interpretation)

Re: Rob Pike’s Rules of Programming (1989)

#48

Post by dragontamer » Wed, Aug 12, 2020, 8:14 PM UTC

zabzonk wrote: post #36

dragontamer wrote: post #22

Earlier quoted context omitted.

> Am I wrong to avoid writing O(n^2) code if at all possible when it is fairly easy to use hash tables for a better time complexity Are you sure that std::unordered_map is faster than std::vector? Did you measure? Every time you access an element in std::vector, you also access nearby ones (thanks to L1 cache, as well as CPU-prefetching of in-line data). In contrast, your std::unordered_map or hash-table has almost n…

Also, creating a hash isn't free. And often ordering is required.

> Also, creating a hash isn't free.

Hmmm... I argue that the hash is nearly free actually.

An unordered_map traversal is probably DDR4 latency bound. That's ~50-nanoseconds (200 clock ticks) per access. What's the CPU going to do in that time?

Well, spending 10 to 20 clock ticks on a typical hash algorithm is fine. Then it will wait the other 180 clock ticks for RAM. If you got hyperthreading, maybe the CPU will go to another thread and do meaningful work while waiting for RAM... but... I think you get the gist.

Even IF the hash were free, the CPU is waiting for RAM anyway. So you got plenty of time to make that hash worthwhile. Even an integer division/modulo operator (worst case ~80 clock ticks) can fit in there while waiting for RAM, with plenty of room to spare.

I guess if everything was in L1 cache, the story is a bit different. A lot of "depends", depends on the data, the access frequency, etc. etc.

Re: Rob Pike’s Rules of Programming (1989)

#49

Post by commandlinefan » Wed, Aug 12, 2020, 8:15 PM UTC

> Tony Hoare's famous maxim "Premature optimization is the root of all evil."

Actually that was Donald Knuth - it's an urban legend that it's an urban legend that it was originally Knuth. Hoare was quoting Knuth, but Knuth forgot he said it, and re-mis-attributed the quote to Hoare.

Re: Rob Pike’s Rules of Programming (1989)

#50

Post by RangerScience » Wed, Aug 12, 2020, 8:15 PM UTC

mywittyname wrote: post #11

> "write stupid code that uses smart objects". Writing stupid code is actually really difficult. For me, it takes a little bit of iterating before I know just the right place to insert stupid.

I have two projects that I consider to have nearly-perfect code. Both are their third iterations, and I think they're stable at this point.

Kinda goes: 1) Make a bad solution exploring the problem 2) Explore a good idea for how to solve the now-understood problem 3) Mature the good idea through usage.