From: david.brown@hesbynett.no
On 29/10/2025 22:21, bart wrote:
> On 29/10/2025 16:12, David Brown wrote:
>> On 29/10/2025 00:14, bart wrote:
>>> On 28/10/2025 21:59, Keith Thompson wrote:
>>>> bart writes:
>>>>> On 28/10/2025 02:35, Janis Papanagnou wrote:
>>>>>> On 27.10.2025 16:11, bart wrote:
>>>> [...]
>>>>>>> If speed wasn't an issue then we'd all be using easy dynamic
>>>>>>> languages
>>>>>> Huh? - Certainly not.
>>>>>
>>>>> *I* would! That's why I made my scripting languages as fast and
>>>>> capable as possible, so they could be used for more tasks.
>>>>>
>>>>> However, if I dare to suggest that even one other person in the world
>>>>> might also have the same desire, you'd say that I can't possibly know
>>>>> that.
>>>>>
>>>>> And yet here you are: you say 'certainly not'. Obviously *you* know
>>>>> everyone else's mindset!
>>>>
>>>> I'll give this one more try.
>>>>
>>>> This kind of thing makes it difficult to communicate with you.
>>>
>>> You're talking to the wrong guy. It's JP who's difficult to talk to.
>>>
>>> He (I assume) always dismisses every single one of my arguments out
>>> of hand:
>>>
>>> Build speed is never a problem - ever. The speed of any language
>>> implemention is never a concern either.
>>>
>>
>> Bart, I think this all comes down to some basic logic that you get
>> wrong regularly :
>>
>> The opposite of "X is always true" is /not/ "X is always false" or
>> that "(not X) is always true". It is that "X is /sometimes/ false",
>> or that "(not X) is /sometimes/ true".
>>
>> You get this wrong repeatedly when you and I are in disagreement, and
>> I see it again and again with other people - such as with both Janis
>> and Keith.
>>
Bart, did you understand what I wrote here? Do you agree with it - or
at least accept how your posts can be interpreted this way? If you
can't change the way you express yourself, these threads will always end
with you repeating wild exaggerations and generalisations on your
favourite rants, no matter what the original topic, and you'll again get
frustrated because you feel "everyone is against you". We get more than
enough of that with Olcott - I know you can do better.
>> No one, in any of the posts I have read in c.l.c. in countless years,
>> has ever claimed that "build speed is /never/ a problem". People have
>> regularly said that it /often/ is not a problem, or it is not a
>> problem in their own work, or that slow compile times can often be
>> dealt with in various ways so that it is not a problem. People don't
>> disagree that build speed can be an issue - they disagree with your
>> claims that it is /always/ an issue (except when using /your/ tools,
>> or perhaps tcc).
>
> It was certainly an issue here: the 'make' part of building CDECL and
> A68G, I considered slow for the scale of the task given that the apps
> are 68 and 78Kloc (static total of .c and .h files).
>
I have no interest in A68G. I have no stake in cdecl or knowledge (or
particular interest) in how it was written, and how appropriate the
number of lines of code are for the task in hand. I am confident it
could have been written in a different way with less code - but not at
all confident that doing so would be in any way better for the author of
the program. I am also confident that you know far too little about
what the program can do, or why it was written the way it was, to judge
whether it has a "reasonable" number of lines of code, or not.
However, it's easy to look at the facts. The "src" directory from the
github clone has about 50,000 lines of code in .c files, and 18,000
lines of code in .h files. The total is therefore about 68 kloc of
source. This does not at all mean that compilation processes exactly 68
thousand lines of code - it will be significantly more than that as
headers are included by multiple files, and lots of other headers from
the C standard library and other libraries are included. Let's guess
100 kloc.
The build process takes 8 seconds on my decade-old machine, much of
which is something other than running the compiler. (Don't ask me what
it is doing - I did not write this software, design its build process,
or determine how the program is structured and how it is generated by
yacc or related tools. This is not my area of expertise.) If for some
strange reason I choose to run "make" rather than "make -j", thus
wasting much of my computer's power, it takes 16 seconds. Some of these
non-compilation steps do not appear to be able to run in parallel, and a
couple of the compilations (like "parser.c", which appears to be from a
parser generator rather than specifically written) are large and take a
couple of seconds to compile. My guess is that the actual compilations
are perhaps 4 seconds. Overall, I make it 25 kloc per second. While I
don't think that is a particularly relevant measure of anything useful,
it does show that either you are measuring the wrong thing, using a
wildly inappropriate or limited build environment, or are unaware of how
to use your computer to build code. (And my computer cpu was about 30%
busy doing other productive tasks, such as playing a game, while I was
doing those builds.)
So, you are exaggerating, mismeasuring or misusing your system to get
build times that are well over an order of magnitude worse than
expected. This follows your well-established practice.
And you claim your own tools would be 1000 times faster. Maybe they
would be. Certainly there have been tools in the past that are much
smaller and faster than modern tools, and were useful at the time.
Modern tools do so much more, however. A tool that doesn't do the job
needed is of no use for a given task, even if it could handle other
tasks quickly.
But the crux of the matter, and I can't stress this enough as it never
seems to get through to you, is that fast enough is fast enough. No one
cares how long cdecl takes to build. Almost everyone who wants it will
download a binary file - "apt-get install cdecl", or similar. The only
people who bother to compile it are those who want the cutting edge
version. And even if it takes a minute or two to build, so what? It
does not matter. If it took an hour, that would be annoying if you
wanted to run it /now/, but even then if it were a useful tool (to the
user in question), all you need to do is start it running and then let
it churn away in the background. Computers are really good at doing
that kind of stuff, and don't get bored easily. Building is a one-time
task. (If the edit-build-test cycle for the developers took an hour,
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
