6 ms·

> For these we don't really need optimizations. While it's true that many sites with high volume are written in high level languages, it's still true that thes

> For these we don't really need optimizations. While it's true that many sites with high volume are written in high level languages, it's still true that these will require more CPU and memory than something which is highly optimized written in a lower level language. The trade-off is that it takes less developer time to write code in the high level language and the savings there are enough to invest in more computing power. However, if you can optimize code for high level languages even further, you're still reducing the hardware requirements and ultimately saving costs. If you can build a stable Ruby VM that runs with 10% fewer resources and is compatible with existing applications, I think you'll find people willing to throw money your way.

userbinator 8y ago
The trade-off is that it takes less developer time to write code in the high level language and the savings there are enough to invest in more computing power. Not if your application is being used by many users; optimising exclusively for development time is only for rarely-used/one-off things or if you don't value your user's time --- some of whom may be themselves developers. The more users you have, the more it matters. We've somehow gotten ourselves into a situation where relatively few developers are making countless more users waste time and hardware resources for their own selfish benefit, and I think that's a very bad thing.
- pjmlp 8y ago
  I think it is a matter of saving resources on language design until it matters, not always a good decision. Take Java for example. When it came into scene we had Oberon and its variants, Ada, Modula-3 and Eiffel. All supported JIT/AOT compilation, value types, and with exception of Oberon, generics. Most of the last changes at the JVM level, and the upcoming ones on Java's roadmap are basically catching up with what was already possible in the mid-90's. So how much money could Sun, Oracle and IBM have saved if those features were there from the beginning? We will never know, but we will know how much the bill is going to be, given that it is 10+ year process currently. All because the current hardware changes make it impossible for Java to continue to ignore those features, if it is to stay relevant against other languages. Same applies to other languages in different ways.
  - hyperman1 8y ago
    So the question becomes: If Java is today still catching up with a list of 90s languages, why is it used instead of them? Part of the answer is that Java still advance the state of the art for most people: It got safety and garbage collection accepted by the mainstream. Oberon etc were not in reach for the average Joe, the tooling was too expensive and the cheap, resource constrained PCs couldn't run it. The language required sophistication from the programmers. Nobody was available to answer questions, the ecosystem wasn't there. Java, o.t.o.h. had something for everybody. It was safer than C, important if you wanted a stable web server. It was faster than perl or shell scripting, so you also had a cheap web server. The browser got nicer graphics from applets. Enterprise architecture got a way forward from CORBA to JEE without having to admit something was wrong. Hardware vendors got a way to stay relevant in the face of Windows. Tooling vendors and consulting companies got a reason to sell. Managers got cogweel replaceable programmers. Schools got a reasonable and vendor-neutral language. Even if none of promises was completely fulfilled, it was close enough long enough. So basically the language design resources for Oberon were in the end more wasted than those on Java. 'Worse is better' once again.
    - microtherion 8y ago
      > Oberon etc were not in reach for the average Joe, the tooling was too expensive and the cheap, resource constrained PCs couldn't run it. I'm sorry, but that's just nonsense. You can argue lack of documentation and user community, but Oberon is about as resource economic as it gets, and was originally designed for mid-80s hardware. https://en.wikipedia.org/wiki/Ceres_(workstation) https://en.wikipedia.org/wiki/Ceres_(workstation)
      - hyperman1 8y ago
        And where was the oberon tooling for x86 dos or win98. Im not saying it was impossible to create, but nobody seems to have cared enought to do it, to get it in the hands of the user at an affordable price
        8y ago
- naasking 8y ago
  > optimising exclusively for development time is only for rarely-used/one-off things or if you don't value your user's time Not true, because the lower-level languages introduce far more bugs which wastes user time even more because they can't get their work done. Lower level languages these days are only used where performance and resource use must be controlled for. With Rust, that too will soon be a thing of the past.
- michaelmior 8y ago
  I think that certainly can be true. But it also depends on how fast the application is changing. If you have a stable portion of the code base that sees significant traffic, by all means invest the time in optimizing. But it can be hard to keep up if you're in an environment where you're trying and iteratively adapting on a daily basis.
- ksec 8y ago
  For every languages and frameworks, there will always be a tipping point where the cost outweighs the benefits and vice versa. For example you could get your product or services up and running in Ruby Rails with least amount of time, but I doubt it will ever be as efficient as Stack Exchange in resources. [1] and likely will cost a lot more reaching that scale. [1] https://stackexchange.com/performance https://stackexchange.com/performance
  - Timmah 8y ago
    I don't understand why there can't be a type of "dynamic analysis " done on higher level languages that analyzes them and tries to substitute lower level code that does the same thing. Like an AI agent that says "hmm this behavior is very map-like, I'll try replacing it with a std::map" or "80 / 100 of these functions are never called. I'll just remove them from the program image to save load time and locality of reference". And in before "it'll just crash". Have the agent throw an exception that is picked up and dynamically loads the old program image, resulting in a one time delay.
    - austin_y 8y ago
      What you described sounds to me like a just-in-time (JIT) compiler! https://en.wikipedia.org/wiki/Just-in-time_compilation https://en.wikipedia.org/wiki/Just-in-time_compilation
    - friday99 8y ago
      Note, "80 / 100 of these functions are never called. I'll just remove them from the program image to save load time and locality of reference" is already an optimization compilers apply: dead code elimination. https://en.wikipedia.org/wiki/Dead_code_elimination https://en.wikipedia.org/wiki/Dead_code_elimination
      - Timmah 8y ago
        I know that for a language like c++, the compiler can prune dead code. But I mean for the often-lamented "4gb-electron text editor" something that could nibble away at the redundancy gradually during runtime, dynamically reducing and refactoring. Until it approaches the efficiency of a native compiled application.
- pcwalton 8y ago
  Development time is a proxy for being able to adapt and evolve quickly, which is ultimately to users' benefit. The computing world would be in a much worse place if developers micro-optimized everything.
- dwild 8y ago
  You ignore completely how is invested the time gained by the developer. Sure you can shave seconds over a few tasks, but a new feature or a new software altogether could save hours on others process. That's how the time of the developer is invested. It's to get a process that takes HOURS to a few minutes versus getting a page that takes SECONDS to a few microseconds. Same goes for the hardware resource. Changing to a bigger server cost less than than my time. That way again my time can save more time on useful stuff. There's billions of hours wasted in business and government in long and meaningless tasks. Optimize that first please before micro optimizing your software.
scott_s 8y ago
What are you quoting? I can't find that anywhere in the paper. The closest I could find (first paragraph of section 4) agrees with the point you're making. edit: Now I understand you're probably replying to a comment (https://news.ycombinator.com/item?id=17950490 https://news.ycombinator.com/item?id=17950490), and probably accidentally made your response a top-level comment.
- michaelmior 8y ago
  Yes, that's what happened. I was using a HN app on my phone and I fat fingered the wrong reply button :(
rurban 8y ago
I maintain the perl compiler which is used in 70% of the world hosted websites. It enables you to write in a very high level language with tons of libraries, and reduces resources by a factor of 10-20%. Without using the optimizing compiler yet. The current focus is on improving the underlying VM, cperl, a fork of perl5, to enable most traditional optimizations, such as types, compile-time classes, inlining, loop unrolling, lazy parsing, type tracing, ... The optimized compiler or jit would then be about 4x faster, while still keeping the memory resources down. Recent efforts with static perfect hashes for const unicode data brought down memory by factor 10. But money is not flowing, on the contrary, it was taken away, so we will see. The dynamic language communities are very hostile to compile-time optimizations. only recently type hints got adopted. but there's so much more to do.

userbinator 8y ago

The trade-off is that it takes less developer time to write code in the high level language and the savings there are enough to invest in more computing power. Not if your application is being used by many users; optimising exclusively for development time is only for rarely-used/one-off things or if you don't value your user's time --- some of whom may be themselves developers. The more users you have, the more it matters. We've somehow gotten ourselves into a situation where relatively few developers are making countless more users waste time and hardware resources for their own selfish benefit, and I think that's a very bad thing.

pjmlp 8y ago
I think it is a matter of saving resources on language design until it matters, not always a good decision. Take Java for example. When it came into scene we had Oberon and its variants, Ada, Modula-3 and Eiffel. All supported JIT/AOT compilation, value types, and with exception of Oberon, generics. Most of the last changes at the JVM level, and the upcoming ones on Java's roadmap are basically catching up with what was already possible in the mid-90's. So how much money could Sun, Oracle and IBM have saved if those features were there from the beginning? We will never know, but we will know how much the bill is going to be, given that it is 10+ year process currently. All because the current hardware changes make it impossible for Java to continue to ignore those features, if it is to stay relevant against other languages. Same applies to other languages in different ways.
- hyperman1 8y ago
  So the question becomes: If Java is today still catching up with a list of 90s languages, why is it used instead of them? Part of the answer is that Java still advance the state of the art for most people: It got safety and garbage collection accepted by the mainstream. Oberon etc were not in reach for the average Joe, the tooling was too expensive and the cheap, resource constrained PCs couldn't run it. The language required sophistication from the programmers. Nobody was available to answer questions, the ecosystem wasn't there. Java, o.t.o.h. had something for everybody. It was safer than C, important if you wanted a stable web server. It was faster than perl or shell scripting, so you also had a cheap web server. The browser got nicer graphics from applets. Enterprise architecture got a way forward from CORBA to JEE without having to admit something was wrong. Hardware vendors got a way to stay relevant in the face of Windows. Tooling vendors and consulting companies got a reason to sell. Managers got cogweel replaceable programmers. Schools got a reasonable and vendor-neutral language. Even if none of promises was completely fulfilled, it was close enough long enough. So basically the language design resources for Oberon were in the end more wasted than those on Java. 'Worse is better' once again.
  - microtherion 8y ago
    > Oberon etc were not in reach for the average Joe, the tooling was too expensive and the cheap, resource constrained PCs couldn't run it. I'm sorry, but that's just nonsense. You can argue lack of documentation and user community, but Oberon is about as resource economic as it gets, and was originally designed for mid-80s hardware. https://en.wikipedia.org/wiki/Ceres_(workstation) https://en.wikipedia.org/wiki/Ceres_(workstation)
    - hyperman1 8y ago
      And where was the oberon tooling for x86 dos or win98. Im not saying it was impossible to create, but nobody seems to have cared enought to do it, to get it in the hands of the user at an affordable price
      - 8y ago
naasking 8y ago
> optimising exclusively for development time is only for rarely-used/one-off things or if you don't value your user's time Not true, because the lower-level languages introduce far more bugs which wastes user time even more because they can't get their work done. Lower level languages these days are only used where performance and resource use must be controlled for. With Rust, that too will soon be a thing of the past.
michaelmior 8y ago
I think that certainly can be true. But it also depends on how fast the application is changing. If you have a stable portion of the code base that sees significant traffic, by all means invest the time in optimizing. But it can be hard to keep up if you're in an environment where you're trying and iteratively adapting on a daily basis.
ksec 8y ago
For every languages and frameworks, there will always be a tipping point where the cost outweighs the benefits and vice versa. For example you could get your product or services up and running in Ruby Rails with least amount of time, but I doubt it will ever be as efficient as Stack Exchange in resources. [1] and likely will cost a lot more reaching that scale. [1] https://stackexchange.com/performance https://stackexchange.com/performance
- Timmah 8y ago
  I don't understand why there can't be a type of "dynamic analysis " done on higher level languages that analyzes them and tries to substitute lower level code that does the same thing. Like an AI agent that says "hmm this behavior is very map-like, I'll try replacing it with a std::map" or "80 / 100 of these functions are never called. I'll just remove them from the program image to save load time and locality of reference". And in before "it'll just crash". Have the agent throw an exception that is picked up and dynamically loads the old program image, resulting in a one time delay.
  - austin_y 8y ago
    What you described sounds to me like a just-in-time (JIT) compiler! https://en.wikipedia.org/wiki/Just-in-time_compilation https://en.wikipedia.org/wiki/Just-in-time_compilation
  - friday99 8y ago
    Note, "80 / 100 of these functions are never called. I'll just remove them from the program image to save load time and locality of reference" is already an optimization compilers apply: dead code elimination. https://en.wikipedia.org/wiki/Dead_code_elimination https://en.wikipedia.org/wiki/Dead_code_elimination
    - Timmah 8y ago
      I know that for a language like c++, the compiler can prune dead code. But I mean for the often-lamented "4gb-electron text editor" something that could nibble away at the redundancy gradually during runtime, dynamically reducing and refactoring. Until it approaches the efficiency of a native compiled application.
pcwalton 8y ago
Development time is a proxy for being able to adapt and evolve quickly, which is ultimately to users' benefit. The computing world would be in a much worse place if developers micro-optimized everything.
dwild 8y ago
You ignore completely how is invested the time gained by the developer. Sure you can shave seconds over a few tasks, but a new feature or a new software altogether could save hours on others process. That's how the time of the developer is invested. It's to get a process that takes HOURS to a few minutes versus getting a page that takes SECONDS to a few microseconds. Same goes for the hardware resource. Changing to a bigger server cost less than than my time. That way again my time can save more time on useful stuff. There's billions of hours wasted in business and government in long and meaningless tasks. Optimize that first please before micro optimizing your software.

scott_s 8y ago

What are you quoting? I can't find that anywhere in the paper. The closest I could find (first paragraph of section 4) agrees with the point you're making. edit: Now I understand you're probably replying to a comment (https://news.ycombinator.com/item?id=17950490 https://news.ycombinator.com/item?id=17950490), and probably accidentally made your response a top-level comment.

michaelmior 8y ago
Yes, that's what happened. I was using a HN app on my phone and I fat fingered the wrong reply button :(

rurban 8y ago

I maintain the perl compiler which is used in 70% of the world hosted websites. It enables you to write in a very high level language with tons of libraries, and reduces resources by a factor of 10-20%. Without using the optimizing compiler yet. The current focus is on improving the underlying VM, cperl, a fork of perl5, to enable most traditional optimizations, such as types, compile-time classes, inlining, loop unrolling, lazy parsing, type tracing, ... The optimized compiler or jit would then be about 4x faster, while still keeping the memory resources down. Recent efforts with static perfect hashes for const unicode data brought down memory by factor 10. But money is not flowing, on the contrary, it was taken away, so we will see. The dynamic language communities are very hostile to compile-time optimizations. only recently type hints got adopted. but there's so much more to do.