Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Short Vectors Versus Long Vectors
Date: Tue, 23 Apr 2024 22:39:44 +0000
Organization: Rocksolid Light
Message-ID: <d46723273a62c22283387893da40e7e4@www.novabbs.org>
References: <v06vdb$17r2v$1@dont-email.me> <5451dcac941e1f569397a5cc7818f68f@www.novabbs.org> <v078td$1df76$4@dont-email.me> <2024Apr23.082238@mips.complang.tuwien.ac.at> <v098so$1rp16$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2156611"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$LlBTxv7Vi.4oWjEdLXElg.Z/pyeZ9o.4XEpiJa9HFQ6U9Rd4arMLq
Bytes: 2653
Lines: 40

BGB wrote:

> On 4/23/2024 1:22 AM, Anton Ertl wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Tue, 23 Apr 2024 02:14:32 +0000, MitchAlsup1 wrote:
>>>big snip>


> As can be noted, SIMD is easy to implement.

ADD/SUB is, MUL and DIV and SHIFTs and CMPs are not; especially when
MUL does 2n = n × n and DIV does 2n / n -> n (quotient) + n (remainder)

> Main obvious drawback is the potential for combinatorial explosions of 
> instructions. One needs to keep a fairly careful watch over this.

> Like, if one is faced with an NxN or NxM grid of possibilities, naive 
> strategy is to be like "I will define an instruction for every 
> possibility in the grid.", but this is bad. More reasonable to devise a 
> minimal set of instructions that will allow the operation to be done 
> within in a reasonable number of instructions.

> But, then again, I can also note that I axed things like packed-byte 
> operations and saturating arithmetic, which are pretty much de-facto in 
> packed-integer SIMD.

MANY SIMD algorithms need saturating arithmetic because they cannot do
b + b -> h and avoid the overflow. And they cannot do B + b -> h because
that would consume vast amounts of encoding space.

> Likewise, a lot of the gaps are filled in with specialized converter and 
> helper ops. Even here, some conversion chains will require multiple 
> instructions.

> Well, and if there is no practical difference between a scalar and SIMD 
> version of an instruction, may well just use the SIMD version for scalar.

> ....


>> - anton