[HN Gopher] Arm fills in some gaps and details in server chip ro...
       ___________________________________________________________________
        
       Arm fills in some gaps and details in server chip roadmaps
        
       Author : rbanffy
       Score  : 66 points
       Date   : 2022-09-16 12:42 UTC (10 hours ago)
        
 (HTM) web link (www.nextplatform.com)
 (TXT) w3m dump (www.nextplatform.com)
        
       | NelsonMinar wrote:
       | I cannot wait until I can buy a good simple ARM server for my
       | home. Something like an RPi 4 but with more disk I/O and RAM. Or
       | a slightly more baked version of a ROCKPro64 in a nice case.
        
         | wmf wrote:
         | Sounds like the Honeycomb.
        
         | 0x202020 wrote:
         | I would love to see something akin to an M-based Mac as a dev
         | board of sorts, but I'm fairly sure it would never happen. My
         | home server has transitioned over time from various 4u rack
         | mount options, to a 2u and an M1 Mac Mini, to a Mac Studio with
         | a disk enclosure.
         | 
         | I even tried using a Snapdragon phone dev board for awhile for
         | something more than an RPi
        
           | rbanffy wrote:
           | It's a bit annoying that (with the exception of Apple) ARM
           | only exists in the low end and in the high-end cloud server
           | space. There is no ARM equivalent to the Core i5 generally
           | available.
        
             | smoldesu wrote:
             | My (non-professional) opinion is that Intel has invested a
             | _lot_ of money into making really good memory and I /O
             | controllers. We need someone to do that in the ARM space as
             | well, which is a really hard-sell. There are no
             | manufacturers out there that want to pay the ARM licensing
             | fee, period. Apple can eat the costs because they sell
             | direct-to-consumer and like to control as much of their
             | stack as possible. Other companies are probably groaning at
             | the thought of fixing all of ARM's problems just so they
             | can be treated as a second-class platform relative to Apple
             | Silicon. Besides Nvidia or Qualcomm, I don't really think
             | there are many companies poised to deliver this, much less
             | an incentive to provide anything.
             | 
             | RISC-V on the other hand, seems like it could be ripe for
             | rapid iteration. We're obviously still in the super-early
             | days of the ISA, but the lack of oppressive licensing has
             | already been a boon for the dozens of hobbyist boards we've
             | seen released in the past few years. As long as Apple
             | doesn't try to EEE the ISA like they're trying to do with
             | ARM, I think the future is pretty bright for open
             | architectures.
        
             | my123 wrote:
             | I'd say that there's one: Snapdragon 8cx Gen 3.
             | 
             | (See the ThinkPad X13s)
        
               | jeffbee wrote:
               | The 8cx Gen 3 is better than Qualcomm's other stuff but
               | it's still generations behind a current Core i5. They're
               | about 20% slower than a last-gen Core i5.
        
       | Symmetry wrote:
       | The V2 decision to go with 4 128 bit vector pipes instead of 2
       | 236 bit ones is a bit odd, maybe due to sharing some of the
       | design with the N2? Or maybe they want to keep things compatible
       | so code can be migrated from a V2 to a smaller core.
        
         | brigade wrote:
         | V1 already had 4 128bit pipes, SVE just used two
         | simultaneously. The only real gain in benchmarks on V1 with
         | 256bit SVE over 128bit NEON was in load-heavy kernels that were
         | bottlenecked by the 5-wide decode, and weren't saved by the MOP
         | cache. Improving decode width is easier now that 32-bit is dead
         | (or maybe V2's MOP cache was improved enough...), so 256bit
         | wide isn't terribly useful unless they commit the transistors
         | and power budget for an even wider backend than 512bit/cycle.
        
         | vgatherps wrote:
         | It also means that code using smaller vectors from an older
         | version just gets faster, as long as the new core can
         | schedule/retire instructions fast enough to keep up. If it
         | can't then going for 256 bit is the best choice although it
         | seems like newer chips are going for wider execution (and that
         | each 128 bit unit is in fact individually accessible).
        
           | saagarjha wrote:
           | Now that's a relevant username ;)
        
           | rbanffy wrote:
           | Can modern chips hold instructions from different processes
           | in the reorder buffer tagging them by their context/PID? If
           | so, up to four processes could be running 128-bit SIMD ops
           | concurrently.
        
             | wmf wrote:
             | That's SMT but Neoverse cores don't use it.
        
       ___________________________________________________________________
       (page generated 2022-09-16 23:01 UTC)