4 ms·

trust a language that ... Where's the problem? JIT compilers work. Most high-level languages require compiler tricks for achieving performance from Scala to

by mafribe 10y ago

trust a language that ... Where's the problem? JIT compilers work. Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog. It's useful to distinguish between (1) having a clean, easy to understand semantics and (2) having a fast implementation. Use all the hackery in the world to get your language fast, as long as it's abstract semantics is easy and canonical.

catnaroek 10y ago
> Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog. To make things perfectly clear: I'm not against optimizations being performed automatically by compilers or runtime systems. What I'm against is unclean designs: deliberately performing an unsound optimization and then rolling it back is an unclean design. > Use all the hackery in the world to get your language fast, The language implementation is a program itself, and I don't have any good reasons to trust a hackish language implementation any more than I trust other hackish programs - that is, not at all. > as long as it's abstract semantics is easy and canonical. Hah! This thread is about JavaScript.
- mafribe 10y ago
  is an unclean design. It's not unsound. Otherwise you'det g incorrect results. You could say the design is wasteful, because you optimise and then throw away the optimisation. But it's hard to do better for some kinds of languages. trust a hackish language implementation I agree. And indeed JIT compilers are hard to get right. But in practise even JIT compilers are much higher quality than applications: ask yourself, how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes?
  - catnaroek 10y ago
    > It's not unsound. Otherwise you'd incorrect results. You could say it's wasteful, because you optimise and then throw away the optimisation. The optimization is unsound. If it weren't, it wouldn't have to be rolled back occasionally. If you're talking about the combination of the optimization and the rollback mechanism, it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you. > how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes? Of course, most were my mistakes. But the very reason why those bugs made it into the final executable is the lack of powerful static analyses in the first place. Curiously enough, when I use languages that make static analyses possible, I write programs with less bugs and they perform better without relying on fancy runtime system tricks. --- Sorry, can't reply to you guys, because “I'm submitting too fast”. So my replies go here: @mafribe: > That's an orthogonal issue. It's not. Static analyses gather valuable information that can be used to emit efficient code. > More powerful static analysis is also more time-consuming. So perform it ahead of time! > One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis. Of course, a browser can't spend much time statically analyzing JavaScript programs, but programs can be statically analyzed (gasp!) before they're deployed. --- @smallnamespace: > Why does that matter to anyone? Because this implementation technique is unnecessarily complex, and a far simpler alternative exists: Know beforehand what your program has to do. Think before you write code. > Java and C# are both statically, strongly typed languages where JITs are the dominant implementation. Their type systems can be easily subverted, so they're not “strongly typed” in my book. --- @smallnamespace: Oops, sorry, I accidentally swapped my two replies to you: this one and https://news.ycombinator.com/item?id=12481956 https://news.ycombinator.com/item?id=12481956 .
    - mafribe 10y ago
      The optimization is unsound. The JIT compiler is sound, w.r.t. to the source language's semantics. That's the only thing that matters for the programmer. but it's inelegant. Elegance is in the eye of the beholder. I was blown away when I first encountered JIT compilers. lack of powerful static analyses That's an orthogonal issue. More powerful static analysis is also more time-consuming. One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis.
    - smallnamespace 10y ago
      > it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you. This is a false dichotomy. You can always build a JIT that uses runtime statistics to speed things up, even in languages that are quite amenable to static analysis, for the simple reason that type systems cannot capture all relevant runtime context. Java is a good example here, since it's strongly statically typed. By your reckoning, all optimistic heuristics that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back. Optimistic heuristics have a long history in computer science, and IMO it seems strange to single one particular use case as being particularly evil.

by mafribe 10y ago

catnaroek 10y ago

> Most high-level languages require compiler tricks for achieving performance from Scala to Haskell to Prolog. To make things perfectly clear: I'm not against optimizations being performed automatically by compilers or runtime systems. What I'm against is unclean designs: deliberately performing an unsound optimization and then rolling it back is an unclean design. > Use all the hackery in the world to get your language fast, The language implementation is a program itself, and I don't have any good reasons to trust a hackish language implementation any more than I trust other hackish programs - that is, not at all. > as long as it's abstract semantics is easy and canonical. Hah! This thread is about JavaScript.

mafribe 10y ago
is an unclean design. It's not unsound. Otherwise you'det g incorrect results. You could say the design is wasteful, because you optimise and then throw away the optimisation. But it's hard to do better for some kinds of languages. trust a hackish language implementation I agree. And indeed JIT compilers are hard to get right. But in practise even JIT compilers are much higher quality than applications: ask yourself, how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes?
- catnaroek 10y ago
  > It's not unsound. Otherwise you'd incorrect results. You could say it's wasteful, because you optimise and then throw away the optimisation. The optimization is unsound. If it weren't, it wouldn't have to be rolled back occasionally. If you're talking about the combination of the optimization and the rollback mechanism, it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you. > how many of the bugs in your code turned out to be compiler bugs, vs how many were ultimately your mistakes? Of course, most were my mistakes. But the very reason why those bugs made it into the final executable is the lack of powerful static analyses in the first place. Curiously enough, when I use languages that make static analyses possible, I write programs with less bugs and they perform better without relying on fancy runtime system tricks. --- Sorry, can't reply to you guys, because “I'm submitting too fast”. So my replies go here: @mafribe: > That's an orthogonal issue. It's not. Static analyses gather valuable information that can be used to emit efficient code. > More powerful static analysis is also more time-consuming. So perform it ahead of time! > One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis. Of course, a browser can't spend much time statically analyzing JavaScript programs, but programs can be statically analyzed (gasp!) before they're deployed. --- @smallnamespace: > Why does that matter to anyone? Because this implementation technique is unnecessarily complex, and a far simpler alternative exists: Know beforehand what your program has to do. Think before you write code. > Java and C# are both statically, strongly typed languages where JITs are the dominant implementation. Their type systems can be easily subverted, so they're not “strongly typed” in my book. --- @smallnamespace: Oops, sorry, I accidentally swapped my two replies to you: this one and https://news.ycombinator.com/item?id=12481956 https://news.ycombinator.com/item?id=12481956 .
  - mafribe 10y ago
    The optimization is unsound. The JIT compiler is sound, w.r.t. to the source language's semantics. That's the only thing that matters for the programmer. but it's inelegant. Elegance is in the eye of the beholder. I was blown away when I first encountered JIT compilers. lack of powerful static analyses That's an orthogonal issue. More powerful static analysis is also more time-consuming. One of the design goals of Javascript JITs is to make web-pages as responsive as possible. That rules out complicated static analysis.
  - smallnamespace 10y ago
    > it's not unsound, but it's inelegant. A runtime system designed this way only understands your program in a statistical sense (based on concrete execution profiles, which may vary from one run to another), never with the full certainty that static analyses (type checking, abstract interpretation) can give you. This is a false dichotomy. You can always build a JIT that uses runtime statistics to speed things up, even in languages that are quite amenable to static analysis, for the simple reason that type systems cannot capture all relevant runtime context. Java is a good example here, since it's strongly statically typed. By your reckoning, all optimistic heuristics that CPUs do like branch prediction and prefetching are also similarly 'inelegant', because they can be wrong and require rolling back. Optimistic heuristics have a long history in computer science, and IMO it seems strange to single one particular use case as being particularly evil.