Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Thu, 21 Nov 2024 15:20:22 +0000
Organization: A noiseless patient Spider
Lines: 166
Message-ID: <vhnj3n$mk94$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me>
 <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me>
 <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me>
 <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me>
 <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <vhl1up$5vdg$1@dont-email.me>
 <vhlg53$8lff$1@dont-email.me> <vhnasl$l8h5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 21 Nov 2024 16:20:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c40e301dd0b1f9597074e8098c15fd77";
	logging-data="741668"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kzLeOFVwN+j2NNN8POEZc"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:SVhWggD+6EpTBgXmc0bU0F5OxX0=
In-Reply-To: <vhnasl$l8h5$1@dont-email.me>
Content-Language: en-GB
Bytes: 7279

On 21/11/2024 13:00, David Brown wrote:
> On 20/11/2024 21:17, Bart wrote:

>> For the routines ones that I do 100s of times a day, where test runs 
>> are generally very short, then I don't want to hang about waiting for 
>> a compiler that is taking 30 times longer than necessary for no good 
>> reason.
>>
> 
> Your development process sounds bad in so many ways it is hard to know 
> where to start.  I think perhaps the foundation is that you taught 
> yourself a bit of programming in the 1970's,

1970s builds, especially on mainframes, were dominated by link times. 
You also had to keep on eye on resources (eg. allocated CPU time), as 
they were limited on time-shared systems.

Above all, you could only do active work from a terminal that you first 
had to book, for one-hour slots.

I'm surprised you think that my tools and working practices have any 
connection with the above.

I've also eliminated linkers; you apparently still use them.

> As I said, no one is ever going to care if a compilation takes 1 second 
> or 0.1 seconds.

And yet, considerable effort IS placed on getting development tools to 
run fast:

* Presumably, optimisation is applied to a compiler to get it faster 
than otherwise. But why bother if the difference is only a second or so?

* Tools can now do builds in parallel across multiple cores. Again, why? 
So that 1 second becomes 20 lots of 50ms? Or what that 1 second really 
have been 20 seconds without that feature?

* People are developing new kinds of linkers (I think there was 'gold', 
and now something else) which are touted as being several times faster 
than traditional

* All sorts of make and other files are used to define dependency graphs 
between program modules. Why? Presumably to minimise time spent recompiling.

* There various JIT compilation schemes where a rough version of an 
application can get up and running quickly, with 'hot' functions 
compiled and optimised on demand. Again, why?

If people really don't care about compilation speed, why this vast effort?

Getting development tools faster is an active field, and everyone 
benefits including you, but when I do it, it's a pointless waste of time?

 > As I said, no one is ever going to care if a compilation takes 1 second
 > or 0.1 seconds.

Have you asked? You must use interactive tools like shells; I guess you 
wouldn't want a pointless one second delay after each command, which you 
KNOW doesn't warrant such a delay.

That would surely slow you down if used to fluently firing off a rapid 
sequence of commands.

The problem is that you don't view use of a compiler as just another 
interactive command.

 > As I said, no one is ever going to care if a compilation takes 1 second
 > or 0.1 seconds.


Here's an actual use-case: I have a transpiler that produces a 
single-file C output of 40K lines. Tiny C can build it in 0.2 seconds. 
gcc -O0 takes 2.2 seconds. However there's no point in using gcc, as the 
generated code is as poor as Tiny C, so I might as well use that.

But if I want faster code, gcc -O2 takes 11 seconds.

For lots of routine builds used for testing, passing the intermediate C 
through gcc -O2 makes no sense at all. It is just a waste of time, 
destroys my train of thought, and is very frustrating.

However, if you ran the world, then tools like gcc and its ilk would be 
the only choice!

> So your advice is that developers should be stuck

I'm saying that most developers don't write their own tools. They will 
use off-the-shelf language implementations. If those happen to be slow, 
then there's little they can do except work within those limitations.

Or just twiddle their thumbs.



> 
> Which do you think an employer (or amateur programmer) would prefer?
> 
> a) A compiler that runs in 0.1 seconds with little static checking
> b) A compiler that runs in 10 seconds but spots errors saving 6 hours 
> debugging time

You can have both. You can run a slow compiler that might pick up those 
errors.

But sometimes you make a trivial mod (eg. change a prompt); do you 
REALLY need that deep analysis all over again? Do you still it fully 
optimised?

If your answer is YES to both then there's little point in further 
discussion.


> 
> I might spend an hour or two writing code (including planing, 
> organising, reading references, etc.) and then 5 seconds building it. 
> Then there might be anything from a few minutes to a few hours testing 
> or debugging.

Up to a few hours testing and debugging without need to rebuild? That 
last time I had to do that, it was a program written on punched cards 
that was submitted as an overnight job. You could compile it only once a 
day.

And you're accusing ME of being stuck in the 70s!

> But using a good compiler saves a substantial amount of developer time 

A better language too.



> <snip the rest to save time>

So you snipped my comments about fast bytecode compilers which do zero 
analysis being perfectly acceptable for scripting languages.

And my remark about my language edging towards behaving as a scripting 
language.

I can see why you wouldn't want to respond to that.

BTW I'm doing the same with C; given this program:

   int main(void) {
      int a;
      int* p = 0;
      a = *p;
  }

Here's what happens with my C compiler when told to interpret it:

   c:\cx>cc -i c
   Compiling c.c to c.(int)
   Error: Null ptr access

Here's what happens with gcc:

   c:\cx>gcc c.c
   c:\cx>a
   <crashes>

Is there some option to insert such a check with gcc? I've no idea; most 
people don't.