Sujet : Re: else ladders practice
De : antispam (at) *nospam* fricas.org (Waldek Hebisch)
Groupes : comp.lang.cDate : 20. Nov 2024, 14:44:08
Autres entêtes
Organisation : To protect and to server
Message-ID : <vhkp36$34cc3$1@paganini.bofh.team>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
Bart <
bc@freeuk.com> wrote:
On 19/11/2024 23:41, Waldek Hebisch wrote:
Bart <bc@freeuk.com> wrote:
BTW I didn't remark on the range of your (WH's) figures. They spanned 40
minutes for a build to instant, but it's not clear for which languages
they are, which tools are used and which machines. Or how much work they
have to do to get those faster times, or what work they don't do: I'm
guessing it's not processing 0.5M lines for that fastest time.
As I wrote, there are 2 different system, if interesed you can fetch
them from github.
Do you have a link? Probably I won't attempt to build but I can see what
it looks like.
I do not think I will use your system language. And for C compiler
at least currently it does not make big difference to me if your
compiler can do 1Mloc or 5Mloc on my machine, both are "pretty fast".
What matters more is support of debugging output, supporting
targets that I need (like ARM or Risc-V), good diagnostics
and optimization.
It's funny how nobody seems to care about the speed of compilers (which
can vary by 100:1), but for the generated programs, the 2:1 speedup you
might get by optimising it is vital!
Here I might borrow one of your arguments and suggest such a speed-up is
only necessary on a rare production build.
Well, there are some good arguments for using optimizing compulation
during developement:
- test what will be deliverd
- in gcc important diagnostics like info about uninitialized variables
are available only when you turn on optimization
- with separate compilation compile time usually is acceptable
I have some extra factors:
- C files on which I am doing developement are frequently quite
small and compile time is reasonable
- C code is usually in slowly changing base part and is recompiled
only rarely
I recently installed TinyC on small Risc-V
machine, I think that available memory (64MB all, about 20MB available
to user programs) is too small to run gcc or clang.
Only 20,000KB? My first compilers worked on 64KB systems, not all of
which was available either.
I used compilers on ZX Spectrum, so I know that compiler is possible
on such a machine. More to the point, gcc-1.42 worked quite well
in 4MB machine, at that time 20MB would be quite big and could support
several users doing compilation. But porting gcc-1.42 to Risc-V
is more work that I am willing to do (at least now, I could do this
if I get infinite amount of free time).
None of my recent products will do so now, but they will still fit on a
floppy disk.
BTW why don't you use a cross-compiler? That's what David Brown would say.
I did use cross-compiler to compile TinyC. Sometimes native compiler
is more convenient, I have non-C code which is hard to cross-build
and I need to link this code with C code. In cases like this doing
everthing natively is simplest thing to do (some folks use emulators,
but when it works native build is simpler). Second, one reason
to build natively is to test that native build works. In early
days of Linux I tried few times to recompile C library, and my
trials failed. Later I learned that at that time Linux C library
for i386 was cross-compiled on a Sparc machine. Apparently native
build was not tested and tended to fail. To be clear: that was long
ago, AFAIK now C library is build natively and IIRC I recompiled
it few times (I rarely have reason to do this). Third reason
to have native compiler is that machines of this class used to
come with C compiler, it was a shame not to have any C compiler
there, so I got one...
-- Waldek Hebisch