4 ms·

What they are doing now is trying to separate power and data, so that they approach the die from different sides. But the memory bottleneck cannot be solved so

by bullen 4y ago

What they are doing now is trying to separate power and data, so that they approach the die from different sides. But the memory bottleneck cannot be solved so we are stuck with the CPU performance per watt we have had since Ivy Bridge around 2012. DRR3 has lower latency than DDR4,5,6+ GPU is also stuck. The ONLY solution is to code vanilla Java (no/few external deps.) on the server and mostly C with ++ compiler on the client. Forget Rust, Go, WASM, etc.

bheadmaster 4y ago
> The ONLY solution is to code vanilla Java (no/few external deps.) on the server and mostly C with ++ compiler on the client. > Forget Rust, Go, WASM, etc. Why?
- bullen 4y ago
  Because you need a VM with GC on the server so it doesn't crash and can share memory between cores properly. On the client you can go lower since deploying new buggy code only affects some of the clients and not the entire server (unless you deploy completely untested patches). - Rust seg. faults. - Go has no VM - WASM has no GC.
  - bheadmaster 4y ago
    How exactly are GC and VM crucial to "not crashing" and "sharing memory"? And what exactly do you mean by "not crashing"? Crashing is a broad term, and I assume you mean C++-style-crash-because-of-type-safety-errors. Go does not run on VM, yet is type safe. Rust can indeed cause segfaults, but that's only if you (ab)use the "unsafe" mechanism, which is explicitly labeled as not safe. As long as you stick to the safe Rust, segfaults are impossible. Could you explain your reasoning to me in a little more detail, please?
    - bullen 4y ago
      "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html "Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html https://travisdowns.github.io/blog/2020/07/06/concurrency-co... "Inspired by the apparent success of Java's new memory model, many of the same people set out to define a similar memory model for C++, eventually adopted in C++11." - https://research.swtch.com/plmm https://research.swtch.com/plmm
      - bheadmaster 4y ago
        All of those sources seem to compare Java to C and C++. You've mentioned more languages than C and C++. Furthermore, your third source even admits that it's possible to implement similar memory model in C++, which goes against your claims. Regardless, I wasn't asking for sources, I was asking for elaboration. What exactly does VM and GC have to do with crashing and memory sharing - in other words, how exactly does a lack of VM and GC imply crashing and inefficient memory sharing?
etaioinshrdlu 4y ago
Going from pointing out CPU and memory hardware problems to declaring, forcefully, the solution can only be Java, of all things, is one of the more bizarre comments I've read here lately. Especially because there is nothing backing up the claim.
holbrad 4y ago
Obvious Troll post, but your massively misinformed. CPU performance per watt, has massively increased. (https://www.cpubenchmark.net/power_performance.html https://www.cpubenchmark.net/power_performance.html) GPU is not stuck, it has also massively improved. The solution is to write better software, there's an awful lot of low hanging fruit in all most every program. (Things like the GTA V loading bug) Langages do matter here, but only marginally for most projects. *Actually kind of correct on the memory, but that ignores much higher throughput.

by bullen 4y ago

bheadmaster 4y ago

> The ONLY solution is to code vanilla Java (no/few external deps.) on the server and mostly C with ++ compiler on the client. > Forget Rust, Go, WASM, etc. Why?

bullen 4y ago
Because you need a VM with GC on the server so it doesn't crash and can share memory between cores properly. On the client you can go lower since deploying new buggy code only affects some of the clients and not the entire server (unless you deploy completely untested patches). - Rust seg. faults. - Go has no VM - WASM has no GC.
- bheadmaster 4y ago
  How exactly are GC and VM crucial to "not crashing" and "sharing memory"? And what exactly do you mean by "not crashing"? Crashing is a broad term, and I assume you mean C++-style-crash-because-of-type-safety-errors. Go does not run on VM, yet is type safe. Rust can indeed cause segfaults, but that's only if you (ab)use the "unsafe" mechanism, which is explicitly labeled as not safe. As long as you stick to the safe Rust, segfaults are impossible. Could you explain your reasoning to me in a little more detail, please?
  - bullen 4y ago
    "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html https://martinfowler.com/bliki/OOPSLA2005.html "Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-costs.html https://travisdowns.github.io/blog/2020/07/06/concurrency-co... "Inspired by the apparent success of Java's new memory model, many of the same people set out to define a similar memory model for C++, eventually adopted in C++11." - https://research.swtch.com/plmm https://research.swtch.com/plmm
    - bheadmaster 4y ago
      All of those sources seem to compare Java to C and C++. You've mentioned more languages than C and C++. Furthermore, your third source even admits that it's possible to implement similar memory model in C++, which goes against your claims. Regardless, I wasn't asking for sources, I was asking for elaboration. What exactly does VM and GC have to do with crashing and memory sharing - in other words, how exactly does a lack of VM and GC imply crashing and inefficient memory sharing?

etaioinshrdlu 4y ago

Going from pointing out CPU and memory hardware problems to declaring, forcefully, the solution can only be Java, of all things, is one of the more bizarre comments I've read here lately. Especially because there is nothing backing up the claim.

holbrad 4y ago

Obvious Troll post, but your massively misinformed. CPU performance per watt, has massively increased. (https://www.cpubenchmark.net/power_performance.html https://www.cpubenchmark.net/power_performance.html) GPU is not stuck, it has also massively improved. The solution is to write better software, there's an awful lot of low hanging fruit in all most every program. (Things like the GTA V loading bug) Langages do matter here, but only marginally for most projects. *Actually kind of correct on the memory, but that ignores much higher throughput.