@MSGID: 2@dont-email.me> 115839a6
@REPLY: <jwvzg1acja6.fsf-monnier+comp.arch@gnu.org>
090dee53
@REPLYADDR BGB <cr88192@gmail.com>
@REPLYTO 2:5075/128 BGB
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@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>
@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 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.



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.

...


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