3 ms·

You're talking a about a very specific scenario, out of the box Go is off course easier than C++ for concurrency. Who by the way runs applications on a 88 core

by Thaxll 8y ago

You're talking a about a very specific scenario, out of the box Go is off course easier than C++ for concurrency. Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks.

shereadsthenews 8y ago
You're making a different argument, that one does not need so much vertical scalability, and I might agree, but that doesn't negate the fact that Go has limits of vertical scalability that C++ doesn't face.
- weberc2 8y ago
  The original claim was that concurrency is easier in Go, not that Go has a higher performance ceiling. You are the one making the different argument. :)
derefr 8y ago
> Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks. Graph analysis and/or routing, for one. Distributed Dijkstra is pretty impractical (the optimal lower bound on the number of messages required equals the number of edges in the graph!) For example, I don't work for Google, but I can pretty much guarantee you that an individual Google Maps routing query runs on a single, extremely-high-memory (but not NUMA!) node, which has likely been optimized for speed using plain-old threading on a high-core-count CPU, with the upper bound on the number of useful cores being the system architecture's per-socket memory bandwidth.
- foobiekr 8y ago
  I would be very, very curious if this is actually true. I agree with the intuition behind the statement but I am actually curious how it is done.
- Thaxll 8y ago
  I highly doubt Google runs any workload on Borg with CPU count > 24. I don't work there, so I'm just assuming but it goes against all modern scaling / deployments patterns.
  - shereadsthenews 8y ago
    There are various workloads that occupy entire machines, they are all very carefully written by dedicated performance experts, in C++.
- kasey_junk 8y ago
  Where do you get high core count computers that aren’t numa?
- jefftk 8y ago
  I think you're ignoring caching/preprocessing in your analysis.
  - derefr 8y ago
    I am, yeah; but it’s an infinite regress—if these aren’t the specs of the machine that answers your query, then they’re the specs of the machine that does the spec-work to build the cache.
    - erik_seaberg 8y ago
      Or the machine that designs the machine that answers your query.
nickpsecurity 8y ago
Anyone doing scale up in the HPC space. It's a massive market. This link has a picture in it showing the industries that buy that stuff: https://www.nextplatform.com/2017/06/22/casing-hpc-market-hard-getting-harder/ https://www.nextplatform.com/2017/06/22/casing-hpc-market-ha... Although they cost a ton, there were at least two reasons to like NUMA machines: 1. You program them much like multithreaded machines instead of message passing like MPI. You do need to account for locality. There's OS, library, and documentation support for handling that, though. Porting a multithreaded library to NUMA is much smaller problem than clustering it. 2. A massive amount of memory with lower-latency access than on clusters. If your data is in memory, it's much faster than if it's being moved in and out of memory. Then, when it is moved, it's moved faster. Low-latency reduces the damage of many smaller copies, too. For such reasons, I always wanted a SGI or Cray machine. Modern, multi-core machines with plenty of RAM are good enough for most of my purposes, though. I do plan to do some model-checking of software in the near future. The amount of RAM used grows exponentially or something like that with the size of the program. Small ones already use GB of RAM in the analyses. Some are getting parallelized a bit. Obviously, 88 cores with 100+GB of RAM could be pretty useful if handling programs twice or three times as large. :) Btw, there are also languages designed specifically to take advantage of parallelism in many HPC situations. Like Go, they were intended to let you describe the algorithms in a high-level way with the compiler synthesizing efficient implementations for everything from multi-cores to NUMA to clusters. That's the theory. The best one from my prior research was Chapel. Then, there's simpler ones for stuff like data parallel with Cilk being an example. https://chapel-lang.org/ https://chapel-lang.org/ https://en.wikipedia.org/wiki/Cilk https://en.wikipedia.org/wiki/Cilk ParaSail was a recent one with interesting design. I'm not sure what its current status is in terms of usability. https://www.embedded.com/design/programming-languages-and-tools/4375616/ParaSail--Less-is-more-with-multicore?page=0 https://www.embedded.com/design/programming-languages-and-to...

by Thaxll 8y ago

shereadsthenews 8y ago

You're making a different argument, that one does not need so much vertical scalability, and I might agree, but that doesn't negate the fact that Go has limits of vertical scalability that C++ doesn't face.

weberc2 8y ago
The original claim was that concurrency is easier in Go, not that Go has a higher performance ceiling. You are the one making the different argument. :)

derefr 8y ago

> Who by the way runs applications on a 88 core server, why would you so they instead of splitting that into smaller chunks. Graph analysis and/or routing, for one. Distributed Dijkstra is pretty impractical (the optimal lower bound on the number of messages required equals the number of edges in the graph!) For example, I don't work for Google, but I can pretty much guarantee you that an individual Google Maps routing query runs on a single, extremely-high-memory (but not NUMA!) node, which has likely been optimized for speed using plain-old threading on a high-core-count CPU, with the upper bound on the number of useful cores being the system architecture's per-socket memory bandwidth.

foobiekr 8y ago
I would be very, very curious if this is actually true. I agree with the intuition behind the statement but I am actually curious how it is done.
Thaxll 8y ago
I highly doubt Google runs any workload on Borg with CPU count > 24. I don't work there, so I'm just assuming but it goes against all modern scaling / deployments patterns.
- shereadsthenews 8y ago
  There are various workloads that occupy entire machines, they are all very carefully written by dedicated performance experts, in C++.
kasey_junk 8y ago
Where do you get high core count computers that aren’t numa?
jefftk 8y ago
I think you're ignoring caching/preprocessing in your analysis.
- derefr 8y ago
  I am, yeah; but it’s an infinite regress—if these aren’t the specs of the machine that answers your query, then they’re the specs of the machine that does the spec-work to build the cache.
  - erik_seaberg 8y ago
    Or the machine that designs the machine that answers your query.

nickpsecurity 8y ago

Anyone doing scale up in the HPC space. It's a massive market. This link has a picture in it showing the industries that buy that stuff: https://www.nextplatform.com/2017/06/22/casing-hpc-market-hard-getting-harder/ https://www.nextplatform.com/2017/06/22/casing-hpc-market-ha... Although they cost a ton, there were at least two reasons to like NUMA machines: 1. You program them much like multithreaded machines instead of message passing like MPI. You do need to account for locality. There's OS, library, and documentation support for handling that, though. Porting a multithreaded library to NUMA is much smaller problem than clustering it. 2. A massive amount of memory with lower-latency access than on clusters. If your data is in memory, it's much faster than if it's being moved in and out of memory. Then, when it is moved, it's moved faster. Low-latency reduces the damage of many smaller copies, too. For such reasons, I always wanted a SGI or Cray machine. Modern, multi-core machines with plenty of RAM are good enough for most of my purposes, though. I do plan to do some model-checking of software in the near future. The amount of RAM used grows exponentially or something like that with the size of the program. Small ones already use GB of RAM in the analyses. Some are getting parallelized a bit. Obviously, 88 cores with 100+GB of RAM could be pretty useful if handling programs twice or three times as large. :) Btw, there are also languages designed specifically to take advantage of parallelism in many HPC situations. Like Go, they were intended to let you describe the algorithms in a high-level way with the compiler synthesizing efficient implementations for everything from multi-cores to NUMA to clusters. That's the theory. The best one from my prior research was Chapel. Then, there's simpler ones for stuff like data parallel with Cilk being an example. https://chapel-lang.org/ https://chapel-lang.org/ https://en.wikipedia.org/wiki/Cilk https://en.wikipedia.org/wiki/Cilk ParaSail was a recent one with interesting design. I'm not sure what its current status is in terms of usability. https://www.embedded.com/design/programming-languages-and-tools/4375616/ParaSail--Less-is-more-with-multicore?page=0 https://www.embedded.com/design/programming-languages-and-to...