[ale] Linux kernel

Fri Nov 17 14:20:13 EST 2023

Heh. Reminds me of the guy at one of my old gigs who spent several weeks of
coding and testing to replace all of the simple sequential loop searches in
a pretty big application with sorts + binary searches.   The original
application took several hours to finish. After his optimizations, the new
version took about fifteen minutes less time.  **Always** profile before
you optimize!

-- CHS

On Fri, Nov 17, 2023 at 8:16 AM Jon "maddog" Hall via Ale <ale at ale.org>
wrote:

> Steve,
>
> >After all, Dbase was an interpreter so it had to be reparsed on every
> execution.
>
> Interpreters are separate beasts all to themselves, and I have never
> studied Dbase, but some interpreters keep a partial compilation around and
> only when the source code changes do they re-evaluate the source code.
> Often interpreters are used instead of compilers because they have a lot
> more data around for debugging.  For example, they can actually point to
> the source code statement and data item that causes an overflow or other
> exception.
>
> >Speaking of all that, what do you know about P-Code?
>
> It has been a long time since I looked at it, but P-Code is more or less a
> generic term for the level of compilation that creates "atoms", which can
> then be executed across architectures.   All of the lexical and syntactical
> analysis has been done and the "atoms" are generated that normally would go
> to the code generator (perhaps with some high-level optimizations done
> first) to generate the actual architecture-specific binaries.
>
> Imagine that each atom generated by the compiler simply calls a subroutine
> on the target system and that subroutine executes what the atom said to
> do.   This has been used by Pascal (the first time I heard of P-code), but
> has also been used by Java (Javabeans are the essence of this) and other
> systems.   A sub-class of this is what is known as "threaded interpretive
> languages".
>
> This can create executions as fast or even faster than compiled code, as
> the "subroutines" can be tuned very tightly to the architecture, and very
> highly optimized.
>
> >If I ever get to the point where my Stylz compiler is too slow, I'll
> write back to you for advice.
>
> It has been over thirty years since I taught compiler design, although I
> do take an interest from time to time in optimization techniques.
> When it comes to your compiler being too slow, I would first profile the
> complier and see where it is spending its time and why just like I would do
> any program.
>
> A friend of mine, Tom Tresvik (unfortunately now deceased) took the
> compiler that was compiling the Ultrix kernel and put it on a RAM disk.
> Reducing the I/O time from taking the source code and temporary files off
> the spinning disk and putting it in a RAM disk made the 24-hour compilation
> time of the Ultrix kernel on a VAX-11/780 to less than an hour.
>
> If I go on any further I might go into a deep discussion about
> optimizations, how important they are and how some people say that "memory
> is cheap, processors are fast and cores are plentiful and optimization is
> not really needed"....a statement *almost* as stupid as "comments slow
> compilation".   Actually there are many topics that people should really
> understand, but don't, and just thinking about these make me upset.
>
> Warmest regards,
>
> maddog
>
>
>
> On Thu, Nov 16, 2023 at 8:08 PM Steve Litt via Ale <ale at ale.org> wrote:
>
>> Thanks maddog!
>>
>> I would have figured the lexical analysis would have gotten rid of the
>> comments right away so nothing downstream had to deal with it. If I
>> ever get to the point where my Stylz compiler is too slow, I'll write
>> back to you for advice. Right now my level of understanding is so low
>> that it sounds like a pipedream, but I think I can do it.
>>
>> Copy that on comments making trouble with paper tape and 300 baud
>> modems. In fact, my buddy Bill who is a huge Foxbase expert, told me
>> around 1987 that for performance reasons he had to keep variable names
>> short in software he wrote in Dbase. After all, Dbase was an
>> interpreter so it had to be reparsed on every execution. Ugh!
>>
>> Speaking of all that, what do you know about P-Code?
>>
>> Thanks,
>>
>> SteveT
>>
>> Jon "maddog" Hall said on Thu, 16 Nov 2023 07:43:09 -0500
>>
>> >Steve,
>> >
>> >Different compilers are written in different ways, but in general you
>> >are right.   Compared to the lexical analysis, syntactical analysis and
>> >optimization stages (ESPECIALLY OPTIMIZATION) the tokenization stage
>> >(which includes removing comments) is a blip in the timeline of
>> >compilation.
>> >
>> >I will say that comments DID have a real impact when compilers were
>> >reading in source code on paper tape on an ASR-33 Teletype, but that
>> >was the last time I even considered the issue oft compilation time
>> >being slowed down by comments.
>> >
>> >md
>> >
>> >On Wed, Nov 15, 2023 at 10:08 PM Steve Litt via Ale <ale at ale.org>
>> >wrote:
>> >
>> >> Jon "maddog" Hall via Ale said on Wed, 15 Nov 2023 19:28:38 -0500
>> >>
>> >> >The other thing that surprised me was the passage that said
>> >> >"Comments just slow down the compilation".
>> >> >
>> >> >Paaaaleese!  Even the heaviest commented source code on a compiled
>> >> >program would be a breeze for the compiler to handle.  This excuse
>> >> >is fake news.
>> >>
>> >> Maddog, is the first step, before lexical analysis, replacing all
>> >> space characters and newlines with tokens so the lexical analyzer
>> >> sees the program as a single string?
>> >>
>> >> If that's the case, I can see where // to the next linefeed and /* to
>> >> the next */ would be very fast.
>> >>
>> >> Thanks,
>> >>
>> >> SteveT
>> >>
>> >> Steve Litt
>> >>
>> >> Autumn 2023 featured book: Rapid Learning for the 21st Century
>> >> http://www.troubleshooters.com/rl21
>> >> _______________________________________________
>> >> Ale mailing list
>> >> Ale at ale.org
>> >> https://mail.ale.org/mailman/listinfo/ale
>> >> See JOBS, ANNOUNCE and SCHOOLS lists at
>> >> http://mail.ale.org/mailman/listinfo
>> >>
>>
>>
>> SteveT
>>
>> Steve Litt
>>
>> Autumn 2023 featured book: Rapid Learning for the 21st Century
>> http://www.troubleshooters.com/rl21
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> https://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20231117/e01fe2b2/attachment.htm>