Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Wed, 5 Jun 2024 12:21:01 +0200
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <v3pe6e$u5kd$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v327n3$1use$1@gal.iecc.com>
 <BM25O.40665$HBac.4762@fx15.iad> <v32lpv$1u25$1@gal.iecc.com>
 <v33bqg$9cst$11@dont-email.me> <v34v62$ln01$1@dont-email.me>
 <v36bva$10k3v$2@dont-email.me> <2024May29.090435@mips.complang.tuwien.ac.at>
 <v38opv$1gsj2$3@dont-email.me> <v38rkd$1ha8a$1@dont-email.me>
 <jwvttifrysb.fsf-monnier+comp.arch@gnu.org>
 <f90b6e03c727b0f209d64484ec097298@www.novabbs.org>
 <v3jtd8$3qduu$2@dont-email.me> <20240603132227.00004e0f@yahoo.com>
 <k6k7O.8602$7jpd.5620@fx47.iad> <v3klhp$3ugeh$1@dont-email.me>
 <v3mljt$c63k$1@dont-email.me>
 <cf98e7ba84809010306e3fdea7aa103c@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 05 Jun 2024 12:21:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f84ce4f3a433bc91a4eab9bf3aa5b9f4";
	logging-data="988813"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Gs/1mg7ohnFsq0B7/m7L7AFccSHvD+JSTR4mZXtVACQ=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:vN9BcDBXA1Ie8P144RvxKOukpPc=
In-Reply-To: <cf98e7ba84809010306e3fdea7aa103c@www.novabbs.org>
Bytes: 3000

MitchAlsup1 wrote:
> Terje Mathisen wrote:
> 
>>
> 
>> That logic already exists, in the form of a single thread/core
>> dedicated
>> to the job.
> 
>> With 30-100 cores on a single die, it becomes very cheap to dedicate
>> one
>> of them to babysit such a process, compared to the cost of making a 
>> custom chunk of VLSI to do the same. This is particularly true because 
>> the logic needed in the babysitting process is mostly straight line, 
>> with a very limited number of hard-to-predict branches.
> 
>> I.e. h.264 CABAC decoding has three branches per bit decoded, at least 
>> one of them impossible to predict or work around with clever coding. 
> 
> How many instructions in the then-clause and in the else-clause ??
> If these are smaller than 8, My 66000 can process them without
> "branching" using predication.

No, the real problem is the context branching: After doing the 50% 
branch you pick up one of two alternative contexts and follow totally 
different paths, i.e. you cannot simply use the branch bit as an index.

I found ways to bypass the issues with the other two branches but this 
one is fundamental.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"