Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Michael Elizabeth Chastain]

I like mconfig, but I like CML2 better.

My primary reason is that ESR has more time to work on CML2 than I do
on mconfig.  And speed problems are often the easiest problems to solve.

Eric did some performance analysis.  If I recall correctly, all but 1
or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
parser once.  Maybe someone needs to rewrite it again, maybe propagate
some changes into the language spec to make it easier to parse, maybe
rewrite from Python to C.

Michael

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Michael Elizabeth Chastain <chastain@cygnus.com>:
> I like mconfig, but I like CML2 better.

Reminder for the rest of you: Michael *wrote* mconfig.

> My primary reason is that ESR has more time to work on CML2 than I do
> on mconfig.  And speed problems are often the easiest problems to solve.
> 
> Eric did some performance analysis.  If I recall correctly, all but 1
> or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
> parser once.  Maybe someone needs to rewrite it again, maybe propagate
> some changes into the language spec to make it easier to parse, maybe
> rewrite from Python to C.

The *language compiler's* runtime got cut in half when I hand-rolled a
parser for it.  The speed problem now is in the configurator itself.
One of my post-1.0.0 challenges is to profile and tune the configurator
code to within an inch of its life.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

'Faith' means not _wanting_ to know what is true.
	-- Nietzsche, Der Antichrist

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Alan Cox]

> Eric did some performance analysis.  If I recall correctly, all but 1
> or 2 seconds of CML2's runtime is in the parser.  He has rewritten the
> parser once.  Maybe someone needs to rewrite it again, maybe propagate
> some changes into the language spec to make it easier to parse, maybe
> rewrite from Python to C.

CML2 seems to have two other problems in my mind. Inability to parse the
existing config files. Also the draw ordering in the menu based config doesnt
appear right. Menuconfig has a rather undocumented but very important property
of doing roughly the right thing with screenreaders. Something to bear in mind
when fixing the menu redrawing stuff.

Alan

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> CML2 seems to have two other problems in my mind. Inability to parse
> the existing config files.

I gave upon that early for two reasons.  One was practical; Michael tried this
with mconfig, and (apparently) failed.  Or, at least, appeared to have decided
that path was not worth pursuing.

The other was the procedural vs. declarative problem.  I spent about a
month after the kbuild team originally encouraged me to tackle the
problem working on a design which I later labeled Thesis.  This was an
attempt to build a cleaned-up CML1, basically the existing language
without the syntactic warts.  I got as far as spinning up an
incomplete implementation that could check toy configurations.

But the design basically didn't work.  The problem is that a
procedural language imposes a kind of time order that makes it very
difficult to (a) do backtracking and (b) prove the correctness of your
result.  Perhaps a clearer way to put it is that configuration (like, say,
screen widget layout) is fundamentally a constraint problem rather
than a control problem.

A constraint problem needs a declarative rather than imperative
language, and it needs a baby reasoning engine to generate a
constraint-satisfying solution (Tk approaches screen-widget layout
this way; that's thye source of its power).  Neither of my strawman
designs had significant advantage over CML1 until I bit the bullet and
wrote a theorem prover to reason about timeless constraints.

>                        Also the draw ordering in the menu based
> config doesnt appear right. Menuconfig has a rather undocumented but
> very important property of doing roughly the right thing with
> screenreaders. Something to bear in mind when fixing the menu
> redrawing stuff.

Yes, I have plans for this.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
        -- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Aaron Lehmann]

On Wed, Apr 11, 2001 at 05:46:09PM -0400, esr@thyrsus.com wrote:
> The speed problem now is in the configurator itself.
> One of my post-1.0.0 challenges is to profile and tune the configurator
> code to within an inch of its life.

Maybe you could kill two birds with one stone by calling 1.0.0 the
prototype and rewriting it in C. Not only would this improve speed
(algorithmic improvements would also be welcome...), but it would
remove the pythonic obstacle to its adoption as a standard. Many,
including me, oppose writing the standard configurator in Python. I
don't have Python installed and I'm not going to install yet another
scripting language just because ESR likes it. Yes, we know about
freeze support, but aren't convinced that it will do well at this. It
seems that a native C configurator will be both faster and more
portable (accross distributions and mindsets) than something requiring
a recent version of SuperEasyInterpretedProgrammingLanguage 2.0.

I know that you're reluctant to make the port, but you don't need to
be too shy to ask for help. Few people on this list are afraid of C.
If you're too lazy to implement CML2 in a standard, popular, robust
language, heck, tell us, and we may be able to help you out.

Sorry for the anti-Python flamage. I'm sure that it has its uses. I,
however, don't view it as appropriate for configuration of an integral
component of a GNU/Linux system. I want to make the view clear to aid
Linus with his descision and to encourage a C port of CML2, which
languages aside looks like a good format and concept BTW.

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[esr]

Aaron Lehmann <aaronl@vitelus.com>:
> Maybe you could kill two birds with one stone by calling 1.0.0 the
> prototype and rewriting it in C.

If I were to become absolutely convinced that I can't get acceptable speed
out of Python, I might do that.  There's a gcml project that tracked the CML2
compiler up to about 0.72 level that might make a decent starting point.

Unfortunately, I'm fairly sure that finishing gcml would take long
enough to render the point moot, because by the time it was done the
average Linux machine would have sped up enough for the Python
implementation not to be laggy anymore :-).

No joke -- *you* try writing a theorem-prover in a language with only
fixed-extent data types.  Go on.  Try it.  I think you will (as Mark
Twain put it about the consequences of teasing a cat) acquire a
valuable education, the facts of which will never grow dim or
doubtful.

I'm pretty sure that tuning the Python implementation (coming up with
faster algorithms, perhaps by reorganizing the data structures to do
more precomputation) will be a more effective use of my time.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
        -- Constitutional scholar and Supreme Court Justice Joseph Story, 1840

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 06:07, Dave Jones wrote:
> On Wed, 11 Apr 2001 esr@thyrsus.com wrote:
> > Unfortunately, I'm fairly sure that finishing gcml would take long
> > enough to render the point moot, because by the time it was done the
> > average Linux machine would have sped up enough for the Python
> > implementation not to be laggy anymore :-).
>
> 'Average' Linux machine is irrelevant. I still have a Sparc IPX
> I occasionally use. I know people using still using 486's as they
> can't afford anything better. Hell, even some of my P5 class machines
> are starting to show their age, but they're still in daily use.
> To say "Screw them, upgrade" is not an option IMO.

Excuse me, but this seems to be something of a red herring.  I've got
a crowd of Pentium-90 and 100 machines at work, and they get new kernels
occasionally, but I haven't built a kernel using that class of machine
in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
"fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
I have much better things to do with my time.

It would seem to me that if someone is using an older and slower machine
to build a kernel, they are probably doing this somewhat infrequently,
and the longer build process, although more painful for those few users,
should be endurable if it is indeed infrequent.

Keep in mind that making a kernel on a current machine has gone from 
a couple of hours (1992) to two minutes (2001).  Adding seconds or tens 
of seconds at this time on 2001 hardware will seem very moot by the 
time 2.5/2.6 is at the point 2.4.x is now.

If you haven't seen my posts here before, I just joined this list last night.

Steven

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Wed, 11 Apr 2001 esr@thyrsus.com wrote:

> Unfortunately, I'm fairly sure that finishing gcml would take long
> enough to render the point moot, because by the time it was done the
> average Linux machine would have sped up enough for the Python
> implementation not to be laggy anymore :-).

'Average' Linux machine is irrelevant. I still have a Sparc IPX
I occasionally use. I know people using still using 486's as they
can't afford anything better. Hell, even some of my P5 class machines
are starting to show their age, but they're still in daily use.
To say "Screw them, upgrade" is not an option IMO.

> I'm pretty sure that tuning the Python implementation (coming up with
> faster algorithms, perhaps by reorganizing the data structures to do
> more precomputation) will be a more effective use of my time.

Well if you can make this run faster, this would kill my main
complaint with CML2.  I'll try out an updated version sometime.

regards,

Davej.

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Dave Jones]

On Thu, 12 Apr 2001, Steven Cole wrote:

> Excuse me, but this seems to be something of a red herring.
> ...
>  Adding seconds or tens of seconds at this time on 2001 hardware will
> seem very moot by the time 2.5/2.6 is at the point 2.4.x is now.

Adding tens of seconds per build is not acceptable when you're building
a lot of kernels each day.

The beginning of this thread showed a 15 second stall on an Athlon 800,
vs a 1 second startup for the old system. The point now is that
Eric _is_ working on improving the performance. (Which was probably
in another post you missed).

> If you haven't seen my posts here before, I just joined this list last night.

Find a list archive, read the beginning of the thread.

regards,

Dave.

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Steven Cole]

On Thursday 12 April 2001 10:51, Horst von Brand wrote:
> Steven Cole <elenstev@mesatop.com> said:
>
> [...]
>
> > It would seem to me that if someone is using an older and slower machine
> > to build a kernel, they are probably doing this somewhat infrequently,
> > and the longer build process, although more painful for those few users,
> > should be endurable if it is indeed infrequent.
>
> Please stop a moment and _think_.
>
> There are people out there that have got a P/90 or less, or just a Sun IPX,
> no network access (or slow phone lines at high prices). That _you_ have a
> dual P3/733 doesn't help them one bit, now does it.

Actually, I did think, and then thought a little more.  Here is a snippet
of what I posted earlier:

>Upon further reflection, the added several second stall will probably be
>a thorn in many people's sides, as it comes while the user is impatiently
>waiting for it to launch.  I don't use StarOffice because it takes 12-15
>seconds to start up and that just seems too long.
>
>So any efforts to reduce the stall will probably have a leveraged
>effect which is much greater than might otherwise seem at first glance.

Sorry, I guess its all too easy to get spoiled quickly with new hardware.
And I'm one of those with slow phone lines.

Steven

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Horst von Brand]

Steven Cole <elenstev@mesatop.com> said:

[...]

> It would seem to me that if someone is using an older and slower machine
> to build a kernel, they are probably doing this somewhat infrequently,
> and the longer build process, although more painful for those few users,
> should be endurable if it is indeed infrequent.

Please stop a moment and _think_.

There are people out there that have got a P/90 or less, or just a Sun IPX,
no network access (or slow phone lines at high prices). That _you_ have a
dual P3/733 doesn't help them one bit, now does it.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [kbuild-devel] Re: CML2 1.0.0 release announcement

[Jochen Striepe]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

        Hi,

On 12 Apr 2001, Steven Cole <elenstev@mesatop.com> wrote:
> 
> Excuse me, but this seems to be something of a red herring.  I've got
> a crowd of Pentium-90 and 100 machines at work, and they get new kernels
> occasionally, but I haven't built a kernel using that class of machine
> in 5 years or so.  I build new kernels using a dual 733 PIII.  Just for
> "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but
> I have much better things to do with my time.

I have an AMD K6/2-400. But I do know _many_ people who do own slower
Hardware, and run Linux on it. They do not want and cannot afford to buy
the newest shiny box. And, they have better things to do with their time
as well. Please note, I live in a country where people are not _poor_.
Just think of others some time, not only of yourself. 


So long,

Jochen Striepe.

-- 
"He was so narrow minded he could see through a keyhole with both
eyes ..."


[-- Attachment #2: Type: application/pgp-signature, Size: 524 bytes --]