@MSGID: 1@dont-email.me> ff7c57ed
@REPLY: <jwvedil530g.fsf-monnier+comp.arch@gnu.org>
cc090be2
@REPLYADDR BGB <cr88192@gmail.com>
@REPLYTO 2:5075/128 BGB
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References:
<57c5e077-ac71-486c-8afa-edd6802cf6b1n@googlegroups.com> <a0dd4fb4-d708-48ae-9764-3ce5e24aec0cn@googlegroups.com>
<5fa92a78-d27c-4dff-a3dc-35ee7b43cbfan@googlegroups.com> <c9131381-2e9b-4008-bc43-d4df4d4d8ab4n@googlegroups.com>
<edb0d2c4-1689-44b4-ae81-5ab1ef234f8en@googlegroups.com> <43901a10-4859-43d7-b500-70030047c8b2n@googlegroups.com>
<jwvzg1acja6.fsf-monnier+comp.arch@gnu.org> 2@dont-email.me> <jwvil7yces1.fsf-monnier+comp.arch@gnu.org>
1@dont-email.me> <jwvedil530g.fsf-monnier+comp.arch@gnu.org>
@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 5:08 PM, Stefan Monnier wrote:
>>> E.g. load 3 chunks (C1, C2, and C3) of 256bits each using standard SIMD
>>> load, and then add an instruction to turn C1+C2 into two 256bit vectors
>>> of 4x64bit floats, and another to do the same with C2+C3 (basically, the
>>> same instruction except it uses the other half of the bits of C2).
>> I don`t really have a good way to do 256-bit loads or work with 256-bit
>> vectors in my core.
> 
> Then do 3x 64bit loads which you then split into 4 64bit floats:
> 
>          64bit                64bit                 64bit
>       +---------+   +-------------------------+  +---------+
>       A0-31 B0-31   A32-47 B32-47 C32-47 D32-47  C0-31 D0-31
> 
> It`s an admittedly unusual layout, but lets you load&store in standard
> sized chunks, and hence full-bandwidth.  And lets you "reshuffle" things
> using only "2-in" operations: if your pipeline can do "2-in 2-out" you
> can do it two (parallel) instructions and otherwise you can do it in
> 4 (parallel) instructions.  Of course, if your pipeline can accommodate
> "3-in 4-out", then you can use a more standard layout.
> 

Possible at least.


>> The Float48 format is basically special case Load/Store ops which pad the
>> value to 64 bits on Load, and narrow it to 48 bits on Store.
> 
> So you`re wasting the extra L1 bandwidth since you`re using a load which
> can fetch 64bit but only use 48 of those bits (you admittedly still
> gain w.r.t to the bandwidth of higher levels of the memory hierarchy).
> 

This is little different from normal load/store:
   The L1 cache is wide enough to support 128 bits in 1 cycle;
   But, anything narrower than 128 bits, still takes 1 cycle.

Typically, 64 and 32 bit access tends to dominate, followed by 128 bit, 
with 8 and 16 bit access a little further down the list.


The Load path basically just performs an unaligned 64-bit load and then 
extracts 48 bits from it. The Store path needed to add a special case to 
support a 48-bit store.

Theoretically, 96-bit could also be possible, but would need some 
additional logic (thus cost).


At least if moving data around with 64 or 128 bit operations, the 
limiting factor tends to be L1<->L2 transfers, but if doing 8 or 16 bit 
Load/Store, then the loads/stores themselves can become the bottleneck.

Doing stuff with 32-bit ops can go either way.


 --- 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