Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sun, 26 May 2024 16:18:32 +0300
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <20240526161832.000012a6@yahoo.com>
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>
	<v2v7ni$3d70v$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 26 May 2024 15:18:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="748cc89cfd4b455fba2588d67f703cb1";
	logging-data="3503865"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+72YZ43Syg1q085akUadcdLDUR1gj3u5w="
Cancel-Lock: sha1:GD0joaYb43opiXlhIwKKlPkBW6E=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4835

On Sun, 26 May 2024 12:51:12 +0100
bart <bc@freeuk.com> wrote:

> On 26/05/2024 12:09, David Brown wrote:
> > On 26/05/2024 00:58, Keith Thompson wrote: =20
>=20
> >> For a very large file, that could be a significant burden.=C2=A0 (I
> >> don't have any numbers on that.) =20
> >=20
> > I do :
> >=20
> > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm#design-effi=
ciency-metrics>
> >=20
> > (That's from a proposal for #embed for C and C++.=C2=A0 Generating the=
=20
> > numbers and parsing them is akin to using xxd.)
> >=20
> > More useful links:
> >=20
> > <https://thephd.dev/embed-the-details#results>
> > <https://thephd.dev/implementing-embed-c-and-c++>
> >=20
> > (These are from someone who did a lot of the work for the
> > proposals, and prototype implementations, as far as I understand
> > it.)
> >=20
> >=20
> >=20
> > Note that I can't say how much of a difference this will make in
> > real life.=C2=A0 I don't know how often people need to include
> > multi-megabyte files in their code.=C2=A0 It certainly is not at a level
> > where I would change any of my existing projects from external
> > generator scripts to using #embed, but I might use it in future
> > projects. =20
>=20
> I've just done my own quick test (not in C, using embed in my
> language):
>=20
>      []byte clangexe =3D binclude("f:/llvm/bin/clang.exe")
>=20
>      proc main=3D
>          fprintln "clang.exe is # bytes", clangexe.len
>      end
>=20
>=20
> This embeds the Clang C compiler which is 119MB. It took 1.3 seconds
> to compile (note my compiler is not optimised).
>=20
> If I tried it using text: a 121M-line include file, with one number
> per line, it took 144 seconds (I believe it used more RAM than was=20
> available: each line will have occupied a 64-byte AST node, so nearly=20
> 8GB, on a machine with only 6GB available RAM, much of which was
> occupied).

On my old PC that was not the cheapest box in the shop, but is more than
10 y.o. compilation speed for similarly organized (but much smaller)
text files is as following:
MSVC 18.00.31101 (VS 2013) - 1950 KB/sec
MSVC 19.16.27032 (VS 2017) - 1180 KB/sec
MSVC 19.20.27500 (VS 2019) - 1180 KB/sec
clang 17.0.6 - 547 KB/sec (somewhat better with hex text)
gcc 13.2.0 - 580 KB/sec

So, MSVC compilers, esp. an old one, are somewhat faster than yours.
But if there was swapping involved it's not comparable. How much time
does it take for your compiler to produce 5MB byte array from text?

>=20
> The figures at your link say it took 1 second for a 40MB test file,
> on an Intel i7 with 24GB.
>
> My compiler took just over 1.3 seconds (now annoyingly taking 1.4=20
> seconds for a retest) for a file nearly 3 times bigger, on a much
> more lowly machine (second cheapest PC in the shop), with 8GB.
>=20
> So my implementation sounds faster. Of course, those 120M data bytes=20
> haven't been optimised!
>

But both are much faster than compiling through text. Even "slow"
40MB/3 is 6-7 times faster than the fastest of compilers in my tests.

> As for usage, this would be a tidy way of bundling a program like a C=20
> compiler if your program required it, although there are a number of=20
> alternatives in that case: the binary here doesn't need to exist in
> the application's data space.
>=20