4 ms·

If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Well, that depends on the value of n,

If your overpaid programmers are writing O(n^2) algorithms then that cheap hardware is going to get expensive real quick. Well, that depends on the value of n, right? Not every piece of software is Google or Twitter: They don't all have a userbase that grows virally to encompass every breathing human in existence, plus animals and robots. Especially if you charge the users money.

gaius 18y ago
It's not just about users because there are no users; there's just data. Any data, the same thing applies.
gnaritas 18y ago
Not every piece of software is Google or Twitter: Worse, almost all software isn't like a Google or Twitter. In almost all cases hardware is vastly cheaper than programmers. The Googles and Twitters of the world are extreme outliers and are no where near the median.
- axod 18y ago
  I don't believe that's true. Google sure, but twitter is just another message routing system, like any one of the IM networks. The average irc server probably handles more than twitter - certainly email software does. There's a ton of software that needs to scale, and be able to handle a large volume of data.
  - mechanical_fish 18y ago
    Twitter is not "just a messaging system". See: http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi.html http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi... (Many thanks to Eran Hammer-Lahav for writing this so that I don't have to.)
    - axod 18y ago
      I respectfully disagree. It's a simple message passing system, of which there are a ton of examples. This isn't rocket science. The problem is that where once it would have been written in c as a server, it's now written with big databases and 'popular' languages - so it's harder to scale.
      - kragen 18y ago
        It would have taken longer to get working in C, which would have dramatically increased the probability that the project would have gotten killed before it saw users (it sounded like a pretty stupid site to me at first!), and it would be harder to rev the UI and features as often as they did before they hit the scaling problems. But a message server in Ruby with Eventmachine wouldn't have been that hard, would it?
      - gaius 18y ago
        True. IBM have basically solved messaging with MQseries running on OS/390. All that remains is do that, only cheaper.
        seiji 18y ago
        Proprietary message queues are a huge problem (and a huge business). There are better ways: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... For a good introduction check out http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-at-google-london.html http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-...
  - gnaritas 18y ago
    There's a ton of software that needs to scale Yes, but there's vastly more that doesn't, you need to stop thinking that most software runs on the Internet and has tons of users, it doesn't. The vast majority of software is written for businesses and runs either on an intranet or is available on the internet to the users of that business. For every public app you know about that needs to scale there are a hundred you don't know about that don't need to scale. Most programmers work on systems that will never need to scale, EVER. It is a tiny tiny minority of programmers that actually work on systems that become publicly popular on the Internet and actually face scaling issues. Secondly, we're talking about programmers here, not the software, most email systems use existing mail software written by that tiny tiny minority of programmers who write such systems. The vast majority of programmers will NEVER write a mail system, a chat system, or anything that handles large volumes of data or users. Most of them of doing one thing, biz apps for in house projects at big and small companies exposing relational data to in house users. How many IM networks are there? Now how many programmers are there? I'll say it again, most software does not need to scale. Because a lot of software does need to scale does not make that statement in any way false because a shit load more doesn't need to scale.
    - gaius 18y ago
      The vast majority of software is written for businesses and runs either on an intranet or is available on the internet to the users of that business. That doesn't mean a thing in terms of scalability. One user can max out a fast machine with OLAP cubes or other DSS. Or any sort of simulation or modeling. Think in terms of datasets, not in terms of users (all many users are is a large dataset with a requirement for a quick turnaround of each computation).
      - gnaritas 18y ago
        If an app only has one user, it doesn't need to scale, it needs to perform. Scalability is all about users and only loosely related to performance. Datasets are irrelevant.
        sadfsa 18y ago
orib 18y ago
If you can determine an upper bound on n, then your algorithm is technically O(1), and you don't have to worry about scaling. If you want to be able to handle any value of n, and expect it to be large, you should care about O(n^2) algorithms. You don't have to necessarily get rid of them all at once, but you should at least know where they exist and have them listed as possible pain points or places to start optimizing.

gaius 18y ago

It's not just about users because there are no users; there's just data. Any data, the same thing applies.

gnaritas 18y ago

Not every piece of software is Google or Twitter: Worse, almost all software isn't like a Google or Twitter. In almost all cases hardware is vastly cheaper than programmers. The Googles and Twitters of the world are extreme outliers and are no where near the median.

axod 18y ago
I don't believe that's true. Google sure, but twitter is just another message routing system, like any one of the IM networks. The average irc server probably handles more than twitter - certainly email software does. There's a ton of software that needs to scale, and be able to handle a large volume of data.
- mechanical_fish 18y ago
  Twitter is not "just a messaging system". See: http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi.html http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi... (Many thanks to Eran Hammer-Lahav for writing this so that I don't have to.)
  - axod 18y ago
    I respectfully disagree. It's a simple message passing system, of which there are a ton of examples. This isn't rocket science. The problem is that where once it would have been written in c as a server, it's now written with big databases and 'popular' languages - so it's harder to scale.
    - kragen 18y ago
      It would have taken longer to get working in C, which would have dramatically increased the probability that the project would have gotten killed before it saw users (it sounded like a pretty stupid site to me at first!), and it would be harder to rev the UI and features as often as they did before they hit the scaling problems. But a message server in Ruby with Eventmachine wouldn't have been that hard, would it?
    - gaius 18y ago
      True. IBM have basically solved messaging with MQseries running on OS/390. All that remains is do that, only cheaper.
      - seiji 18y ago
        Proprietary message queues are a huge problem (and a huge business). There are better ways: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc... For a good introduction check out http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-at-google-london.html http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-...
- gnaritas 18y ago
  There's a ton of software that needs to scale Yes, but there's vastly more that doesn't, you need to stop thinking that most software runs on the Internet and has tons of users, it doesn't. The vast majority of software is written for businesses and runs either on an intranet or is available on the internet to the users of that business. For every public app you know about that needs to scale there are a hundred you don't know about that don't need to scale. Most programmers work on systems that will never need to scale, EVER. It is a tiny tiny minority of programmers that actually work on systems that become publicly popular on the Internet and actually face scaling issues. Secondly, we're talking about programmers here, not the software, most email systems use existing mail software written by that tiny tiny minority of programmers who write such systems. The vast majority of programmers will NEVER write a mail system, a chat system, or anything that handles large volumes of data or users. Most of them of doing one thing, biz apps for in house projects at big and small companies exposing relational data to in house users. How many IM networks are there? Now how many programmers are there? I'll say it again, most software does not need to scale. Because a lot of software does need to scale does not make that statement in any way false because a shit load more doesn't need to scale.
  - gaius 18y ago
    The vast majority of software is written for businesses and runs either on an intranet or is available on the internet to the users of that business. That doesn't mean a thing in terms of scalability. One user can max out a fast machine with OLAP cubes or other DSS. Or any sort of simulation or modeling. Think in terms of datasets, not in terms of users (all many users are is a large dataset with a requirement for a quick turnaround of each computation).
    - gnaritas 18y ago
      If an app only has one user, it doesn't need to scale, it needs to perform. Scalability is all about users and only loosely related to performance. Datasets are irrelevant.
      - sadfsa 18y ago

orib 18y ago

If you can determine an upper bound on n, then your algorithm is technically O(1), and you don't have to worry about scaling. If you want to be able to handle any value of n, and expect it to be large, you should care about O(n^2) algorithms. You don't have to necessarily get rid of them all at once, but you should at least know where they exist and have them listed as possible pain points or places to start optimizing.