[9fans] It's not like lightning is it ...

[9fans] It's not like lightning is it ...

[Matt Pidd-Cheshire]

cej@gli.cas.cz wrote:

> (the box computes some task for 5 weeks now, so I don't
> want to restart it)

I had that problem too. Dictionary AVL tree builder, running
on 2Gb of ascii text for 9 days, no sign of finishing.

Copied src (unchanged save for includes) to FreeBSD
running on the same box, compiled it and kicked it off.

Twelve minutes later I had my result. Double checked it with
a smaller dataset. No echo 'pri xx' > /proc/yy/ctl or anything
of that kind.

Without wishing to be offensive, does anyone know why
Plan 9 appears to be so slow?

I love the OS, but it doesn't do my work on time.  =)

Re: [9fans] It's not like lightning is it ...

[Charles Forsyth]

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

try using prof or tprof to see where it is spending its time.
you don't need to wait 9 days for usable results.

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

From: Matt Pidd-Cheshire <axwrt001@yahoo.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: [9fans] It's not like lightning is it ...
Date: Tue, 08 Jun 2004 14:37:04 -0700
Message-ID: <40C63180.9070207@yahoo.com>

cej@gli.cas.cz wrote:

> (the box computes some task for 5 weeks now, so I don't
> want to restart it)

I had that problem too. Dictionary AVL tree builder, running
on 2Gb of ascii text for 9 days, no sign of finishing.

Copied src (unchanged save for includes) to FreeBSD
running on the same box, compiled it and kicked it off.

Twelve minutes later I had my result. Double checked it with
a smaller dataset. No echo 'pri xx' > /proc/yy/ctl or anything
of that kind.

Without wishing to be offensive, does anyone know why
Plan 9 appears to be so slow?

I love the OS, but it doesn't do my work on time.  =)

Re: [9fans] It's not like lightning is it ...

[Matt Pidd-Cheshire]

Charles Forsyth wrote:

> try using prof or tprof to see where it is spending its time.
> you don't need to wait 9 days for usable results.

Thanks Charles, I will try this when I next get the chance.

Perhaps I mucked something up during the install;

I noticed that when reaming kfs with blocks smaller than 8k the
performance of the filesystem was markedly degraded and the
error "dnodebuf: trip indirect" would pop up occasionally.

Even so, I'm almost certain that it was operating on an fs
reamed with the default block size. kfs doesn't seem to be
particularly quick especially when another process is wandering
around the file tree. I just went with the defaults so I may
be missing some important tuning tricks.


Regards

Re: [9fans] It's not like lightning is it ...

[Geoff Collyer]

kfs is not the preferred file server.  If you must use it, you ought
to give it a few 100MB of buffers with -B.  For fastest results, you
probably want to use Ken's standalone file server (in /sys/src/fs).
venti+fossil is reported to be a little slower, but should be faster
than kfs.

Re: [9fans] It's not like lightning is it ...

[boyd, rounin]

> Without wishing to be offensive, does anyone know why
> Plan 9 appears to be so slow?

slower than what?  define your parameters.

Re: [9fans] It's not like lightning is it ...

[Matt Pidd-Cheshire]

boyd wrote:

 > slower than what?  define your parameters.

as I say; same dataset, same source code, same physical
machine different OS.

Single CPU (1.3GHz P3) 512Mb RAM

differences; gcc versus 8c - tho I don't see how that
can make much difference...

:-\

or am I missing something out?

Re: [9fans] It's not like lightning is it ...

[boyd, rounin]

> or am I missing something out?

you are.

how long does it take to boot to lunix?

how long does it take to compile the lunix kernel?

tried:

    size 8c gcc

?

Re: [9fans] It's not like lightning is it ...

[Matt Pidd-Cheshire]

boyd, rounin wrote:

> how long does it take to boot to lunix?
sure, FreeBSD takes longer than 9

> how long does it take to compile the lunix kernel?
never timed them

> tried:
> 
>     size 8c gcc

meaning optimisation?

sure gcc is a whopper, 8c diminutive.

default gcc switches were used to compile, but not explicitly with 
-funroll-loops -fexpensive-optimizations -m686 -O3 ... et cetera.

gcc produces fat binaries and uses many tricks
but an AVL tree ain't a complex peice of code, aside from branch
optimisations and registerising pointer dereferences I see little
for the compiler to chew on.

is kfs the bottleneck? I don't know for sure, maybe there are
things I can do to tune kfs up. Perhaps naively I'm assuming
that once booted, most other things are equal. kfs doesn't seem
to use all of the unassigned RAM as a disc cache, but in this case
it wouldn't matter anyway. I realise 9 is distributed but this is
my living room setup not a lab.

if all this sounds incredibly naive, feel free to enlighten me.

<sorry, my posts are taking time to get out; so I get replies
out of sequence.>

Re: [9fans] It's not like lightning is it ...

[Brantley Coile]

Does the program in question buffer its output?
Plan 9 doesn't like lots of small writes.

  Brantley

Re: [9fans] It's not like lightning is it ...

[Matt Pidd-Cheshire]

Brantley Cole wrote:

> Does the program in question buffer its output?
> Plan 9 doesn't like lots of small writes.

The tree is built during the input read phase and
written when the input is exhausted through a stdio
interface. 9 days and counting for the read phase, it
didn't even get round to writing.

The bottleneck seems to be kfs' reading the fresh data.
Fat kfs buffers don't solve the initial read problem,
the system generally is a bit slicker once the data is
cached.

Re: [9fans] It's not like lightning is it ...

[Rob Pike]

i wonder if you have DMA turned off on your disk.
also, i've known CPUs to disable their caches
sometimes. is the machine healthy when running
other programs?

-rob