6 ms·

This is not only a nice enhancement to the Go compiler and thus for all Go users, but also it shows why Go as a language is so relevant. Single thread performan

• noir_lord 10y ago
  Interesting with the Ryzen parts coming to market as well. I'm in the market for a new developer desktop and if it shakes out the way it's looking an 8 core/16 thread Ryzen is hitting the price/perf sweetspot.
  • _ph_ 10y ago
    Yes, I was so happy to learn that AMD is finally pushing 8 cores for mainstream processors, they were too long stuck on 4 cpus. Of course, building software fully using those cpus is the challenge, but thats where Go comes in.
    • noir_lord 10y ago
      It's not just the building, it's the ability to run multiple virtualised environments (for example at the moment I'm running Xubuntu, two vagrant machines and Microsoft's Windows 10/Edge testing VM).
    • pcwalton 10y ago
      As I elaborated on elsewhere, if you focus on task parallelism to the exclusion of data parallelism, like Go tends to do, then you are not making good use of the hardware.
      • weberc2 10y ago
        What does it mean for a programming language to "tend to focus on task vs data parallelism"? In my mind, Go gives you primitives from which to build either data or task parallel algos, and the programmer can choose the kind of algorithm that they find appropriate (perhaps data parallelism is always faster, but perhaps some developers find task parallelism easier and their time is not well spent squeezing out the performance delta?). Is there some set of primitives that would cater more naturally to data parallelism? If these primitives exist, are they really 'better' than Go's primitives, or do they simply make task parallelism harder without making data parallelism easier? These aren't rhetorical questions; I'm genuinely curious to hear your opinion.
        • zzzcpan 10y ago
          "Go gives you primitives from which to build either data or task parallel algos" No, Go doesn't give you simd/vector primitives for data parallelism.
          • weberc2 10y ago
            SIMD is an implementation of data parallelism. Data parallelism doesn't require SIMD.
        • pcwalton 10y ago
          You want SIMD and parallel for, parallel map/reduce, etc. Goroutines are too heavyweight for most of these tasks: you will be swamped in creation, destruction, and message passing overhead. What you need is something like TBB or a Cilk-style scheduler.
          • weberc2 10y ago
            I see. It's worth noting that there are SIMD libraries for Go. I can't comment about them because I haven't used them.
    • geezerjay 10y ago
      > Yes, I was so happy to learn that AMD is finally pushing 8 cores for mainstream processors, they were too long stuck on 4 cpus. What do you mean by "finally pushing 8 cores"? AMD has been selling 8 core CPUs for years with their AMD FX 8xxx line.
• lossolo 10y ago
  > Go is a great language which combines C-like speeds I am using Go in production. It does not combine C-like speeds (I've comparison after rewriting one of the services from C to Go), but there is a lot of space for additional optimizations in future. Go will never be as efficient as C because of additional indirection in certain cases and additional bookkeeping. But in many cases it's faster than Java.
  • _ph_ 10y ago
    I am also using Go in production, and I am really getting C like speeds. Low level code is basically the same efficiency - the Go compiler does not optimize as well as good C compilers, but that gap closes constantly, and there is some overhead due e.g. bounds checking. But many those checks can be optimized away and of course, safe C code would have explicit checks as part of the programs usually.
    • unscaled 10y ago
      Go is incapable of ever achieving C like speeds, and that's not because of runtime safety checks like bounds checking. It's because Go still has a garbage collector, and that always comes with a price tag. Go also often has to copy structs and buffers that would be zero-copy in C, C++ and Rust code. Passing slices to functions which requires arrays or converting between strings and byte slices requires copy for instance. There's also the matter of poor control of stack vs. heap allocation and poor escape analysis to mitigate that. All in all, Go provides very impressive performance when compared to other high-level languages, but calling it C-level performance is pure hype.
      • kardianos 10y ago
        This is true. But much of the GC can be done on parallel threads, reducing the amount of total work that can be done, but keeping the threads that do work nice and speedy.
      • _ph_ 10y ago
        The garbage collector does not impact the speed of tight code - when it runs it of course takes cpu power, but it runs in parallel to the program code, so this comes pretty cheap. And the GC only consumes any resources, when you allocate heap space. This is generally not necessary, and also comes with a steep price when done in C. Coding efficiently in Go requires some different best practices in C, so this might have gotten you the impression of inefficiencies, but once you have adapted to the good Go practices, there is very little difference.
• blauditore 10y ago
  > Single thread performance of processors has not increased very much in the recent years, while the core count continued to grow Frequencies have not increased much, but performance certainly has. Better single-core performance at the same frequency is the main advantage Intel CPUs currently have over AMD ones.
  • abecedarius 10y ago
    'Much' is a matter of perspective. Mine was formed in the 80s and 90s, when doubled performance took maybe a couple years, not a decade.
• rbehrends 10y ago
  Compilation is not a good example of this, though. Parallel compilation is something that any language that allows for separate compilation has supported for decades (make -j N at its most basic, with some language implementations providing more sophisticated support).
  • burntsushi 10y ago
    Go has supported that too. But this particular change enables parallelism within a single compilation unit.
  • deleted 10y ago
    [deleted]
  • mtanski 10y ago
    Yes, but often times you've been stuck with single threaded / single process linking. Also, why LLVM has spent time recently creating a fast(er) linker.
• pcwalton 10y ago
  Task parallelism is fine with the goroutine model, but not data parallelism, which is just as important if not more so. (Although note that task parallelism depends on having good locking strategies, and having more static checking than Go offers in this department is always nice...) Why do we use GPUs, for example? Data parallelism. What have all the advances in video/audio codec implementation been the result of? Data parallelism again. What makes hashing fast? You guessed it...
  • chrisseaton 10y ago
    I would have thought you could perfectly model data parallelism in terms of task parallelism though? But not the other way around.
    • pcwalton 10y ago
      Theoretically, yes. In practice, when performance matters, no.
• zzzcpan 10y ago
  "with a good concurrency model, making your program comparatively easy to parallelize on a per-function basis" Actually Go's shared-memory multithreading concurrency model encourages program architectures that are not easily parallelizable at all. And it's harmful to praise it. We have much better share-nothing models that encourage parallelizable programs from the start.