Sujet : Re: xxd -i vs DIY Was: C23 thoughts and opinions
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 28. May 2024, 19:57:38
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v359f1$nknu$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla Thunderbird
On 28/05/2024 16:56, Michael S wrote:
On Tue, 28 May 2024 15:06:40 +0100
bart <bc@freeuk.com> wrote:
On 28/05/2024 12:41, Michael S wrote:
On Sun, 26 May 2024 13:09:36 +0200
David Brown <david.brown@hesbynett.no> wrote:
>
I think you might be missing the point here.
>
I don't think so.
I understand your points and agree with just about everything. My post
was off topic, intentionally so.
If we talk about practicalities, the problems with xxd, if there are
problems at all, are not its speed, but the size of the text file
it produces (~6x the size of original binary) and its availability.
I don't know to which package it belongs in typical Linux or BSD
distributions, but at least on Windows/msys2 it is part of Vim - rather
big package for which, apart from xxd, I have no use at all.
OK, I had go with your program. I used a random data file of exactly 100M bytes.
Runtimes varied from 4.1 to 5 seconds depending on compiler. The fastest time was with gcc -O3.
I then tried a simple program in my language, which took 10 seconds.
I looked more closely at yours, and saw you used a clever method of a table of precalculated stringified numbers.
Using a similar table, plus more direct string handling, the fastest timing on mine was 3.1 seconds, with 21 numbers per line. (The 21 was supposed to match your layout, but that turned out to be variable.)
Both programs have a trailing comma on the last number, which may be problematical, but also not hard to fix.
I then tried xxd under WSL, and that took 28 seconds, real time, with a much larger output (616KB instead of 366KB). But it's using fixed width columns of hex, complete with a '0x' prefix.
Below is that program but in my language. I tried transpiling to C, hoping it might be even faster, but it got slower (4.5 seconds with gcc-O3). I don't know why. It would need manual porting to C.
This hardcodes the input filename. 'readfile' is a function in my library.
--------------------------------
[0:256]ichar numtable
[0:256]int numlengths
proc main=
ref byte data
[256]char str
const perline=21
int m, n, slen
byte bb
ichar s, p
for i in 0..255 do
numtable[i] := strdup(strint(i))
numlengths[i] := strlen(numtable[i])
od
data := readfile("/c/data100")
n := rfsize
while n do
m := min(n, perline)
n- := m
p := &str[1]
to m do
bb := data++^
s := numtable[bb]
slen := numlengths[bb]
to slen do
p++^ := s++^
od
p++^ := ','
od
p^ := 0
println str
od
end