From: vallor@vallor.earth
At Wed, 29 Oct 2025 21:21:34 +0000, 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.
> >
> > 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).
Not sure if it's worth it, but my 2 cents:
You can throw more processors at your "make" with the "-j" switch,
something like:
$ make -j $(nproc)
Where $(nproc) substitutes the number of processors on your system
for a parallel make.
>
> A68G I know takes 90 seconds to build (since I've just tried it again;
> it took long enough that I had an ice-cream while waiting, so that's
> something).
>
> That's under 1Kloc per second; not great.
>
> But at least all the optimising would have produced a super-fast
> executable? Well, that's disappointing too; no-one can say that A68G is
> fast.
>
> I said that my equivalent product was 1000 times faster to build (don't
> forget the configure nonsense) and it ran 10 times faster on the same test.
>
> That is a quite remarkable difference. VERY remarkable. Only some of it
> is due to my product being smaller (but it's not 1000 times smaller!).
>
> This was stated to demonstrate how different my world was.
>
> My view is that there is something very wrong with the build systems
> everyone here uses. But I can understand that no one wants to admit that
> they're that bad.
>
> You find ways around it, you get inured to it, but you just have to use
> much more powerful machines than mine, but I would go round the bend if
> I had to work with something so unresponsive.
>
--
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090Ti 24G
OS: Linux 6.17.5 D: Mint 22.2 DE: Xfce 4.18
NVIDIA: 580.95.05 Mem: 258G
"Let's split up, we can do more damage that way."
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
