@MSGID:
<18ef0212-cea1-44d3-bacf-532a2f386a7bn@googlegroups.com> a530b7e0
@REPLY: <8ThQM.146454$bmw6.26202@fx10.iad>
450b1445
@REPLYADDR MitchAlsup <MitchAlsup@aol.com>
@REPLYTO 2:5075/128 MitchAlsup
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<fbed57b4-1553-4b63-b39e-c130754b3aa8n@googlegroups.com> <memo.20230925074837.16292U@jgd.cix.co.uk>
<8ThQM.146454$bmw6.26202@fx10.iad>
@RFC-Message-ID:
<18ef0212-cea1-44d3-bacf-532a2f386a7bn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Monday, September 25, 2023 at 10:42:00 AM UTC-5, Scott Lurndal wrote:
> j...@cix.co.uk (John Dallman) writes: 
> >In article <fbed57b4-1553-4b63...@googlegroups.com>, 
> >jsa...@ecn.ab.ca (Quadibloc) wrote: 
> > 
> >> hardware support for packed decimal 
> >> hardware support for IBM System/360 hexadecimal floating point 
> >> 
> >> because people do run Hercules on their computers and so on. 
> > 
> >I read the Hercules mailing list. Nobody on there uses it for serious 
> >work. It seems to be mainly used to evoke memories of youth. Running it 
> >on low-powered hardware, such as Raspberry Pi, attracts more notice than 
> >running it on something powerful. Hercules is written in portable C, 
> >because portability is considered more important than performance. 
> > 
> >> I have now added, at the bottom of the page, a scheme, involving 
> >> having dual-channel memory where each channel is 192 bits wide, 
> >> that permits the operating system to allocate blocks of 384-bit 
> >> wide memory, 288-bit wide memory, 240-bit wide memory, and 256-bit 
> >> wide memory. 
> > 
> >That`s an interesting new way to have your system run short of the right 
> >kind of memory.
<
> Indeed. It`s not the path from memory to the core complex that is 
 > currently most interesting (although 256-bit wide (and higher) mesh
or crossbars 
> aren`t uncommon), but rather the data path widths from I/O 
> subsystems. 512-bit wide paths from network controllers and on-board 
> non-coherent (or coherent, see CXL) coprocessors has become 
> common. Supporting 80gbit/sec of network traffic into memory 
> or the networking subsystem isn`t trivial. 
<
CRAY YMP allowed I/O to send 1 doubleword per memory bank per
cycle--providing 50+ GB/s in I/O throughput.
> 
> The memory bandwidth grows by adding controllers and striping across them 
> for the most part.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441