@MSGID:
<76d818c1-ee00-456b-848f-bb43ec7739fan@googlegroups.com> 75fc1b4c
@REPLY: 2@dont-email.me> 115839a6
@REPLYADDR robf...@gmail.com <robfi680@gmail.com>
@REPLYTO 2:5075/128 robf...@gmail.com
@CHRS: CP866 2
@RFC: 1 0
@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>
@RFC-Message-ID:
<76d818c1-ee00-456b-848f-bb43ec7739fan@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Monday, September 25, 2023 at 1:39:09 PM UTC-4, BGB wrote:
> On 9/25/2023 11:30 AM, Stefan Monnier wrote: 
> > I think intermediate-sized FPs are unlikely to be worth the effort other 
> > than in very niche places where the few percents gained can be justified 
> > by a very large volume. 
> > 
> > In memory management libraries (malloc, GCs, ...) we do try and minimize 
> > the amount of memory that`s "wasted" of course, but we generally 
> > consider that having an upper bound of ~100% overhead is acceptable 
> > (i.e. using twice as much memory as actually needed in the worst case). 
> >
> I am now evaluating the possible use of a 48-bit floating-point format, 
> but this is (merely) in terms of memory storage (in registers, it will 
> still use Binary64). 
> 
> Still to be determined whether being able to save 2-bytes in struct or 
> array storage (at the cost of a few extra clock-cycles per load/store 
> operation; and a non-standard C type) will be a worthwhile tradeoff. 
> 
> Would also need to determine the relative cost tradeoff between having 
> dedicated 48-bit load/store ops, and "faking it" via multi-instruction 
> sequences. 

 If your CPU supports unaligned data, you could store 64-bit floats
every six bytes,
instead of eight bytes, overlapping previously stored values. But you would need
to be careful the order the stores take place.

With a 48-bit load/store, scaled indexed addressing for arrays would need to
scale by six.
> 
> 
> 
> Similarly, while I was at it, went and added a few "proper" byte-swap 
> instructions (to potentially help with the efficiency of endian 
> conversion, at least slightly...). 
> 
> As for memory management, I generally aim for around a 25% space 
> overhead per small/medium "malloc()". 
> 
> Sometimes, this does mean needing to switch between strategies, say: 
> Cell-oriented allocator for small objects (say, under 256 or 384B); 
> Memory-block-list allocator for medium objects; 
> Page-based allocation for larger objects. 
> 
> ...
--- G2/1.0
 * Origin: usenet.network (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