I’ve just realised that I was confused. Steven, can your confirm that that bus width between the memory controller and CPU was 256 bytes (not bits)? On a G3 9672?
> On 23 May 2023, at 8:48 am, David Crayford <[email protected]> wrote: > > Good question. By bus size I'm assuming that your referring to cache-lines? I > wonder how much of a difference that makes with OOO pipelines? What I can > confirm is that my new Arm M2 MacBook Pro which has a 32-byte cache-line > sizes absolutely smashes my AMD Ryzen 5 in Cinebench benchmarks. > > On 22/5/2023 8:26 pm, Steve Thompson wrote: >> I have a question about these systems, both z and not z. >> >> What is the current bus width supported? >> >> At the G3 level for "z" the CPU-RAM bus was 256 bytes wide, as I recall. >> >> For IOP to RAM it was 64 bytes wide. >> >> For the systems I run (off the shelf stuff for Linux and windows) the bus is >> still at 64bits (8 bytes). Yes it has bus mastering, and pathing to allow >> certain adapter cards to use 8bit "channels".... >> >> z/Arch POP has instructions for interrogating the bus sizes. I haven't had >> the time or opportunity to write any tests using this to find out what those >> bus sizes are it would report on. >> >> Steve Thompson >> >> On 5/22/2023 7:52 AM, David Crayford wrote: >>> On 22/5/2023 1:26 pm, Attila Fogarasi wrote: >>>> Good point about NUMA....and it is still a differentiator and competitive >>>> advantage for IBM z. >>> >>> How is NUMA a competitive advantage for z? Superdomes use Intel UltraPath >>> Interconnect (UPI) links that can do glueless NUMA. >>> >>>> IBM bought Sequent 20+ years ago to get their >>>> excellent NUMA technology, and has since built some very clever cache >>>> topology and management algorithms. AMD has historically been crippled in >>>> real-world performance due to cache inefficiencies. >>> >>> What historical generation of AMD silicon was crippled? The EPYC supports >>> up to 384MB of L3 cache and the specs and benchmarks suggest the chiplet >>> architecture can easily handle the I/O. >>> >>>> 10 years ago CICS was at 30 billion transactions per day, so >>>> volume has tripled in 10 years, during the massive growth of cloud. >>>> Healthy indeed. >>> >>> I have a different perspective on what constitutes healthy. Here in >>> Australia, I've had the opportunity to meet architects from various banks >>> who are actively involved in or have completed the process of migrating the >>> read side of their CICS transactions to distributed systems. They have >>> embraced technologies like CDC and streaming platforms such as Apache Kafka >>> and distributed data stores such as Cassandra and MongoDb. This shift has >>> been primarily driven by disruptive technologies like mobile banking >>> pushing up mainframe software costs. >>> >>> This is a common architectural pattern. >>> >>> https://www.conferencecast.tv/talk-29844-nationwide-building-society-building-mobile-applications-and-a-speed-layer-with-mongodb#.talkPage-header >>> >>> >>>> >>>> On Mon, May 22, 2023 at 2:56 PM David Crayford<[email protected]> wrote: >>>> >>>>> Sent again in plain text. Apple mail is too clever for it’s own good! >>>>> >>>>>> On 22 May 2023, at 12:46 pm, David Crayford<[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 21 May 2023, at 12:52 pm, Howard Rifkind<[email protected]> >>>>> wrote: >>>>>>> Hundreds of PC type servers still can’t handle the huge amount of data >>>>> like a mainframe can. >>>>>> >>>>> Of course, that's an absurd statement! By "PC type," I assume you're >>>>> referring to x86? We can easily break this down. First things first, let's >>>>> forget about the "hundreds" requirement. A 32 single socket system is >>>>> enough to match up. >>>>> >>>>> AMD EPYC is the poster child for single socket servers, running its novel >>>>> chiplet technology on a 5nm process node. AMD's infinity interconnects are >>>>> capable of massive I/O bandwidth. You can learn more about it here: >>>>> https://www.amd.com/en/technologies/infinity-architecture. Each socket >>>>> can have a maximum of 96 cores, but even if we use a conservative 64 cores >>>>> per socket, that's a scale-out of 2048 cores. AMD also has accelerators >>>>> for >>>>> offload encryption/compression, etc. >>>>> >>>>> Over in Intel land, the Ice Lake server platform is not quite as >>>>> impressive, but the QPI (Quick Path Interconnect) yet again handles huge >>>>> bandwidth. Intel also has accelerators such as their QAT, which can either >>>>> be on-die SoC or a PCIe card. It's not too dissimilar to zEDC but with the >>>>> advantage that it supports all popular compression formats and not just >>>>> DEFLATE. You can find more information here: >>>>> https://www.intel.com.au/content/www/au/en/architecture-and-technology/intel-quick-assist-technology-overview.html >>>>> >>>>> . >>>>> >>>>> A more apples-to-apples comparison would be the HP Superdome Flex, which >>>>> is a large shared memory system lashed together with NUMA interconnects, >>>>> with a whopping 32 sockets and a maximum core count of 896 on a single >>>>> vertically integrated system. HP Enterprise has technology such as nPars, >>>>> which is similar to PR/SM. They claim 99.999% availability on a single >>>>> system and even beyond when clustered. >>>>> >>>>> On the Arm side, it gets even more interesting as the hyperscalers and >>>>> cloud builders are building their own kit. Although this technology is >>>>> almost certainly the growth area of non-x86 workloads, you can find more >>>>> details about it here: >>>>> https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/ >>>>> >>>>> . >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email [email protected] with the message: INFO IBM-MAIN >>>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email [email protected] with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
