4 ms·

You post a list of the best comments on HN without putting The Wisdom of Bane on the list? Seriously, how did The Wisdom of Bane not make it one here? That is

You post a list of the best comments on HN without putting The Wisdom of Bane on the list? Seriously, how did The Wisdom of Bane not make it one here? That is one of the best comments on all of HN. For the uninitiated: https://news.ycombinator.com/item?id=8902739 https://news.ycombinator.com/item?id=8902739

nekopa 10y ago
Heh, I prefer to refer to that whole comment as Bane's Rule. I have had many interesting discussions with IT managers face to face after having them read that, especially regarding the idea of having vendors show that their product beats out the current system. For programmers, I think one of the key takeaways from that comment is not the clever coding, but the direct tie into business results from the coding. Not just immediate business results, but also how the system was set up for growth and improvement easily too.
- qwertyuiop924 10y ago
  It's about some of core principles of software: Keep it simple, use the minimal code (if it's not there, it can't slow you down), see where speed problems are before optimizing, optimize before scaling up. It's common sense, but it's rare to actually follow it. Actually, I'm guilty of this myself. I was finishing last year's Advent of Code, and was given a problem which I tried to optimize, as I assumed the naive approach would be too slow. Then I realized I was trying to optimize Travelling Salesman, so I bit the bullet and went for the O(n!) solution. And it ran in less than a second. In interpreted scheme, no less. I felt kind of silly later.
nickpsecurity 10y ago
Thanks for the link. That was an amazing comment that should be required reading for all these people thinking about throwing datacenters at their problem of choice. It's actually about the same as the advice and methods used in the Beowulf clusters back when all this crap was starting. They did come up with creative ways to scale out while NUMA vendors (esp SGI) kept scaling further up. However, they also identified bottlenecks in their algorithms from transport all the way up to application layers. Active Messages vs TCP/IP, BLAS libraries, hand-tuned MPI, careful choice of interconnects, offloading I/O onto dedicated workstations w/ clustered filesystes... always improving efficiency of each component in the stack to get max ROI out of those expensive clusters. As bane notes, it seems that third part of doing HPC right was lost in translation to modern crowd. Not entirely sure why. Prior conversations indicated strong separation between HPC and business/cloud crowds in terms of knowledge sharing. Plus, there's marketing hype and VC money involved riding the waves of whatever is massively popular. Bigger IT budgets, too, if your proposal doesn't involve using one, mid-range Dell. I'm sure such things have more impact than the technical arguments in many places. ;)
- qwertyuiop924 10y ago
  There's a reason it's a classic. The best summation I heard of it was, "If you can't get the solution to a problem to fit on one machine, you probably don't understand the problem well enough." This is probably one of my favorite quotes in software. I'm probably slightly misquoting it here, but I don't care.
  - nickpsecurity 10y ago
    It's been formalized past that into the COST methodology of assessing distribution solutions: Configuration that Outperforms a Single Thread. If that configuration doesn't exist, just ditch the solution in favor of a single thread. :) http://www.frankmcsherry.org/assets/COST.pdf http://www.frankmcsherry.org/assets/COST.pdf http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html http://www.frankmcsherry.org/graph/scalability/cost/2015/01/... It just gets more hilarious the more you read the measurements of all these tech vs a single thread.
    - qwertyuiop924 10y ago
      A single thread frequently has less code: less code means less code being executed. This is a contributing factor to speed. The less instructions you have to execute, the faster it runs, give or take. Not that instructions executed do not necessarily correlate to code size (a loop is only written once, but executed many times). By the way, bane responded to my original post: it's worth reading.
      - deleted 10y ago
        [deleted]
      - nickpsecurity 10y ago
        His response just loaded on my end for some reason. Yeah, that's the points I was getting from his longer write-up. If you see him redo it & I'm not there, definitely ping me so I can see the future copy. We were actually both in the best example I've seen of this effect on HN: https://news.ycombinator.com/item?id=12472905 https://news.ycombinator.com/item?id=12472905 It's the kind of title that, if proven in resulting article, should make many people pause to think about how effectively they're solving business problems.
bane 10y ago
Aww shucks. Thanks for the shout out. I realize reading this again that I owe a more significant writeup -- I started one not long after this and wasn't happy with how it was shaping up. Maybe I'll have another go at it. Since writing that comment two years ago I've added a couple more examples consistent with the ones in the original post. One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. When they're working with the platform, and hitting the inevitable and unplanned for performance issues (because, you know, just shove the node to the hadoop cluster and it'll magically take care of that), the solutions never tackle the algorithmic bottlenecks but instead seem to focus on messing with the platform or changing platforms, or changing run-time languages or throwing more hardware at it. If you are having trouble taking the nuts off your wheel to change a tire, using a bigger hammer or a blow torth isn't going to help. Take the time to find the wrench, of the right size, and then things will work much better.
- qwertyuiop924 10y ago
  I mean, you get shoutouts every day. Thanks for responding to this one. >One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. Ahhh yes. The "when X is your hammer" problem. In this context, I think the appropriate incarnation is, "When Hadoop is your hammer, everything looks like 1000 nails to be hit very quickly, using brute force."

nekopa 10y ago

Heh, I prefer to refer to that whole comment as Bane's Rule. I have had many interesting discussions with IT managers face to face after having them read that, especially regarding the idea of having vendors show that their product beats out the current system. For programmers, I think one of the key takeaways from that comment is not the clever coding, but the direct tie into business results from the coding. Not just immediate business results, but also how the system was set up for growth and improvement easily too.

qwertyuiop924 10y ago
It's about some of core principles of software: Keep it simple, use the minimal code (if it's not there, it can't slow you down), see where speed problems are before optimizing, optimize before scaling up. It's common sense, but it's rare to actually follow it. Actually, I'm guilty of this myself. I was finishing last year's Advent of Code, and was given a problem which I tried to optimize, as I assumed the naive approach would be too slow. Then I realized I was trying to optimize Travelling Salesman, so I bit the bullet and went for the O(n!) solution. And it ran in less than a second. In interpreted scheme, no less. I felt kind of silly later.

nickpsecurity 10y ago

Thanks for the link. That was an amazing comment that should be required reading for all these people thinking about throwing datacenters at their problem of choice. It's actually about the same as the advice and methods used in the Beowulf clusters back when all this crap was starting. They did come up with creative ways to scale out while NUMA vendors (esp SGI) kept scaling further up. However, they also identified bottlenecks in their algorithms from transport all the way up to application layers. Active Messages vs TCP/IP, BLAS libraries, hand-tuned MPI, careful choice of interconnects, offloading I/O onto dedicated workstations w/ clustered filesystes... always improving efficiency of each component in the stack to get max ROI out of those expensive clusters. As bane notes, it seems that third part of doing HPC right was lost in translation to modern crowd. Not entirely sure why. Prior conversations indicated strong separation between HPC and business/cloud crowds in terms of knowledge sharing. Plus, there's marketing hype and VC money involved riding the waves of whatever is massively popular. Bigger IT budgets, too, if your proposal doesn't involve using one, mid-range Dell. I'm sure such things have more impact than the technical arguments in many places. ;)

qwertyuiop924 10y ago
There's a reason it's a classic. The best summation I heard of it was, "If you can't get the solution to a problem to fit on one machine, you probably don't understand the problem well enough." This is probably one of my favorite quotes in software. I'm probably slightly misquoting it here, but I don't care.
- nickpsecurity 10y ago
  It's been formalized past that into the COST methodology of assessing distribution solutions: Configuration that Outperforms a Single Thread. If that configuration doesn't exist, just ditch the solution in favor of a single thread. :) http://www.frankmcsherry.org/assets/COST.pdf http://www.frankmcsherry.org/assets/COST.pdf http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html http://www.frankmcsherry.org/graph/scalability/cost/2015/01/... It just gets more hilarious the more you read the measurements of all these tech vs a single thread.
  - qwertyuiop924 10y ago
    A single thread frequently has less code: less code means less code being executed. This is a contributing factor to speed. The less instructions you have to execute, the faster it runs, give or take. Not that instructions executed do not necessarily correlate to code size (a loop is only written once, but executed many times). By the way, bane responded to my original post: it's worth reading.
    - deleted 10y ago
      [deleted]
    - nickpsecurity 10y ago
      His response just loaded on my end for some reason. Yeah, that's the points I was getting from his longer write-up. If you see him redo it & I'm not there, definitely ping me so I can see the future copy. We were actually both in the best example I've seen of this effect on HN: https://news.ycombinator.com/item?id=12472905 https://news.ycombinator.com/item?id=12472905 It's the kind of title that, if proven in resulting article, should make many people pause to think about how effectively they're solving business problems.

bane 10y ago

Aww shucks. Thanks for the shout out. I realize reading this again that I owe a more significant writeup -- I started one not long after this and wasn't happy with how it was shaping up. Maybe I'll have another go at it. Since writing that comment two years ago I've added a couple more examples consistent with the ones in the original post. One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. When they're working with the platform, and hitting the inevitable and unplanned for performance issues (because, you know, just shove the node to the hadoop cluster and it'll magically take care of that), the solutions never tackle the algorithmic bottlenecks but instead seem to focus on messing with the platform or changing platforms, or changing run-time languages or throwing more hardware at it. If you are having trouble taking the nuts off your wheel to change a tire, using a bigger hammer or a blow torth isn't going to help. Take the time to find the wrench, of the right size, and then things will work much better.

qwertyuiop924 10y ago
I mean, you get shoutouts every day. Thanks for responding to this one. >One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. Ahhh yes. The "when X is your hammer" problem. In this context, I think the appropriate incarnation is, "When Hadoop is your hammer, everything looks like 1000 nails to be hit very quickly, using brute force."