Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: xxd -i vs DIY Was: C23 thoughts and opinions
Date: Wed, 29 May 2024 01:29:00 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <v35ssd$qq9b$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
 <v2lji1$1bbcp$1@dont-email.me> <87msoh5uh6.fsf@nosuchdomain.example.com>
 <f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
 <v2nbp4$1o9h6$1@dont-email.me> <v2ng4n$1p3o2$1@dont-email.me>
 <87y18047jk.fsf@nosuchdomain.example.com>
 <87msoe1xxo.fsf@nosuchdomain.example.com> <v2sh19$2rle2$2@dont-email.me>
 <87ikz11osy.fsf@nosuchdomain.example.com> <v2v59g$3cr0f$1@dont-email.me>
 <20240528144118.00002012@yahoo.com> <v34odg$kh7a$1@dont-email.me>
 <20240528185624.00002494@yahoo.com> <v359f1$nknu$1@dont-email.me>
 <20240528232315.00006a58@yahoo.com> <20240529004530.00005793@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 29 May 2024 02:29:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f50a0a3313aa9a4c5e71b452f1561318";
	logging-data="878891"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19AWMMNNk5Z9VY/ErYOZpHL"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:50vPP0O2ZWmcsdKJxCdqNpcsADA=
In-Reply-To: <20240529004530.00005793@yahoo.com>
Content-Language: en-GB
Bytes: 2940

On 28/05/2024 22:45, Michael S wrote:
> On Tue, 28 May 2024 23:23:15 +0300
> Michael S <already5chosen@yahoo.com> wrote:
> 
>>
>> Also, I think that random numbers are close to worst case for branch
>> predictor / loop length predictor in my inner loop.
>> Were I thinking about random case upfront, I'd code an inner loop
>> differently. I'd always copy 4 octets (comma would be stored in the
>> same table). After that I would update outptr by length taken from
>> additional table, similarly, but not identically to your method below.
>>
> 
> That's what I had in mind:
> 

>    unsigned char bin2dec[256][MAX_CHAR_PER_NUM+1]; //
>    bin2dec[MAX_CHAR_PER_NUM] => length for (int i = 0; i < 256;++i) {

Is this a comment that has wrapped?

After fixing a few such line breaks, this runs at 3.6 seconds compared 
with 4.1 seconds for the original.

Although I don't quite understand the comments about branch prediction.

I think runtime is still primarily spent in I/O.

If I take the 1.9 second version, and remove the fwrite, then it runs in 
0.8 seconds. 0.7 of that is generating the text (366MB's worth, a line 
at a time).

In my language that part takes 0.9 seconds, which is a more typical 
difference due to gcc's superior optimiser.