29 ms·

Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? Sort of. But it's also that you're makin

Is the story that Go, as a simpler language, is able to compile to decently fast code w/ fewer compiler optimizations? Sort of. But it's also that you're making bad comparisons. C++ has an include based compilation model and heavy reliance on template specialisation that means it'll never be fast. What you should instead be comparing it to is Java, which is also a simple language, only slightly more complex than Go. However, that comparison is rarely made, because it'd show that compiling fast is not so special a trick ... Java also compiles extremely fast at every level, that's why it's possible to use a JIT compiler with it at all. Given that "compiles fast" is Go's number one claim to fame, the reluctance to compare to the most popular compiled language is the elephant in the room.

nickpsecurity 11y ago
What did it take to fo that in Java? When I tried Java on a Pent3, it took a few seconds to compile. The BASIC and Wirth languages could do tens of thousands of lines a second on same machine. Then they consistently ran faster than Java. The only elephant in the room is the bloated, insecure platform sitting on many servers. Competition showed one could do much more with less CPU, memory, or money invested in tooling itself.
- pcwalton 11y ago
  HotSpot's sea of nodes IR is far beyond anything Turbo Pascal did in terms of balancing compile time and runtime. It's not even comparable. Few people are as consistently right in their field as Cliff Click is with JITs and language runtimes.
  - nickpsecurity 11y ago
    Dude is brillaint and did great work. Yet, the Oberons and Pascals compiled so fast my finger was barely off the key when they were done. Even the C/C++ editors werent that fast for Java. Allowed rapid iteration while maintaining mental flow. When done, you turn all the options on with that or a slower compiler to get fastest, production version. This has been true going back to the old, Ceres workstations where commenters here that used them reported instant compiles on CPU's with tens of MHz.
    - pcwalton 11y ago
      Yes, and they didn't do any optimization. That's not particularly interesting; TCC is there if you want it.
      - nickpsecurity 11y ago
        Barely any. Which leads us to differentiate between iterative and release requirements. Language like Go will kill on the former with Wirth-style compilees. A LLVM extension might have been better for latter. That was my recommendation a while back. Even still, the language is simple enough it should compile faster. Should != will of course.
- sievebrain 11y ago
  On a Pentium 3? Don't you think such a comparison might be out of date? Java has changed a lot since those days. Yes, Pascal/Delphi also compiles very fast, it's true, but they also forbid circular dependencies and impose other restrictions that caused a lot of developer pain.
  - nickpsecurity 11y ago
    Let's say we port it from P3 to multi-core, 2GHz x86. We want to know if prior performance was relevant as a predictor. As in, will difference choices made on old platform apply to new? Here's a few examples to illustrate: 1. Interpreted vs compiled language. 2. Simple, Oberon-like type checks vs Rust or Ada. 3. Several pages of BNF in grammar vs 1 or 2. 4. Designed for abstract, heap machine or just above real, stack machine? 5. Number of steps needed between source and efficient exdcution. 6. Number of times you perform those steps (eg AOT vs JIT). 7. Cache-awareness of design. These are a few key differences between Java and Wirth-style languages then. They made compiles rapid on P3. Updating to multicore or 64-bit would be trivial given each update at ETH was a few undergrads work for 6mo-2yr. So, do lessons learned that those attributes Wirth-style greatly aid performance of compilers and runtime still apply today? I think so given what Go accomplished in its time and resources. Other languages too with design decisions that proved out over time. It took truly epic work and investment to get Java to its current situation. I havent heard people say Pascal caused them lots of pain aside from functional crowd or some wanting a few C++ features. What specifics bothered you? And why did you need circular dependencies?

nickpsecurity 11y ago

What did it take to fo that in Java? When I tried Java on a Pent3, it took a few seconds to compile. The BASIC and Wirth languages could do tens of thousands of lines a second on same machine. Then they consistently ran faster than Java. The only elephant in the room is the bloated, insecure platform sitting on many servers. Competition showed one could do much more with less CPU, memory, or money invested in tooling itself.

pcwalton 11y ago
HotSpot's sea of nodes IR is far beyond anything Turbo Pascal did in terms of balancing compile time and runtime. It's not even comparable. Few people are as consistently right in their field as Cliff Click is with JITs and language runtimes.
- nickpsecurity 11y ago
  Dude is brillaint and did great work. Yet, the Oberons and Pascals compiled so fast my finger was barely off the key when they were done. Even the C/C++ editors werent that fast for Java. Allowed rapid iteration while maintaining mental flow. When done, you turn all the options on with that or a slower compiler to get fastest, production version. This has been true going back to the old, Ceres workstations where commenters here that used them reported instant compiles on CPU's with tens of MHz.
  - pcwalton 11y ago
    Yes, and they didn't do any optimization. That's not particularly interesting; TCC is there if you want it.
    - nickpsecurity 11y ago
      Barely any. Which leads us to differentiate between iterative and release requirements. Language like Go will kill on the former with Wirth-style compilees. A LLVM extension might have been better for latter. That was my recommendation a while back. Even still, the language is simple enough it should compile faster. Should != will of course.
sievebrain 11y ago
On a Pentium 3? Don't you think such a comparison might be out of date? Java has changed a lot since those days. Yes, Pascal/Delphi also compiles very fast, it's true, but they also forbid circular dependencies and impose other restrictions that caused a lot of developer pain.
- nickpsecurity 11y ago
  Let's say we port it from P3 to multi-core, 2GHz x86. We want to know if prior performance was relevant as a predictor. As in, will difference choices made on old platform apply to new? Here's a few examples to illustrate: 1. Interpreted vs compiled language. 2. Simple, Oberon-like type checks vs Rust or Ada. 3. Several pages of BNF in grammar vs 1 or 2. 4. Designed for abstract, heap machine or just above real, stack machine? 5. Number of steps needed between source and efficient exdcution. 6. Number of times you perform those steps (eg AOT vs JIT). 7. Cache-awareness of design. These are a few key differences between Java and Wirth-style languages then. They made compiles rapid on P3. Updating to multicore or 64-bit would be trivial given each update at ETH was a few undergrads work for 6mo-2yr. So, do lessons learned that those attributes Wirth-style greatly aid performance of compilers and runtime still apply today? I think so given what Go accomplished in its time and resources. Other languages too with design decisions that proved out over time. It took truly epic work and investment to get Java to its current situation. I havent heard people say Pascal caused them lots of pain aside from functional crowd or some wanting a few C++ features. What specifics bothered you? And why did you need circular dependencies?