8 ms·

What gets me about MOST of the stuff I read on criticising c++ is the complete disregard for runtime performance. I write software that has to consume billions

What gets me about MOST of the stuff I read on criticising c++ is the complete disregard for runtime performance. I write software that has to consume billions of messages a day per instance. I've done it in several languages for different purposes. At the end of the day if you implement the same algorithm in c++ it will be faster. I don't care what you think you can do in node.js, but you are wrong. When you have limited resources there is no option save for c and c++. It isn't a big deal, that is currently how we get things done. People fucking around with distributed web applications are so immune from the specific cost of adding a line of code because rarely is what they are writing executed repeatedly in a tight loop and thus they lose the ability to quickly measure performance impact

terio 13y ago
I find it funny that when I had to switch to C++ I found it slow compared to C and Object-Oriented Pascal. There are also some tradeoffs when switching languages. Some people would never make the move from C to C++ citing unnecessary complexity (e.g. Linus Torvald). This is essentially a question of having the right tool for the job. Switching from C++ to Go is probably a good decision some cases and a bad one in others. But one should not remain so anchored in one language that won't be able to consider some other, probably better, option.
tlb 13y ago
One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing) If your code consumes more than 300 cores, you should care about performance. If your code consumes less, you should care about productivity. Adding cores is easy while adding programmers is hard. Cores scale linearly while programmers don't. So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that.
- anon1385 13y ago
  What on earth makes you think that all problems can be scaled out to as many cores as you like? This is exactly the web developer mindset that people are referring to elsewhere in this thread.
  - raverbashing 13y ago
    "What on earth makes you think that all problems can be scaled out to as many cores as you like" It certainly can't. And for example you can't do that on an app that runs on a phone, for example. But, when possible, this is the cheapest way to do it. Not to mention other cases where it's the "only" way to do it (like, CPU heavy processing, video processing, simulations, etc). A smart developer can help with a %, but with limited returns. For example, Facebook invested on their PHP compiler since their server usage would only increase, and the resources for that gain (in terms of people) are more or less constant.
  - PaulHoule 13y ago
    Well you're trading one kind of B.S. for another kind of B.S. There's a lot of B.S. that comes with C++, and there's an entirely different kind of B.S. involved with writing things in Java + Hadoop. Personally I stay out of the C/C++ ecosystem as much as I can because threads are never really going to work in the GNU world because you can't trust the standard libraries never mind all the other libraries. The LMAX Disruptor shows that if you write code carefully in Java it can scream. They estimate that they could maybe get 10% better throughput in C++ at great cost, but the average C++ programmer would probably screw up the threading and make something buggy, and a C++ programmer that's 2 SD better than the mean would still struggle with cache line and other detailed CPU issues. The difference between the LMAX Disruptor and the "genius grade" C++ I've seen is that the code for the Disruptor is simple and beautiful, whereas you might spend a week and a half just figuring out how to build a "genius grade" C++ program, taking half an hour each pop.
    - cobrausn 13y ago
      The genius of disruptor was in the data structure and access mechanisms, plus the fact that it worked for single producer / single consumer circumstances. It is certainly not an example you can tout for how Java is as fast as C/C++ under all circumstances if you are 'careful'. I think you are just falling prey to confirmation bias w.r.t. 'beauty' of code. Having said that, C++ can be ugly as hell.
      - 13y ago
- dllthomas 13y ago
  > Cores scale linearly while programmers don't. Cores scale linearly, but performance may not scale linearly to cores.
- hobb0001 13y ago
  Not all code is server-side code that can be addressed by elastic computing. Most C++ programmers work on desktop, mobile, and embedded programs. In such a domain, it is very likely that your code will be running on more than 10,000 cores on launch day (and with little or no intercommunication between the cores).
- abelsson 13y ago
  I'm sorry, but I can't outsource the computation of real time ultrasound denoising to EC2. Nor can I do the work of my LTE radio modem on EC2. Clouds and scaling out on clusters are great answer to a certain set of problems, but far from a panacea.
  - tlb 13y ago
    In that case, you are running on >1000 cores and my guideline gives the right answer.
    - figglesonrails 13y ago
      I'm pretty sure ultrasound denoising does not run on > 10000 cores. The point was more of "cloud this, cloud that" solves many types of problems but real-time is not one of them. Cf: why you can't play a game on the cloud by sending JPG screenshots of the rendered scene 60 times per second while polling a joystick at 120 Hz and send that to the cloud.
      - staunch 13y ago
        http://en.wikipedia.org/wiki/Cloud_gaming#Video_streaming http://en.wikipedia.org/wiki/Cloud_gaming#Video_streaming
        figglesonrails 13y ago
        I don't know why you bothered to provide a link and no commentary. This proves that people have attempted it, not that it is common nor that it produces equivalent results. I'm well aware that for some games, it can work "ok". Let me know when you get uncompressed 2K video at 60 FPS and <16 msec input response.
        staunch 13y ago
        You suggested that it couldn't be done for games, so I gave you a link showing you that it can and has been done. There are number of reasons why that isn't a popular way to play games, but it's not primarily a technical issue. You certainly could pull off this architecture in a setting with a good LAN connection. Though I'm not really arguing that it's necessarily a great way to go.
- easytiger 13y ago
  > One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing) That is gibberish. If I work at a company and we have 5 machines with 12 cores apiece already in place that is what I have to make do with. We don't all live in an elastic world. Further to that the scaling of large single computations across cores is a costly and often pointless exercise.
  - PaulHoule 13y ago
    You're lucky. Some places are so inelastic that developers get hand-me-down laptops from sales people who couldn't sell, or when they buy a new machine from Dell they get one with two cores.
    - dekhn 13y ago
      So.... they pay you a salary right? So long as they don't prevent it... you can take some of the money your company allocates to salary, and reallocate it to buying a few cheap VMs.
      - carbocation 13y ago
        You could also contribute to the company's rent payment. It would have a similar wealth transfer effect.
      - mempko 13y ago
        If a company is making a profit, they owe more to you than you to them....
        dekhn 13y ago
        you're profitsharing, right? so if you go around the company's self limiting policies, and make more profit by using your salary... then it's a net win to you.
      - PaulHoule 13y ago
        I was working as an enumerator for the U.S. Census in the year 2000 and one of the people on my team realized that for 2 hours worth of pay she could buy office supplies that would save us all (and the government) 60 hours worth of work. She was stressed because there wasn't any official channel for us to buy office supplies other than the stuff they sent us. I told her to buy the office supplies and say that she worked another 2 hours; this was breaking the rules but this did not strike me as at all unethical. Now, not long after the 2008 crunch I was getting pissed about how long builds took on my cheap laptop (on which I was running both the client and server sides of a complex app). Getting a better machine from management was out of the question, but I liked other aspects of the job, and 2009 wasn't the best time to go job seeking. So I bought myself a top end desktop computer and three inexpensive monitors. When I left that company they wanted to buy the machine off me so as to keep all the proprietary code and data on it, but as things worked out, the value of my own proprietary code and data on that machine was worth a lot to me so I kept it, and fortunately things never went to court. This type of decision has risks (for instance, you don't want to be the guy who loses a machine with social security numbers on it and forces his employer to pay for credit monitoring for 70,000 people) but it can be the right thing to do sometimes.
- twoodfin 13y ago
  What if I'm distributing my code to thousands or millions of users who are going to be running it dozens of times a day? Suddenly, spending an hour to make it run just a few seconds faster looks like a very good trade-off.
  - pault 13y ago
    Right tool for the job, etc etc
- figglesonrails 13y ago
  Depending on how you value things, being able to spend fewer clock cycles may be more "environmentally responsible" in the long run, though data centers do run a pretty tight ship. ;)
- awj 13y ago
  Ok, sweet, so we just need to tell game developers to start packaging additional processors with their games. You need to get out more, you've completely lost perspective.
- cbr 13y ago
  Setting aside the validity of this comparison, keep in mind that Go is coming out of Google, a place where running on 1000 cores is dinky. (Note: I work for Google, but on open-source server software.)
- shin_lao 13y ago
  Cores scale linearly while programmers don't. It does not: http://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_of_Computational_Scalability http://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_o... and http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law Not only it does not but sometimes it doesn't scale at all. Scaling software is a very difficult problem, especially when you have low latency issues. And what happens when you write desktop software? You ask your customers to open Amazon accounts? So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that. In which field do you work?
- speeder 13y ago
  And then how my players (I make games) use more cores? They hire Amazon before playing my physics game? Oh, I know, just put the game in the cloud... Then players will become angry because the game only works when internet works and they cannot play at the underground train while commuting. Sorry, but sometimes I have impression that web developers forget there is other sort of development that exists.
- mempko 13y ago
  This is going to become less true when/if power costs go up
- zeteo 13y ago
  > One programmer costs ~ 300 cores. [...] If your code consumes less [than 300 cores], you should care about productivity. Adding cores is easy while adding programmers is hard. [...] Do not make performance-productivity tradeoffs below [1000 cores]. Computing time is cheap these days, but this kind of math doesn't make any more sense than comparing feet to miles per hour. Programming time saved is a one-time gain, whereas the performance loss in continuous. Let's say you write code for a single core, you spend 10 hours instead of 20 by accepting a 50% slowdown, and manage to compensate by adding an extra core. Depending on how long this code runs, there will be a point at which the ongoing costs of an extra core surpass the one-time saving of 10 hours' programming. If all you need is a working prototype then sure, performance shortcuts may be worthwhile. (Although you can't calculate trade-offs as suggested). But for long-term production systems they will always start hurting at some point.
  - ned_roberts 13y ago
    Unless you never make changes to your software, development time is as continuous as run time. As someone pointed out below, the fact that Google finds value in Go seems to point to there being enough of a cost in development time that they're willing to sacrifice run time to reduce it. That said, what makes sense for Google doesn't necessarily make sense for the rest of us.
    - zeteo 13y ago
      Yeah, as I said it depends on how long the code ends up running. For sections of the code that you end up changing all the time you'll have a much higher proportion of developer time to "running core" time, so you obviously can reduce costs more on the productivity side. But there's no simple, 300-cores-per-developer math for it.
    - waps 13y ago
      Generally I'd say it depends on the component. There are tons of components that never change, at least in my apps. Splitting them off and moving them to java or C++ provides gigantic gains. In practice, I think a lot of programmers simply don't know how to call C/C++ from python, even though it has become so much easier since ctypes. Thus doing this is derided as a waste of time, dangerous and whatever. You'll soon see that doing this has other advantages (like type safety).
- asdasf 13y ago
  >Cores scale linearly You don't seriously think that do you? People struggle with concurrency and parallelism all the time. Tons of problems we have no way to scale up with more CPU cores, it is an open research problem to try to find ways to do so. Pretending that you can just buy fast is a huge mistake that costs millions of dollars.
mathattack 13y ago
With no disrespect intended to the OP, this is an interesting comment considering that he came from Google, which is one of the world's largest beneficiaries of optimized performance. (If there's one place where run time trumps human time...)
consultant23522 13y ago
The number of places in most code where you're running a tight loop a jillion times is vanishingly small. In those cases you're usually better off writing the vast majority of the code in a language that increases developer productivity while writing the occasional C/C++ module when serious single-threaded crunching is required. This is why so many modern higher level languages offer C bindings. The world isn't all or nothing. And this thought isn't specific to Go. The main language could just as easily be Java, Python, PHP, or even (eek) Ruby.
mtkd 13y ago
I think a lot people who are doing (successful) distributed web apps - are learning that performance actually does matter - and it can be painful to optimise poor architectural decisions. People who 5 years ago were sermonising to me on premature optimisation are now telling me they're rewriting something in a faster language or how many millisecs they've saved using some new profiling snake oil they've just bought. (whilst my background is in assembler/C, I now prefer to use prematurely optimised Ruby where possible just for the maintainability and the magic)
- karterk 13y ago
  But optimizing later can also be the smarter thing to do. Especially when you're in the early stages, you don't know what direction your product/company will take. Optimization is a happier problem to have than say, trying to find enough people to sustain your business.
- Pxtl 13y ago
  I think the lesson to learn is that you have to ensure you don't have barriers to optimization as well. Knuth's original statement on premature optimization presupposed that the cost of optimizing later isn't really that much higher than optimizing now. I mean, obviously it's going to be somewhat harder - code is harder to read than to write, and fixing a performance failure is going to take longer than getting it right the first time. But still, that's not a humongous cost and there are so very many opportunities for optimization that chasing them without performance data is a waste of time. But when you have an actual barrier to optimizing? Then you've got a real problem. If you're committed to a technology that has a hard performance ceiling and no easy way to break the slow parts out into another technology? That's a different problem. It seems evident that Knuth's advice about premature optimization can be indiscriminately applied when you're talking about code for an individual component... but should be considered carefully against the potential costs when thinking about large architecture.
  - jfb 13y ago
    People who quote Knuth as aphorism are rarely as smart as Knuth. The optimization quote is great, but it's usually deployed as an appeal to authority to justify a preconceived, ideological decision -- God knows, I've done this. Building software is hard, and it's not at all surprising (or reprehensible) that people will seek out shortcuts to winnow their decision space.

terio 13y ago

I find it funny that when I had to switch to C++ I found it slow compared to C and Object-Oriented Pascal. There are also some tradeoffs when switching languages. Some people would never make the move from C to C++ citing unnecessary complexity (e.g. Linus Torvald). This is essentially a question of having the right tool for the job. Switching from C++ to Go is probably a good decision some cases and a bad one in others. But one should not remain so anchored in one language that won't be able to consider some other, probably better, option.

tlb 13y ago

One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing) If your code consumes more than 300 cores, you should care about performance. If your code consumes less, you should care about productivity. Adding cores is easy while adding programmers is hard. Cores scale linearly while programmers don't. So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that.

anon1385 13y ago
What on earth makes you think that all problems can be scaled out to as many cores as you like? This is exactly the web developer mindset that people are referring to elsewhere in this thread.
- raverbashing 13y ago
  "What on earth makes you think that all problems can be scaled out to as many cores as you like" It certainly can't. And for example you can't do that on an app that runs on a phone, for example. But, when possible, this is the cheapest way to do it. Not to mention other cases where it's the "only" way to do it (like, CPU heavy processing, video processing, simulations, etc). A smart developer can help with a %, but with limited returns. For example, Facebook invested on their PHP compiler since their server usage would only increase, and the resources for that gain (in terms of people) are more or less constant.
- PaulHoule 13y ago
  Well you're trading one kind of B.S. for another kind of B.S. There's a lot of B.S. that comes with C++, and there's an entirely different kind of B.S. involved with writing things in Java + Hadoop. Personally I stay out of the C/C++ ecosystem as much as I can because threads are never really going to work in the GNU world because you can't trust the standard libraries never mind all the other libraries. The LMAX Disruptor shows that if you write code carefully in Java it can scream. They estimate that they could maybe get 10% better throughput in C++ at great cost, but the average C++ programmer would probably screw up the threading and make something buggy, and a C++ programmer that's 2 SD better than the mean would still struggle with cache line and other detailed CPU issues. The difference between the LMAX Disruptor and the "genius grade" C++ I've seen is that the code for the Disruptor is simple and beautiful, whereas you might spend a week and a half just figuring out how to build a "genius grade" C++ program, taking half an hour each pop.
  - cobrausn 13y ago
    The genius of disruptor was in the data structure and access mechanisms, plus the fact that it worked for single producer / single consumer circumstances. It is certainly not an example you can tout for how Java is as fast as C/C++ under all circumstances if you are 'careful'. I think you are just falling prey to confirmation bias w.r.t. 'beauty' of code. Having said that, C++ can be ugly as hell.
    - 13y ago
dllthomas 13y ago
> Cores scale linearly while programmers don't. Cores scale linearly, but performance may not scale linearly to cores.
hobb0001 13y ago
Not all code is server-side code that can be addressed by elastic computing. Most C++ programmers work on desktop, mobile, and embedded programs. In such a domain, it is very likely that your code will be running on more than 10,000 cores on launch day (and with little or no intercommunication between the cores).
abelsson 13y ago
I'm sorry, but I can't outsource the computation of real time ultrasound denoising to EC2. Nor can I do the work of my LTE radio modem on EC2. Clouds and scaling out on clusters are great answer to a certain set of problems, but far from a panacea.
- tlb 13y ago
  In that case, you are running on >1000 cores and my guideline gives the right answer.
  - figglesonrails 13y ago
    I'm pretty sure ultrasound denoising does not run on > 10000 cores. The point was more of "cloud this, cloud that" solves many types of problems but real-time is not one of them. Cf: why you can't play a game on the cloud by sending JPG screenshots of the rendered scene 60 times per second while polling a joystick at 120 Hz and send that to the cloud.
    - staunch 13y ago
      http://en.wikipedia.org/wiki/Cloud_gaming#Video_streaming http://en.wikipedia.org/wiki/Cloud_gaming#Video_streaming
      - figglesonrails 13y ago
        I don't know why you bothered to provide a link and no commentary. This proves that people have attempted it, not that it is common nor that it produces equivalent results. I'm well aware that for some games, it can work "ok". Let me know when you get uncompressed 2K video at 60 FPS and <16 msec input response.
        staunch 13y ago
        You suggested that it couldn't be done for games, so I gave you a link showing you that it can and has been done. There are number of reasons why that isn't a popular way to play games, but it's not primarily a technical issue. You certainly could pull off this architecture in a setting with a good LAN connection. Though I'm not really arguing that it's necessarily a great way to go.
easytiger 13y ago
> One programmer costs ~ 300 cores. (Bay Area salary with benefits vs. AWS EC2 pricing) That is gibberish. If I work at a company and we have 5 machines with 12 cores apiece already in place that is what I have to make do with. We don't all live in an elastic world. Further to that the scaling of large single computations across cores is a costly and often pointless exercise.
- PaulHoule 13y ago
  You're lucky. Some places are so inelastic that developers get hand-me-down laptops from sales people who couldn't sell, or when they buy a new machine from Dell they get one with two cores.
  - dekhn 13y ago
    So.... they pay you a salary right? So long as they don't prevent it... you can take some of the money your company allocates to salary, and reallocate it to buying a few cheap VMs.
    - carbocation 13y ago
      You could also contribute to the company's rent payment. It would have a similar wealth transfer effect.
    - mempko 13y ago
      If a company is making a profit, they owe more to you than you to them....
      - dekhn 13y ago
        you're profitsharing, right? so if you go around the company's self limiting policies, and make more profit by using your salary... then it's a net win to you.
    - PaulHoule 13y ago
      I was working as an enumerator for the U.S. Census in the year 2000 and one of the people on my team realized that for 2 hours worth of pay she could buy office supplies that would save us all (and the government) 60 hours worth of work. She was stressed because there wasn't any official channel for us to buy office supplies other than the stuff they sent us. I told her to buy the office supplies and say that she worked another 2 hours; this was breaking the rules but this did not strike me as at all unethical. Now, not long after the 2008 crunch I was getting pissed about how long builds took on my cheap laptop (on which I was running both the client and server sides of a complex app). Getting a better machine from management was out of the question, but I liked other aspects of the job, and 2009 wasn't the best time to go job seeking. So I bought myself a top end desktop computer and three inexpensive monitors. When I left that company they wanted to buy the machine off me so as to keep all the proprietary code and data on it, but as things worked out, the value of my own proprietary code and data on that machine was worth a lot to me so I kept it, and fortunately things never went to court. This type of decision has risks (for instance, you don't want to be the guy who loses a machine with social security numbers on it and forces his employer to pay for credit monitoring for 70,000 people) but it can be the right thing to do sometimes.
twoodfin 13y ago
What if I'm distributing my code to thousands or millions of users who are going to be running it dozens of times a day? Suddenly, spending an hour to make it run just a few seconds faster looks like a very good trade-off.
- pault 13y ago
  Right tool for the job, etc etc
figglesonrails 13y ago
Depending on how you value things, being able to spend fewer clock cycles may be more "environmentally responsible" in the long run, though data centers do run a pretty tight ship. ;)
awj 13y ago
Ok, sweet, so we just need to tell game developers to start packaging additional processors with their games. You need to get out more, you've completely lost perspective.
cbr 13y ago
Setting aside the validity of this comparison, keep in mind that Go is coming out of Google, a place where running on 1000 cores is dinky. (Note: I work for Google, but on open-source server software.)
shin_lao 13y ago
Cores scale linearly while programmers don't. It does not: http://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_of_Computational_Scalability http://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_o... and http://en.wikipedia.org/wiki/Amdahl%27s_law http://en.wikipedia.org/wiki/Amdahl%27s_law Not only it does not but sometimes it doesn't scale at all. Scaling software is a very difficult problem, especially when you have low latency issues. And what happens when you write desktop software? You ask your customers to open Amazon accounts? So I set the guideline at 1000 cores. Do not make performance-productivity tradeoffs below that. In which field do you work?
speeder 13y ago
And then how my players (I make games) use more cores? They hire Amazon before playing my physics game? Oh, I know, just put the game in the cloud... Then players will become angry because the game only works when internet works and they cannot play at the underground train while commuting. Sorry, but sometimes I have impression that web developers forget there is other sort of development that exists.
mempko 13y ago
This is going to become less true when/if power costs go up
zeteo 13y ago
> One programmer costs ~ 300 cores. [...] If your code consumes less [than 300 cores], you should care about productivity. Adding cores is easy while adding programmers is hard. [...] Do not make performance-productivity tradeoffs below [1000 cores]. Computing time is cheap these days, but this kind of math doesn't make any more sense than comparing feet to miles per hour. Programming time saved is a one-time gain, whereas the performance loss in continuous. Let's say you write code for a single core, you spend 10 hours instead of 20 by accepting a 50% slowdown, and manage to compensate by adding an extra core. Depending on how long this code runs, there will be a point at which the ongoing costs of an extra core surpass the one-time saving of 10 hours' programming. If all you need is a working prototype then sure, performance shortcuts may be worthwhile. (Although you can't calculate trade-offs as suggested). But for long-term production systems they will always start hurting at some point.
- ned_roberts 13y ago
  Unless you never make changes to your software, development time is as continuous as run time. As someone pointed out below, the fact that Google finds value in Go seems to point to there being enough of a cost in development time that they're willing to sacrifice run time to reduce it. That said, what makes sense for Google doesn't necessarily make sense for the rest of us.
  - zeteo 13y ago
    Yeah, as I said it depends on how long the code ends up running. For sections of the code that you end up changing all the time you'll have a much higher proportion of developer time to "running core" time, so you obviously can reduce costs more on the productivity side. But there's no simple, 300-cores-per-developer math for it.
  - waps 13y ago
    Generally I'd say it depends on the component. There are tons of components that never change, at least in my apps. Splitting them off and moving them to java or C++ provides gigantic gains. In practice, I think a lot of programmers simply don't know how to call C/C++ from python, even though it has become so much easier since ctypes. Thus doing this is derided as a waste of time, dangerous and whatever. You'll soon see that doing this has other advantages (like type safety).
asdasf 13y ago
>Cores scale linearly You don't seriously think that do you? People struggle with concurrency and parallelism all the time. Tons of problems we have no way to scale up with more CPU cores, it is an open research problem to try to find ways to do so. Pretending that you can just buy fast is a huge mistake that costs millions of dollars.

mathattack 13y ago

With no disrespect intended to the OP, this is an interesting comment considering that he came from Google, which is one of the world's largest beneficiaries of optimized performance. (If there's one place where run time trumps human time...)

consultant23522 13y ago

The number of places in most code where you're running a tight loop a jillion times is vanishingly small. In those cases you're usually better off writing the vast majority of the code in a language that increases developer productivity while writing the occasional C/C++ module when serious single-threaded crunching is required. This is why so many modern higher level languages offer C bindings. The world isn't all or nothing. And this thought isn't specific to Go. The main language could just as easily be Java, Python, PHP, or even (eek) Ruby.

mtkd 13y ago

I think a lot people who are doing (successful) distributed web apps - are learning that performance actually does matter - and it can be painful to optimise poor architectural decisions. People who 5 years ago were sermonising to me on premature optimisation are now telling me they're rewriting something in a faster language or how many millisecs they've saved using some new profiling snake oil they've just bought. (whilst my background is in assembler/C, I now prefer to use prematurely optimised Ruby where possible just for the maintainability and the magic)

karterk 13y ago
But optimizing later can also be the smarter thing to do. Especially when you're in the early stages, you don't know what direction your product/company will take. Optimization is a happier problem to have than say, trying to find enough people to sustain your business.
Pxtl 13y ago
I think the lesson to learn is that you have to ensure you don't have barriers to optimization as well. Knuth's original statement on premature optimization presupposed that the cost of optimizing later isn't really that much higher than optimizing now. I mean, obviously it's going to be somewhat harder - code is harder to read than to write, and fixing a performance failure is going to take longer than getting it right the first time. But still, that's not a humongous cost and there are so very many opportunities for optimization that chasing them without performance data is a waste of time. But when you have an actual barrier to optimizing? Then you've got a real problem. If you're committed to a technology that has a hard performance ceiling and no easy way to break the slow parts out into another technology? That's a different problem. It seems evident that Knuth's advice about premature optimization can be indiscriminately applied when you're talking about code for an individual component... but should be considered carefully against the potential costs when thinking about large architecture.
- jfb 13y ago
  People who quote Knuth as aphorism are rarely as smart as Knuth. The optimization quote is great, but it's usually deployed as an appeal to authority to justify a preconceived, ideological decision -- God knows, I've done this. Building software is hard, and it's not at all surprising (or reprehensible) that people will seek out shortcuts to winnow their decision space.