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

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.

[9fans] Re: Clean Code & Performance

[Jack Johnson]

rob pike, esq. wrote:
> 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.

There's this interesting harmonic convergence in the stuff I've been
reading lately, and I just thought I'd share.

There's some interesting stuff going on with the Squeak VM in regards to
performance, and in general people are happy with the performance
improvements, but there has been a lot of discussion about what it takes
to eke out another 10%, and how much of it can hurt keeping the system
clean and straightforward.

Because some of the Squeakers see strong similarities in
Squeak/Smalltalk and Forth, there has been some discussion about
rewriting the VM in Forth to get closer to the machine.

Chuck Moore, Forth's creator, talks a *lot* about how he feels good
Forth is nearly non-portable, because if you're really that close to the
metal you're taking advantage of that particular platform's
optimizations and using them to your advantage.  His feeling seems to be
that (in his environment) if you're knowledgeable about the problem then
the coding is, relatively speaking, the easy part, that the solution is
the portable part and not necessarily the code.

I just find it interesting that in this third yet-unrelated thread we
have this discussion of cleanliness/portability vs. performance, and how
often they're at odds with each other.  But, as Rob points out, there
are different ways to measure performance, and something invaluable I
always take away from the discussions here is how a simple solution can
often be much more effective than a hard-number performance improvement.

But, I'm rambling again.  Nothing worse than newbies rambling.

Hopefully you've taken the time to just filter me out.

-Jack

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