@MSGID: 2@dont-email.me> 33b2930b
@REPLY:
<c6f7d78c-b586-413a-a551-9987a486a39bn@googlegroups.com> 71fc74bd
@REPLYADDR BGB <cr88192@gmail.com>
@REPLYTO 2:5075/128 BGB
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@dont-email.me>
@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> <c6f7d78c-b586-413a-a551-9987a486a39bn@googlegroups.com>
@TZUTC: -0500
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
On 9/25/2023 7:06 PM, JimBrakefield wrote:
> 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)


I was talking about the width of the datapath, not the size of a burst 
transfer.

So, for example, with a DDR3 chip with a 16-bit interface, 8x burst, you 
can move 16B in 4 cycles (from the RAM chip`s POV); but this doesn`t 
change that the interface is only 16-bit wide.


Internally, in my case, there is a 512-bit wide interface between my DDR 
RAM module and L2 cache, but I don`t really count it as it is fairly 
special purpose: Move data in big enough chunks that I can get full RAM 
bandwidth, with a DDR controller that can only issue one request at a 
time at a 50MHz RAM clock (logic internally operating at 100MHz and thus 
driving the high and low sides as separate clock-cycles as far as the 
FPGA is concerned).

If I were able to FIFO the requests in the RAM controller, wouldn`t 
necessarily need the 512-bit bursts; but there are annoyances (and 
latency) here, due to crossing clock domains.



 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: A noiseless patient Spider (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