Hi,
On 12 Apr 2001, Steven Cole <[EMAIL PROTECTED]> 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
On Thursday 12 April 2001 10:51, Horst von Brand wrote:
> Steven Cole <[EMAIL PROTECTED]> 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,
Steven Cole <[EMAIL PROTECTED]> 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
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
On Thursday 12 April 2001 06:07, Dave Jones wrote:
> On Wed, 11 Apr 2001 [EMAIL PROTECTED] 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
On Wed, 11 Apr 2001 [EMAIL PROTECTED] 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 :-).
On Wed, 11 Apr 2001 [EMAIL PROTECTED] 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 :-).
On Thursday 12 April 2001 06:07, Dave Jones wrote:
On Wed, 11 Apr 2001 [EMAIL PROTECTED] 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
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
Steven Cole [EMAIL PROTECTED] 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
On Thursday 12 April 2001 10:51, Horst von Brand wrote:
Steven Cole [EMAIL PROTECTED] 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
Hi,
On 12 Apr 2001, Steven Cole [EMAIL PROTECTED] 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
Aaron Lehmann <[EMAIL PROTECTED]>:
> 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
On Wed, Apr 11, 2001 at 05:46:09PM -0400, [EMAIL PROTECTED] 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
Alan Cox <[EMAIL PROTECTED]>:
> 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
> 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
>
Michael Elizabeth Chastain <[EMAIL PROTECTED]>:
> 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.
>
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
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
Michael Elizabeth Chastain [EMAIL PROTECTED]:
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
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
Alan Cox [EMAIL PROTECTED]:
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
On Wed, Apr 11, 2001 at 05:46:09PM -0400, [EMAIL PROTECTED] 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
Aaron Lehmann [EMAIL PROTECTED]:
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
24 matches
Mail list logo
