Path: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 20:00:13 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <vccn4d$3m68q$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team>
 <20240915154038.0000016e@yahoo.com>
 <vc70sl$285g2$4@dont-email.me>
 <vc73bl$28v0v$1@dont-email.me>
 <OvEFO.70694$EEm7.38286@fx16.iad>
 <32a15246310ea544570564a6ea100cab@www.novabbs.org>
 <vc7a6h$2afrl$2@dont-email.me>
 <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org>
 <vc8qic$2od19$1@dont-email.me>
 <d61f7d82d6976343d9446bfc18552060@www.novabbs.org>
 <vc9sc8$2vus6$2@dont-email.me>
 <vcamfc$makp$2@paganini.bofh.team>
 <vcbi5c$3ecji$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 Sep 2024 22:00:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="08bfc96e5361a83057aef91988974f4e";
	logging-data="3873050"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18NJmd28uLutCUKTE1VAt8P"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:+Hewv3U+NehxEF8QCPb25NJlZFI=
	sha1:gWOBQKbWQe1pCkjpr0f0/4Z8Dv4=
Bytes: 4286

David Brown <david.brown@hesbynett.no> wrote:
> On 17/09/2024 03:36, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 16/09/2024 19:51, MitchAlsup1 wrote:
>>>> On Mon, 16 Sep 2024 8:34:19 +0000, David Brown wrote:
>>>> 
>>>>> On 15/09/2024 21:13, MitchAlsup1 wrote:
>>>>>> 
>>>>>> As to HW sadism:: this not not <realistically> any harder than mis-
>>>>>> aligned DW accesses from the cache. Many ISA from the rather distant
>>>>>> past could do these rather efficiently {360 SRDL,...}
>>>>>> 
>>>>> 
>>>>> Anyone who designs a data structure with a bit-field that spans two
>>>>> 64-bit parts of a struct is probably ignorant of C bit-fields and
>>>>> software in general.  It is highly unlikely to be necessary or even
>>>>> beneficial from the hardware viewpoint, but really inconvenient on the
>>>>> software side (whether you use bit-fields or not).
>>>> 
>>>> Sometimes you don't have a choice::
>>>> x86-64 segment registers.
>>>> PCIe MMI/O registers,
>>>> ..
>>> 
>>> The folks designing those register setups had a choice, and made a bad
>>> choice from the viewpoint of software (whether it be C, assembly, or any
>>> other language).
>>> 
>>> It's conceivable that it was the right choice on balance, considering
>>> many factors.  And it's certainly more believable that it was an
>>> appropriate choice when sizes were smaller.  It is less believable that
>>> there is an overwhelming need to cross a 64-bit boundary.
>> 
>> Several pieces of software discoverd that "bad" smaller data
>> structures lead to faster execution.  Simply, smaller data structures
>> lead to better utilization of caches and busses, and efect due to
>> this was larger than cost of extra instructions.  So need to cross
>> 64-bit boundary may be rare, but there will be cases when it is best
>> choice.
>> 
> 
> It is possible, but I think it is rare.
> 
> Perhaps my perception is biased from working with microcontrollers, 
> where you often don't have caches and instruction speeds are not nearly 
> as much faster than ram access speeds as you see in modern x86 systems.

I personally got lots of 20% speedups by restructuring data on PlayStation
2 code.

The C rules for data structure layout is stupid, a programmer would add a
int in front of a vector and fail to wonder why his structure grew by 16
bytes. Never mind that he used that 4 byte int to hold a value that had a
max of 15.

Had to annotate the data structures with 16 byte comment boundaries to stop
endless stupidity.

> The other thing I don't like about split bit-fields is that there is 
> typically no way to do atomic updates, which can mean you need extra 
> care to keep things correct.