Re: [9fans] Webbrowser

Re: [9fans] Webbrowser

[Keith Nash]

> " 'Even though some of us used to work on Mozilla, we have to admit that
> the Mozilla code is a gigantic, bloated mess, not to mention slow, and with
> an internal API so flamboyantly baroque that frankly we can't even
> comprehend where to begin. Also did we mention big and slow and
> incomprehensible?'".
>
> sounds nice, doesn't it? :) article here:
>
> http://www.theregister.co.uk/content/39/29183.html

This remarkably frank statement describes the reasons for Apple's choice of khtml over Mozilla as the rendering engine for OSX's new web browser, Safari.

Apple has open-sourced its WebCore library, which includes their modified form of khtml, and a library that replaces khtml's calls to KDE and Qt libraries (presumably with Aqua calls).

http://developer.apple.com/darwin/projects/webcore/index.html

http://www.apple.com/safari/

If anyone is serious about porting a graphical browser to Plan 9, this might be worth a look.

Re: [9fans] Webbrowser

[John Packer]

> Apple has open-sourced its WebCore library, which includes their
> modified form of khtml, and a library that replaces khtml's calls to
> KDE and Qt libraries (presumably with Aqua calls).
>
> http://developer.apple.com/darwin/projects/webcore/index.html
>
> http://www.apple.com/safari/
>
> If anyone is serious about porting a graphical browser to Plan 9, this
> might be worth a look.


Unfortunately ktml is written in C++.

Re: [9fans] Webbrowser

[Skip Tavakkolian]

> Unfortunately ktml is written in C++.

You know that GCC has been ported and is available? Or am I missing
something?

Re: [9fans] Webbrowser

[John Packer]

> You know that GCC has been ported and is available? Or am I missing
> something?

I know. I have actually thought about attempting to port the
khtml library to Plan 9, but I guess I'm prejudiced against
C++, (and gcc). I don't mean to offend anyone.

I agree that khtml is far preferable to Mozilla. It just
seemed a step toward Mozilla/X11 chaos and bloatedness, and
away from the grace of Plan 9.

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] Webbrowser

[Peter Bosch]

> I know. I have actually thought about attempting to port the
> khtml library to Plan 9, but I guess I'm prejudiced against
> C++, (and gcc). I don't mean to offend anyone.
>
> I agree that khtml is far preferable to Mozilla. It just
> seemed a step toward Mozilla/X11 chaos and bloatedness, and
> away from the grace of Plan 9.

g++ can be used on Plan 9.

pb.

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] Webbrowser - porting mozilla

[matt]

Mozilla is the name for the renderer and the User interface

The renderer itself is called NGLayout   http://www.mozilla.org/newlayout/

Porting instructions are here : http://www.mozilla.org/newlayout/ngport.html

Reading through them suggests it wouldn't be too hard - ymmv [a lot
probably]

Mind you the bottom of that pages says :  Last modified January 14, 1999.

m

Re: [9fans] Webbrowser - porting mozilla

[Ian Broster]

> Porting instructions are here :
> http://www.mozilla.org/newlayout/ngport.html
> Mind you the bottom of that pages says :  Last modified January 14,
> 1999.

And at the top:

Last updated 8-July-98

...
ian

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