Re: [9fans] GCC3.0 [Was; Webbrowser]

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Keith Nash]

> I wouldnt worry about the 10% performance difference between Plan 9
> implementation and FreeBSD or Linux. What matters is whether we can
> tolerate the performance loss. As long as my apps like acme, sam, charon,
> etc run sufficiently fast, why would I worry?

> > We know Plan 9 has the better design, code, capabilities, etc. It would
> > be nice at some point to be able to say that speed is a distinguishing
> > feature of Plan 9. Is it fundamentally impossible?

This is an important issue if we want Plan 9 to be more widely deployed.  I guess that not many users care about 10% differences in performance - but if Plan 9 is (say) three times slower than Unix, its user base will always be limited.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Tharaneedharan Vilwanathan]

Hi,

> > I wouldnt worry about the 10% performance difference between Plan 9
> > implementation and FreeBSD or Linux. What matters is whether we can
> > tolerate the performance loss. As long as my apps like acme, sam,
charon,
> > etc run sufficiently fast, why would I worry?
>
> > > We know Plan 9 has the better design, code, capabilities, etc. It
would
> > > be nice at some point to be able to say that speed is a distinguishing
> > > feature of Plan 9. Is it fundamentally impossible?
>
> This is an important issue if we want Plan 9 to be more widely deployed.
I guess that not many users care about 10% differences in performance - but
if Plan 9 is (say) three times slower than Unix, its user base will always
be limited.

The strengths of Plan 9 should be the reason for wide deployment instead of
performance figures. Things like venti, fossil, factotum and revved up
graphics module are excellent additions to Plan 9 in the recent time. I
would like to see these kind of enhancements to Plan 9 rather than racing
with other OS'es in terms of performance. Of course, if someone can cleanly
modify the code for some critical performance improvement, thats fine.
Otherwise, let us not try to make Plan 9 another *nux* or *BSD.

IMHO.

Regards
dharani

PS: The opinions are just mine, not company's.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Russ Cox]

> Otherwise, let us not try to make Plan 9 another *nux* or *BSD.

people have been using this abbreviation
a lot recently.  surely you mean *n*x* rather
than *nux*.  i should go out and build
a unix clone called uxin so that you'd have to
call it a ***** clone, or maybe a !@#$% clone.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Jack Johnson]

Russ Cox wrote:
>>Otherwise, let us not try to make Plan 9 another *nux* or *BSD.
> people have been using this abbreviation
> a lot recently.  surely you mean *n*x* rather
> than *nux*.  i should go out and build
> a unix clone called uxin so that you'd have to
> call it a ***** clone, or maybe a !@#$% clone.

I think it's something like *n[ui]x(c), though it's still !@#$%.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Richard Miller]

> I think it's something like *n[ui]x(c), though it's still !@#$%.

Not good enough - doesn't match Xinu. Or Idris.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[matt]

> > I think it's something like *n[ui]x(c), though it's still !@#$%.
>
> Not good enough - doesn't match Xinu. Or Idris.

or, horrors, Xenix

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Boyd Roberts]

I always liked 'lunix'.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Geoff Collyer]

> Otherwise, let us not try to make Plan 9 another *nux* or *BSD.

I just call them all `lunix'.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Skip Tavakkolian]

> !@#$% clone.

As a side note, I'm surprised there isn't a Unicode symbol for !@#$%

Re: [9fans] GCC3.0 [Was; Webbrowser]

[okamoto]

I was too late.   It's all over while I was in bed. ☺

> The least of my desires was to judge plan9 based on the results of
> this 'benchmark'..

I remind that we usually make serious decision without measuring it,
rather just based on our feelings.   The most important one to us may be
to select our partner, and at such scene we are at most emotional,
not logical.  Then, we fail sometime? ☺

I suppose it is the very nice or bad human nature probably comes from
very deep of us.   I choose my OS through such process.   'benchmark'
is necessary only to endorse one to someone else.   Unfortunately, and
usually, the one compelled by the 'benchmark' will not love it, but just
accept it.   We need such acceptants?, yes, indeed.   However, now we
need more developpers to love it, where no 'benchmark' but just good
nature is required...

Sorry, my redundant.

Kenji  -- to 9fans

Re: [9fans] GCC3.0 [Was; Webbrowser]

[C H Forsyth]

>>that's fine if your idea of the world is developer minutes. But there's
>>this other thing called "the guys who pay the bill minutes", i.e.
>>(l)users, and they are less willing to take slower systems.

but the most popular system on the planet is in many commonly-used activities
very--even painfully--slow indeed!

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, C H Forsyth wrote:

> but the most popular system on the planet is in many commonly-used activities
> very--even painfully--slow indeed!

yeah and I don't use it.

Anyway, I was mainly asking a question, it's been answered, so time to
move on.

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[okamoto]

> here are the highly scientific results I got:

Cordially, I must say this is not scientific. ?

I think the speed is not the main matter of Plan 9, anyway.

Kenji

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

On Thu, 6 Feb 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> Cordially, I must say this is not scientific. ?
>
> I think the speed is not the main matter of Plan 9, anyway.


Yes, you're right, they are not scientific. I forgot the smiley at the end
--> :)

plan9 may not be about speed, but it's so much fun to measure the lack
thereof... after all I wasn't going to send my results to the list, but
since the GCC discussion started, I decided it was a nice example of its
use...

The least of my desires was to judge plan9 based on the results of
this 'benchmark'..

andrey

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> I think the speed is not the main matter of Plan 9, anyway.

My memory is at some point it was. An intro by Honeyman at the '89 Usenix
for a Plan 9 speaker ended with "... and he can't believe how slow X11
is". Gosh, was it even called Plan 9 then? Is my memory wrong? I think it
was starting to be called Plan 9.

Did speed stop being a goal when Plan 9 got slower? Personally, I like
speedy OSes. I do recall an Infocomm in 1996 where a speaker from Bell
Labs (Holmdel) presented numbers showing FreeBSD running 10% faster than
Plan 9 for some TCP measurements. I was surprised, as until that time I
had assumed Plan 9 would be faster. So had the speaker. So had, according
to the speaker, the folks at Murray Hill. Nobody expected FreeBSD to win
that race.

Side note: at some point (late 70s) I think I used just about every OS
that ran on a PDP11 (including the Pascal-based one from Hansen, not the
boy-band, but Per Brinch). For speed, V6 Unix always crushed them all,
including the vendor OSes which were supposed to be so much superior (e.g.
RSX). Speed was one distinguishing feature of Unix, the others being
better design, code, capabilities, and, oh, everything else.

We know Plan 9 has the better design, code, capabilities, etc. It would be
nice at some point to be able to say that speed is a distinguishing
feature of Plan 9. Is it fundamentally impossible?

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Tharaneedharan Vilwanathan]

Hi,

I like the current implementation of Plan 9. It is sufficiently fast,
stable, clean and simple to understand. If there is a severe performance
problem, someone always takes care of it.

I wouldnt worry about the 10% performance difference between Plan 9
implementation and FreeBSD or Linux. What matters is whether we can tolerate
the performance loss. As long as my apps like acme, sam, charon, etc run
sufficiently fast, why would I worry?

I also like the clean screen when Plan 9 (rio) starts: it is like starting
with a clean slate.

Regards
dharani

> On Thu, 6 Feb 2003 okamoto@granite.cias.osakafu-u.ac.jp wrote:
>
> > I think the speed is not the main matter of Plan 9, anyway.
>
> My memory is at some point it was. An intro by Honeyman at the '89 Usenix
> for a Plan 9 speaker ended with "... and he can't believe how slow X11
> is". Gosh, was it even called Plan 9 then? Is my memory wrong? I think it
> was starting to be called Plan 9.
>
> Did speed stop being a goal when Plan 9 got slower? Personally, I like
> speedy OSes. I do recall an Infocomm in 1996 where a speaker from Bell
> Labs (Holmdel) presented numbers showing FreeBSD running 10% faster than
> Plan 9 for some TCP measurements. I was surprised, as until that time I
> had assumed Plan 9 would be faster. So had the speaker. So had, according
> to the speaker, the folks at Murray Hill. Nobody expected FreeBSD to win
> that race.
>
> Side note: at some point (late 70s) I think I used just about every OS
> that ran on a PDP11 (including the Pascal-based one from Hansen, not the
> boy-band, but Per Brinch). For speed, V6 Unix always crushed them all,
> including the vendor OSes which were supposed to be so much superior (e.g.
> RSX). Speed was one distinguishing feature of Unix, the others being
> better design, code, capabilities, and, oh, everything else.
>
> We know Plan 9 has the better design, code, capabilities, etc. It would be
> nice at some point to be able to say that speed is a distinguishing
> feature of Plan 9. Is it fundamentally impossible?
>
> ron
>

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, Tharaneedharan Vilwanathan wrote:

> I wouldnt worry about the 10% performance difference between Plan 9
> implementation and FreeBSD or Linux.

No, my note said "10% on one TCP benchmark in 1996 which Plan 9 was
expected to win". That's actually a bit different from "10% performance
difference". 1996 was a long time ago; freebsd just keeps getting faster.

The real question for me is whether the speed difference is fundamental or
not. I don't know enough to know. It's an issue here because I've been
pushing Plan 9 as a possible future OS for DOE use (assuming we can get
the legal mess fixed), due to its really nice architecture. But if it is
not ever going to be competitive performance-wise with *nux* then that is
a huge problem.  If it is fixable, well, there will be money to fix it at
some point (again, assuming Lucent can provide a sane license agreement).

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[rob pike, esq.]

Plan 9 was really not designed with performance in mind.  It was
designed to push some Unix ideas in new directions, to build an
operating system with networking at its core instead of an add-on bag,
to design a system interface that would make window systems easy to
write, and to be clean code.

I think it's that last point that might make you think Plan 9 was
designed for speed.  Execute less code, run faster.  But to get those
10% tweaks everybody fusses over, to the detriment of just about
everything in computing, you need to tune and tune and fuss and tweak
and hack, and that does not leave you with clean code.  Plan 9 is
fundamentally efficient in the sense that its interfaces are clean and
the code is modest in scope, but it will not win most performance
races that depend on benchmarks.

On the other hand, the kernel compiles in a few seconds on a modest
modern computer.  The entire tree - everything - builds in a few
minutes (and by far the largest piece of that time is compiling
applications written outside an imported, such as gs).  Now that is
performance I care about.

-rob

Re: [9fans] GCC3.0 [Was; Webbrowser]

[rob pike, esq.]

Oh, and another thing - we ran very few benchmarks or efficiency tests
over the years.  When we did, it was because someone asked us, because
we had some big new component (like a new network interface) we wanted
to try out, or because we needed to have numbers to publish a paper.
In other words, making measurements to test performance was never a
priority, and that means the measurements themselves were never a
priority.

I'm not saying running fast is bad, I'm just saying we tried to write
a smooth, efficient system by design, but we were not willing (or even
thinking) to make our code ugly to achieve ultimate speed.

-rob

Re: [9fans] GCC3.0 [Was; Webbrowser]

[matt]

As the introduction [http://plan9.bell-labs.com/sys/doc/9.html] says :

Producing a more efficient way to run the old UNIX warhorses is empty
engineering; we were more interested in whether the new ideas suggested by
the architecture of the underlying system encourage a more effective way of
working.



I like the approach that believes CPU cycles can be bought cheaper than
developer minutes.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, matt wrote:

> I like the approach that believes CPU cycles can be bought cheaper than
> developer minutes.

that's fine if your idea of the world is developer minutes. But there's
this other thing called "the guys who pay the bill minutes", i.e.
(l)users, and they are less willing to take slower systems.

Anyway, I am not taking exception to the decisions behind Plan 9 *in it's
current state*, I am merely asking: now that we have a model for an OS
that looks like a far better model than what *nux* offers, can we speed
that OS up to be competitive without destroying it? Or is what we have
about as good as it will get?

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Tharaneedharan Vilwanathan]

Hi,

> > I like the approach that believes CPU cycles can be bought cheaper than
> > developer minutes.
>
> that's fine if your idea of the world is developer minutes. But there's
> this other thing called "the guys who pay the bill minutes", i.e.
> (l)users, and they are less willing to take slower systems.
Yeah, I agree that for a real production system, Plan 9 solution may not be
as attractive as *nux* or *BSD. But then I think one can improve the
performance by using real good hadware parts and careful system architecture
(say, a good distributed architecture with a good network of machines).

> Anyway, I am not taking exception to the decisions behind Plan 9 *in it's
> current state*, I am merely asking: now that we have a model for an OS
> that looks like a far better model than what *nux* offers, can we speed
> that OS up to be competitive without destroying it? Or is what we have
> about as good as it will get?
Can you say which part of the system needs improvement? File System?
Networking? And can you also give more details on the particular area?

Regards
dharani

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

On Thu, 6 Feb 2003, Tharaneedharan Vilwanathan wrote:

> Can you say which part of the system needs improvement? File System?
> Networking? And can you also give more details on the particular area?
>

currently the part of the system that needs improvement the most is the
license (at least that's what the people at LANL think).

short of starting another license flamewar, i'm simply saying this because your
mail address appears to be related to the party responsible for this
(though i'm not saying you are :)

there are three separate places so far that have said "yes, you can work
with p9, yes, we may even help you with it, but please fix the license". it
doesn't bother me personally, it bothers the institution i'm a part of...

</rant>

andrey

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Sam]

>
> > I like the approach that believes CPU cycles can be bought cheaper than
> > developer minutes.
>
> that's fine if your idea of the world is developer minutes. But there's
> this other thing called "the guys who pay the bill minutes", i.e.
> (l)users, and they are less willing to take slower systems.
>

Aside:
They're also less willing to change their computing environment
due to the false belief that system interfaces are incremental;
anything not resembling WIMP is met with resistance.  I personally
believe our approach is better, but I'll settle for "different"
simply because you either get it or you don't.  It's just not a
matter of whether my window system is faster than yours.

Since 9's end users are developers, it makes sense to compare our view
of "speed" with others.  Rob did a great job of building a system
that lacks barriers to developing software; everything flows very
nicely.  I wouldn't trade that for a TCP implementation that runs
10% faster.

> Anyway, I am not taking exception to the decisions behind Plan 9 *in it's
> current state*, I am merely asking: now that we have a model for an OS
> that looks like a far better model than what *nux* offers, can we speed
> that OS up to be competitive without destroying it? Or is what we have
> about as good as it will get?

I just don't understand what you conceive as "slow."  Speedups should be
done only where they're demonstrably necessary - not because the
"competitor" can do it in n less microseconds.  Besides, you're
comparing *nix to something resembling UNIX.  It just doesn't work.
Sure, UNIX was the computation king in its day, but that was
accomplished with solid design.

Look at it this way; 9 transcends the speed race by keeping the
system "fast enough" as opposed to chasing an unnecessary goal.
If the "competition" wants to compare microseconds, let 'em.
While they're busy tweaking I'll be developing software to
do something useful.  I suspect my peers will too.

Sam

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, Sam wrote:

> I just don't understand what you conceive as "slow."

Well, on Pink, a 1024-node cluster we just built here, I can fire up a
command to 1024 nodes from start to completion in < 4 seconds, and we
consider that slow. Lest you think this a worthless benchmark I can tell
you that startup overhead matters when scaling to this size system. My
hunch is that Plan 9 would not start up quite this fast. But that is only
based on very limited experience with 'cpu'.

But you are correct in that I am not being specific. Sadly, my impressions
are based on work done here last summer measuring TCP etc., and Andrey
knows way better than I what the outcome of that was.

However that doesn't much matter; what I'm taking from this discussion is
that most Plan 9 users, who are developers not end-users, are satisfied
with the performance of the system as is and see no need to try to make it
competitive with the *nux* breeds. Given the overall far better quality of
Plan 9 as an OS I find that understandable.

That said, I did think David Butler's remarks were pretty interesting.

Thanks

ron
p.s. What I really want to know: is Google going to run Plan 9 :-)

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

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

I was under the impression that Dong and I had fixed the TCP problems LANL was
having.  Is this incorrect?  Could you tell me what's still slow?  I really
do want our IP stack to stay competative.  Our next move is to take advantage
of the hardware checksuming on the gigabit boards since, in our most recent
testing, we seem to differ from BSD speeds most because of that.

[-- Attachment #2: Type: message/rfc822, Size: 3097 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
Date: Thu, 6 Feb 2003 11:07:13 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302061047570.11322-100000@carotid.ccs.lanl.gov>

On Thu, 6 Feb 2003, Sam wrote:

> I just don't understand what you conceive as "slow."

Well, on Pink, a 1024-node cluster we just built here, I can fire up a
command to 1024 nodes from start to completion in < 4 seconds, and we
consider that slow. Lest you think this a worthless benchmark I can tell
you that startup overhead matters when scaling to this size system. My
hunch is that Plan 9 would not start up quite this fast. But that is only
based on very limited experience with 'cpu'.

But you are correct in that I am not being specific. Sadly, my impressions
are based on work done here last summer measuring TCP etc., and Andrey
knows way better than I what the outcome of that was.

However that doesn't much matter; what I'm taking from this discussion is
that most Plan 9 users, who are developers not end-users, are satisfied
with the performance of the system as is and see no need to try to make it
competitive with the *nux* breeds. Given the overall far better quality of
Plan 9 as an OS I find that understandable.

That said, I did think David Butler's remarks were pretty interesting.

Thanks

ron
p.s. What I really want to know: is Google going to run Plan 9 :-)

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, David Presotto wrote:

> I was under the impression that Dong and I had fixed the TCP problems LANL was
> having.  Is this incorrect?  Could you tell me what's still slow?  I really
> do want our IP stack to stay competative.  Our next move is to take advantage
> of the hardware checksuming on the gigabit boards since, in our most recent
> testing, we seem to differ from BSD speeds most because of that.

David, thanks for the note, and once I manage to stand some Plan 9 nodes
back up, we'll try it again. Sorry I am being so non-specific.

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Dean Prichard]

Last time i ran tests (after Presotto fixes) if i recall
correctly plan9 was very close to FreeBSD on netpipe tcp
performance on 100BT, and that is preety amazing in my book
as the plan9 tcp code is a lot smaller and cleaner than
FreeBSD's.  GigE performance was not so good, probably
because of the lack of window scale option.

On Thu, 6 Feb 2003, Ronald G. Minnich wrote:

> Date: Thu, 6 Feb 2003 11:17:26 -0700 (MST)
> From: Ronald G. Minnich <rminnich@lanl.gov>
> Reply-To: 9fans@cse.psu.edu
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
>
> On Thu, 6 Feb 2003, David Presotto wrote:
>
> > I was under the impression that Dong and I had fixed the TCP problems LANL was
> > having.  Is this incorrect?  Could you tell me what's still slow?  I really
> > do want our IP stack to stay competative.  Our next move is to take advantage
> > of the hardware checksuming on the gigabit boards since, in our most recent
> > testing, we seem to differ from BSD speeds most because of that.
>
> David, thanks for the note, and once I manage to stand some Plan 9 nodes
> back up, we'll try it again. Sorry I am being so non-specific.
>
> ron
>
>
>

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

this is the last message on this subject:

https://lists.cse.psu.edu/archives/9fans/2002-May/017658.html

(it doesn't appear on groups.google.com though, I don't know why -- maybe
the pics attached are to blame?)

indeed we were able to measure improvement in speed, but the behaviour was
still strange, yet even stranger when iostats was involved.

andrey

On Thu, 6 Feb 2003, David Presotto wrote:

> I was under the impression that Dong and I had fixed the TCP problems LANL was
> having.  Is this incorrect?  Could you tell me what's still slow?  I really
> do want our IP stack to stay competative.  Our next move is to take advantage
> of the hardware checksuming on the gigabit boards since, in our most recent
> testing, we seem to differ from BSD speeds most because of that.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

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

I'll try to reproduce it but I believe that's the bug we fixed.  I'll let you know after
I try.

[-- Attachment #2: Type: message/rfc822, Size: 2645 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
Date: Thu, 6 Feb 2003 11:35:16 -0700 (MST)
Message-ID: <20030206113325.O535@fbsd.cpsc.ucalgary.ca>

this is the last message on this subject:

https://lists.cse.psu.edu/archives/9fans/2002-May/017658.html

(it doesn't appear on groups.google.com though, I don't know why -- maybe
the pics attached are to blame?)

indeed we were able to measure improvement in speed, but the behaviour was
still strange, yet even stranger when iostats was involved.

andrey

On Thu, 6 Feb 2003, David Presotto wrote:

> I was under the impression that Dong and I had fixed the TCP problems LANL was
> having.  Is this incorrect?  Could you tell me what's still slow?  I really
> do want our IP stack to stay competative.  Our next move is to take advantage
> of the hardware checksuming on the gigabit boards since, in our most recent
> testing, we seem to differ from BSD speeds most because of that.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

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

I didn't use iostats to speed things up because we don't need it
now that the bug is fixed.  Here's a bunch of runs with the bug
fixed (actually there were a few bugs, one with acks and one
with coalescing writes before sends).  I could have sworn I'ld
mailed you guys but I'ld just come back to lucent so maybe I
was in daze...

presotto@lauro% for(i in 8000 16000 32000 64000 128000 150000 200000 250000)
	netpipe -l $i prestotest
    8000 Bpp    54352 kbps
   16000 Bpp    66144 kbps
   32000 Bpp    78064 kbps
   64000 Bpp    82992 kbps
  128000 Bpp    86720 kbps
  150000 Bpp    87952 kbps
  200000 Bpp    87760 kbps
  250000 Bpp    90816 kbps

[-- Attachment #2: Type: message/rfc822, Size: 4336 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 96 bytes --]

I'll try to reproduce it but I believe that's the bug we fixed.  I'll let you know after
I try.

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2645 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
Date: Thu, 6 Feb 2003 11:35:16 -0700 (MST)
Message-ID: <20030206113325.O535@fbsd.cpsc.ucalgary.ca>

this is the last message on this subject:

https://lists.cse.psu.edu/archives/9fans/2002-May/017658.html

(it doesn't appear on groups.google.com though, I don't know why -- maybe
the pics attached are to blame?)

indeed we were able to measure improvement in speed, but the behaviour was
still strange, yet even stranger when iostats was involved.

andrey

On Thu, 6 Feb 2003, David Presotto wrote:

> I was under the impression that Dong and I had fixed the TCP problems LANL was
> having.  Is this incorrect?  Could you tell me what's still slow?  I really
> do want our IP stack to stay competative.  Our next move is to take advantage
> of the hardware checksuming on the gigabit boards since, in our most recent
> testing, we seem to differ from BSD speeds most because of that.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Scott Schwartz]

| (it doesn't appear on groups.google.com though, I don't know why -- maybe
| the pics attached are to blame?)

Probably the https.  I put a copy of all that stuff (and the older set
of archives) in < http://bio.cse.psu.edu/~schwartz/9fans/ >.  I used to
have those files bzip2-ed, but that seems to have prevented google from
indexing them, so I recently uncompressed them.  Hopefully google will
reindex them soon.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Butler]

Forgive the length of this response, but I've been thinking about this for
some time.

> The real question for me is whether the speed difference is fundamental or
> not. I don't know enough to know.

My opinion is the problem is fundamental but fixable. The fundamental
problem is the synchronous nature of the API. This is where I think Plan 9
has not gone far enough breaking with tradition. Even though ANSI and
POSIX are given the finger, it is only slightly so.

The underlying system is very asynchronous (9P messages have tags to
correlate replies) and there is a lot of overlap allowed from multiple
processes, but any one application is slow. Take for example the command
sed -e script <input >output. It is not hard to imagine the flow of 9P
messages
that stream from the system to fulfill this command. Each message is
synchronous. This is why most of the time in execution of this command is in
"halt". But this is not an OS or protocol issue because if 100 of these
commands are executed in parallel, the real time for completion is
quite a bit less than 100 times the real time for one.

There is an optimization in the file server code to try to assist the single
thread case that has to be removed to get good performance from the
multi thread case. That optimization is the attempt of the file server to
fill the cache with some number of blocks ahead of a file being read.
This, like any cache policy, should not be in a file server but in the
application. LRU is not always the best way. This is why database
systems bypass the UNIX buffer cache and use raw disks. I have
changed my file server to use the cache only for its needs and let
applications create their own policy in their local address space.

Using the current API to get performance sed would need to be rewritten
with multiple threads which launch parallel reads and writes. Since it does
not reuse the data after it has modified it, it has no cache needs.

Because of these thoughts and efforts, my system runs a little slower than
the average Plan 9 system in casual use, but the applications I have written
for performance are very fast and can utilize every resource I can throw at
them.

So, I know the API needs to allow more I/O concurrency and cache policy
management. I do not know enough yet how that looks. I'm interested in any
ideas.

David

Re: [9fans] Webbrowser

[Russ Cox]

Having gcc doesn't mean we like it.  I have yet to
use gcc for anything -- even my recent Perl 5.8.0 port
still uses pcc, which is just a wrapper around 8c et al.

The main `benefit' of gcc seems to be that you could
compile C++ code, but you'd still be locked in the APE,
making it harder to integrate well with the rest of the system.

On a related note, I looked at links for a while today.
I did most of the work for a port, but there's a big
select loop at the heart of it that I just didn't want
to deal with cutting through.  I also didn't write the
frame buffer, mouse, and keyboard code, but those
look easy once you kill off select.

In my frustration, I tried i again.  No good.

Then I tried charon again.  It's come along quite
a bit since the last time I used it.  It seems like Charon
is still the best bet for now, though I do wish it were
easier to integrate with the rest of the Plan 9 environment.

There's just no good answer right now.

Russ

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

On Wed, 5 Feb 2003, Russ Cox wrote:

> Having gcc doesn't mean we like it.  I have yet to
> use gcc for anything -- even my recent Perl 5.8.0 port
> still uses pcc, which is just a wrapper around 8c et al.
>

just out of curiosity: what are my chances of using the GCC3.0 port to
compile, say GCC3.2 and switch it as the C++ plan9 compiler?

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

I've actually used gcc to compile something -- a simple cpu and memory
benchmark called 'ubench'.

I strongly desire such that the 'my OS is faster' flamewars continue on this
list, that's why i'm posting a URL to the ubench source and compilation
instructions for Plan9 (using the GCC3.0 port).

Unfortunately I couldn't be bothered rewriting the benchmark for the native
P9 compiler, so 'my compiler is faster' flame warriors will be left
dissatisfied.

The URL for ubench is:
	http://www.phystech.com/download/ubench.html

to compile under plan9:
	% gunzip < ubench-0.32.tar.gz | tar xv
	% cd ubench-0.32
	% # edit ubench.c and comment out syslog.h on line 25
	% gnu/gsh
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c
	(alternatively, to compile with optimizations, do:)
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2
	$ ^D
	% strip ubench
	% ubench

here are the highly scientific results I got:

Celeron 900mhz (average ~40,000 in FreeBSD 4.7 w/ gcc2.95), the machine is a
standalone 9pcdisk/kfs terminal:

no optimizations:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    23072
Ubench MEM:    14221
--------------------
Ubench AVG:    18646
%

with -O2:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    24992
Ubench MEM:    18097
--------------------
Ubench AVG:    21544
%




Pentium 4, 2Ghz (average ~60,000 on FreeBSD 4.7 w/ gcc2.95, now the machine
has FBSD 5.0 w/ gcc3.2 on it, but is booted in p9 so I couldn't test :), the
machine is running as an auth/cpu/kfs server:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    39110
Ubench MEM:    33350
--------------------
Ubench AVG:    36230
cpu%


with -O2:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43528
Ubench MEM:    44170
--------------------
Ubench AVG:    43849
cpu%

And something else: I just checked how ubench is compiled on freebsd (what
optimizations are used) and gave the same arguments to plan9's gcc. The
result is:


$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2 -Wall '-malign-loops=2' '-malign-jumps=2' '-malign-functions=2' -fomit-frame-pointer -s
cpu% strip ubench
cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43863
Ubench MEM:    44170
--------------------
Ubench AVG:    44016
cpu%


as with everything, those results should not be taken too seriously :)

andrey

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

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

I looked at at the benchmarks.  There are lots of times() calls in
inner loops that are very low cost in Unix but pretty expensive in
Plan 9.  Why not do a run under iostats and post the results.  It
might be enlightening.

[-- Attachment #2: Type: message/rfc822, Size: 5014 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
Date: Wed, 5 Feb 2003 21:16:59 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302052038050.7087-100000@csl>

I've actually used gcc to compile something -- a simple cpu and memory
benchmark called 'ubench'.

I strongly desire such that the 'my OS is faster' flamewars continue on this
list, that's why i'm posting a URL to the ubench source and compilation
instructions for Plan9 (using the GCC3.0 port).

Unfortunately I couldn't be bothered rewriting the benchmark for the native
P9 compiler, so 'my compiler is faster' flame warriors will be left
dissatisfied.

The URL for ubench is:
	http://www.phystech.com/download/ubench.html

to compile under plan9:
	% gunzip < ubench-0.32.tar.gz | tar xv
	% cd ubench-0.32
	% # edit ubench.c and comment out syslog.h on line 25
	% gnu/gsh
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c
	(alternatively, to compile with optimizations, do:)
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2
	$ ^D
	% strip ubench
	% ubench

here are the highly scientific results I got:

Celeron 900mhz (average ~40,000 in FreeBSD 4.7 w/ gcc2.95), the machine is a
standalone 9pcdisk/kfs terminal:

no optimizations:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    23072
Ubench MEM:    14221
--------------------
Ubench AVG:    18646
%

with -O2:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    24992
Ubench MEM:    18097
--------------------
Ubench AVG:    21544
%




Pentium 4, 2Ghz (average ~60,000 on FreeBSD 4.7 w/ gcc2.95, now the machine
has FBSD 5.0 w/ gcc3.2 on it, but is booted in p9 so I couldn't test :), the
machine is running as an auth/cpu/kfs server:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    39110
Ubench MEM:    33350
--------------------
Ubench AVG:    36230
cpu%


with -O2:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43528
Ubench MEM:    44170
--------------------
Ubench AVG:    43849
cpu%

And something else: I just checked how ubench is compiled on freebsd (what
optimizations are used) and gave the same arguments to plan9's gcc. The
result is:


$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2 -Wall '-malign-loops=2' '-malign-jumps=2' '-malign-functions=2' -fomit-frame-pointer -s
cpu% strip ubench
cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43863
Ubench MEM:    44170
--------------------
Ubench AVG:    44016
cpu%


as with everything, those results should not be taken too seriously :)

andrey

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

this is iostats:

read      238369 bytes, 13.02132 Kb/sec
write     1266 bytes, .4715208 Kb/sec
protocol  659280 bytes, 28.10126 Kb/sec
rpc       8876 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     0     0     0     0 ms       25       20 bytes
flush          1 10000000     0     0     0 ms        9        7 bytes
walk        2544     0   153   551     0 ms    78729    88992 bytes
open        1248     0   117   785     0 ms    14976    29928 bytes
read        1277     0 11179 17877    13 ms    29371   252416 bytes
write         15     0   686  2622   174 ms     1611      165 bytes
clunk       2542     0    44   379     0 ms    27962    17794 bytes
stat        1247     0    50   697     0 ms    13717   103426 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
 1233     1233    88776        0        0 /dev/cputime
    1        0        0        1        5 /proc/10281/note
    1        0        0        1        5 /proc/10282/note
    1        0        0        1        5 /proc/10287/note
    2        0        0        2        9 /proc/10289/note
    1        0        0        1        5 /proc/10295/note
    1        1      172        0        0 /adm/users
    1        2        7        0        0 (stdin)
    1        0        0        7     1227 (stdout)
    1        0        0        2       10 (stderr)
    1        2      579        0        0 /rc/lib/rcmain
    1       24    91459        0        0 /bin/rc
    1       15    57376        0        0 /usr/bootes/ubench-0.32/ubench

and this is what kprof has to say:

total: 492060	in kernel text: 56450	outside kernel text: 435610
KTZERO 80100000
ms	  %	sym
50180	 88.8	halt
3210	  5.6	memmove
420	  0.7	savagewaitidle
410	  0.7	i8259isr
350	  0.6	inb
250	  0.4	drawclip
150	  0.2	runproc
130	  0.2	wbflush
120	  0.2	memset
110	  0.1	chardraw
70	  0.1	rectclip
60	  0.1	memdraw
50	  0.0	drawmesg
50	  0.0	convD2M
50	  0.0	strlen
40	  0.0	syscall
30	  0.0	drawgoodname
30	  0.0	_syscallintr
30	  0.0	dstflush
30	  0.0	memimagedraw
30	  0.0	drawreplxy


interesting tidbit -- iostats filled up the memory on both machines I tried
it on (128 and 512 MB), it's fun to look at in 'stats'

adnrey

On Thu, 6 Feb 2003, David Presotto wrote:

> I looked at at the benchmarks.  There are lots of times() calls in
> inner loops that are very low cost in Unix but pretty expensive in
> Plan 9.  Why not do a run under iostats and post the results.  It
> might be enlightening.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

Just for a wild guess, I bet the 1200+ open/read/close/strtoui's of
/dev/cputimes skewed the results which would mean that side effects
that wouldn't exist in programs (dominated the results).  The tests
themselves were not at all OS tests, they pretty much test the compiler
and malloc and nothing else.  There's a little pipe stuff in there to implement
locks but they looked like pretty high level locks.

I'm not saying that we're anywhere near as fast as the other OS's,
only that the tests were pretty misdirected.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[William K. Josephson]

On Thu, Feb 06, 2003 at 12:32:52PM -0500, David Presotto wrote:
>themselves were not at all OS tests, they pretty much test the compiler
>and malloc and nothing else. There's a little pipe stuff in there to implement
>locks but they looked like pretty high level locks.

Not to mention that the repeated comparisons with gcc
get tiresome: gcc is really not as great as many proponents
make it out to be, even on the ia32.  I'm very glad to have
it and use it regularly, but it is much slower than either
8c or the vendor compiler and generates substantially slower
code than the vendor compiler, at least in my experience.
It isn't uncommon to see Intel's compiler beat gcc by 30-40%
and I haven't found any non-trivial examples where gcc beats
the Microsoft or Intel compilers, although they may well
exist.  If someone has the time, money, and warm bodies to
invest, great, otherwise I'll port a few assembly routines
when it really matters and get on with my life.  Premature
obfusc^H^H^H^H^Hoptimization is the root of all evil.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, William K. Josephson wrote:

> It isn't uncommon to see Intel's compiler beat gcc by 30-40%
> and I haven't found any non-trivial examples where gcc beats
> the Microsoft or Intel compilers, although they may well
> exist.

Agree with most of your comments re gcc, but the fact is that
counterexamples do in fact exist. In fact I believe that LLNLs latest
LINPACK runs were better with gcc than the intel v7.0 compiler, which I
think surprised *everybody*.

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[William K. Josephson]

On Thu, Feb 06, 2003 at 11:16:22AM -0700, Ronald G. Minnich wrote:

> Agree with most of your comments re gcc, but the fact is that
> counterexamples do in fact exist. In fact I believe that LLNLs latest
> LINPACK runs were better with gcc than the intel v7.0 compiler, which I
> think surprised *everybody*.

That does surprise me.  What is the target hardware?
I've found gcc 3.2's support for the Pentium 4 to be
rather atrocious.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, William K. Josephson wrote:

> On Thu, Feb 06, 2003 at 11:16:22AM -0700, Ronald G. Minnich wrote:
>
> > Agree with most of your comments re gcc, but the fact is that
> > counterexamples do in fact exist. In fact I believe that LLNLs latest
> > LINPACK runs were better with gcc than the intel v7.0 compiler, which I
> > think surprised *everybody*.
>
> That does surprise me.  What is the target hardware?
> I've found gcc 3.2's support for the Pentium 4 to be
> rather atrocious.
>

that's the best part. Is a p4@2.4 ghz.

ron