COMP.ARCH---------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 41 из 100
 От   : JimBrakefield                       2:5075/128        25 сен 23 17:06:58
 К    : BGB                                                   25 сен 23 03:12:01
 Тема : Re: Solving the Floating-Point Conundrum
----------------------------------------------------------------------------------
                                                                                 
@MSGID:
<c6f7d78c-b586-413a-a551-9987a486a39bn@googlegroups.com> 71fc74bd
@REPLY: 1@dont-email.me> 55f853f8
@REPLYADDR JimBrakefield
<jim.brakefield@ieee.org>
@REPLYTO 2:5075/128 JimBrakefield
@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>
1@dont-email.me>
@RFC-Message-ID:
<c6f7d78c-b586-413a-a551-9987a486a39bn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Monday, September 25, 2023 at 11:43:45 AM UTC-5, BGB wrote:
> On 9/25/2023 10:41 AM, 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. 
> > 
> > The memory bandwidth grows by adding controllers and striping across them 
> > for the most part.
> ?... 


> AFAIK, typical DIMMs have a 64-bit wide interface, and typical MOBOs 
> have 4 DIMM slots with DIMMs being filled in pairs. 

> This would seemingly imply that RAM would be mostly limited to a 128-bit 
> datapath (or 64-bit in unganged mode). 

> Similarly, PCIe slots are effectively multiple serial lanes running in 
> parallel, etc... 

> Typical onboard peripherals being connected either with PCIe lanes or 
> via an onboard LPC bus. 

> Similarly, a typical motherboard only has a single CPU socket. 

> ... 


> Outside of the CPU itself, unclear where any of these wide interconnects 
> would be, or where they would be going. 


> Similarly, most things much smaller than a PC, will have 16-bit or 
> 32-bit RAM interfaces (with typically 1 or 2 RAM chips soldered onto the 
> motherboard somewhere, often also with an eMMC Flash chip and other things). 


> Granted, on the other hand, I have some ~ 18 year old Xeon based rack 
> servers, which have a pair of CPUs surrounded by a small island of RAM 
> modules, and comparably still rather impressive multi-core "memcpy()" 
> performance. 

> Say, while each core individually is still limited to a few GB/sec, one 
> can have all of the cores running memcpy at the same time without any 
> significant drop (vs, say, on a PC where once the total exceeds around 8 
> to 10GB/sec or so, per-thread performance drops off). 

> Well, and both still significantly beat out the "memcpy()" performance 
> on a 20 year old laptop (as does a RasPi...). 

> ...

Ugh,
|> This would seemingly imply that RAM would be mostly limited to a 128-bit 
|> datapath (or 64-bit in unganged mode). 

https://en.wikipedia.org/wiki/CAS latency
 Has a table of DIMM performance for various DIMM generations and
various burst lengths.
 And by extension to some number of directly soldered DRAM chips
which each can have up to 16 data pins.
 (e.g. two chips DRAM with 32 total data pins and a burst size of
eight = 256 bit cache line)
--- 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



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх