Fast software is a discipline, not a purpose • Hacker News Board

Re: Fast software is a discipline, not a purpose

#31

Post by microcolonel » Thu, Nov 16, 2017, 9:05 AM UTC

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

The problem is that these rules should apply in sequence to a given feature or flow, but they're instead applied in sequence to the whole product. So what happens is: they make everything "work", then they spend the next two decades pecking at making it right, and making it fast takes a back seat.

Corollary: interaction latency, power consumption, and other performance characteristics should probably be part of "make it right", and "make it fast" might not even be a value at all.

Re: Fast software is a discipline, not a purpose

#32

Post by majikandy » Thu, Nov 16, 2017, 9:05 AM UTC

dullgiulio wrote: post #11

jackjeff wrote: post #2

“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…

Performant code vs readable code is a false dichotomy.

Do you have any evidence to back that statement up?

Re: Fast software is a discipline, not a purpose

#33

Post by majikandy » Thu, Nov 16, 2017, 9:08 AM UTC

I’ve spent the last 20 years not caring about performance. Not once has performance ever been a real issue on any project I’ve been on. Imagine how much time I could have wasted prematurely optimising.

Re: Fast software is a discipline, not a purpose

#34

Post by speedplane » Thu, Nov 16, 2017, 9:17 AM UTC

majikandy wrote: post #33

I’ve spent the last 20 years not caring about performance. Not once has performance ever been a real issue on any project I’ve been on. Imagine how much time I could have wasted prematurely optimising.

You've never written any code to run in parallel? Or used a data structure or algorithm with O(logN) time instead of O(N) time?

Re: Fast software is a discipline, not a purpose

#35

Post by lmm » Thu, Nov 16, 2017, 9:18 AM UTC

jlg23 wrote: post #29

jackjeff wrote: post #2

“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…

The advice you quoted is the most valuable of all, in my opinion. You give "map/filter/reduce" as an example and claim that theses approaches "typically result in passing over the data multiple times". No, since reduce can behave like map and filter , with a proper reduction function you only have to pass over the data once. > Most collections/array I process have trivial number of elements ( That is true for all oth…

> No, since reduce can behave like map and filter, with a proper reduction function you only have to pass over the data once.

You can indeed - which is why reduce is relatively opaque and unmaintainable, and should be a last resort. Any given map/filter pipeline could be rewritten to reduce, and it quite possibly would perform better - but at the cost of not being able to test individual pipeline stages, nor inspect the intermediate results in a debugger. Most of the time that's a bad tradeoff.

Re: Fast software is a discipline, not a purpose

#36

Post by lmm » Thu, Nov 16, 2017, 9:20 AM UTC

AstralStorm wrote: post #5

jackjeff wrote: post #2

“Avoid multiple passes over the data when one would do.” Totally disagree. Unless performance is an issue (like I’m not dealing with a trivial number of elements), I would rather use functional programming approaches to sort data into shape (think map/filter/reduce). These approaches typically result in passing over the data multiple times, and often performing multiple copies, but it makes for readable and less erro…

Readable and less error prone? As opposed as to proven to be correct for example? Recursive functional code is a pain to prove to be right and not blow up stack. Multiple passes (when interspersed with other accesses) can blow up cache. Even calling through a lambda is a cost compilers cannot easily optimize away unless you help them. (Even in C++.) You do get the benefit of optimizing all the "trivial data size" cod…

> Recursive functional code is a pain to prove to be right and not blow up stack.

Much easier to prove recursion correct than to prove a loop always terminates, since the recursion makes the way the state changes between steps much more explicit. If you're really worried about this you can use Idris and require all your functions to be total.

Re: Fast software is a discipline, not a purpose

#37

Post by nnq » Thu, Nov 16, 2017, 9:30 AM UTC

Blah. You get a lot of performance "for free" by getting the overall architecture of a system right. By starting with optimizations, you usually hit the "limit of your brainpower" very soon, like before you know enough to architect things right, so you mess up the architecture (think like "shit, we ended up with this location dependent time conversion logic in the backend instead of on the clients, so now is un-cacheable, but it's too late to refactor across multiple teams now... shit").

Just avoid building un-optimizable systems (nowadays it's harder than ever to avoid this... all the tools and services lay traps for us), and then you can safely leave the optimizations for later...

If you can't avoid building an un-optimizable system, all your clever early optimizations are worthless anyway. If you can, they can be postponed anyway.

Now, what I'd really want to read would be an article/book about avoiding the traps that lead people to get stuck with un-optimizable systems! (Though I imagine it's in general an unsolvable problem if natural evolution didn't solve it either: at some point your body accumulated enough de-optimizations that it basically stops working or being fixable/optimizable, so you die, and some of your memes and genes carry on in "rewritten forks" aka "other newly born people".)

Re: Fast software is a discipline, not a purpose

#38

Post by majikandy » Thu, Nov 16, 2017, 9:31 AM UTC

speedplane wrote: post #34

majikandy wrote: post #33

I’ve spent the last 20 years not caring about performance. Not once has performance ever been a real issue on any project I’ve been on. Imagine how much time I could have wasted prematurely optimising.

You've never written any code to run in parallel? Or used a data structure or algorithm with O(logN) time instead of O(N) time?

I probably have, without particularly prioritising it. Ok, perhaps I should have said "overly caring about performance". Of course I have used built in functions in languages that take advantage of this when searching or sorting - but no, I can't remember a time when I had to get into the nitty gritty of low level performance enhancement, unless it was in a coding challenge of course.

Re: Fast software is a discipline, not a purpose

#39

Post by dullgiulio » Thu, Nov 16, 2017, 9:31 AM UTC

majikandy wrote: post #32

dullgiulio wrote: post #11

Earlier quoted context omitted.

Performant code vs readable code is a false dichotomy.

Do you have any evidence to back that statement up?

I think the proof should be on those who say that readable code cannot be performant.

Re: Fast software is a discipline, not a purpose

#40

Post by Cthulhu_ » Thu, Nov 16, 2017, 9:37 AM UTC

delta1 wrote: post #26

1. Make it work 2. Make it right 3. Make it fast "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet w…

The challenge there is that a lot of developers are pushed by their managers to go to the next feature after #1, postponing 2 and 3 for when there's time. Time to market is considered the most important thing. Of course, it accumulates after a year.