Re: Reboot: Strategic goals for GNOME

[Alan Cox <alan lxorguk ukuu org uk>]

> sillies :-) Lets not forget some of the low-level sillies found in the
> kernel and base-syste, recently: software resume processes that
> synchronously read huge chunks of the swap partition to checksum the
> disk, single big kernel locks held for all module insertions,

Modules is not showing up on profiles..

> de-compressing the initrd twice, hal parsing huge files multiple times
> etc. etc. ;-) IMHO no-one has the monopoly on writing bad, high-latency,
> poorly serialised code.

Oh indeed.

> compared to the ~70% I/O latency caused primarily by shoddy, obsolete
> pointer-chasing-with-10ms-latency-each-time filing systems :-)

Some of it comes from user space reading a zillion tiny files some from
file system design. Media latency is a huge issue. You see how huge when
you realise that a high end NFS server witha huge battery backed cache can
often beat a local SATA disk on latency.

> [ hopefully with some success ]. Indeed, most of the really startling
> boot-time / performance wins come from trying, often at great expense,
> to defeat the kernel's lame approach to I/O and get data from the disk
> faster. That is where most of the ~50% magnitude speedups I've seen come
> from.

I'd be interested to know more about this (off list ?) and how it looks
from the OO.o end of things.

> perhaps that helps them today wrt. reducing IPC latency: but I'm unsure
> how much of a win it is on a local machine; is it not the case that
> context switches are amazingly cheap these days ? is it not the case

Thread switches are. Process switches and IPC can be more costly than you
might think because of data moving between cores. The kernel isn't
entirely without blame on that one. In the ideal case the server and the
client are running on two cores in the same package. At that point
latency will matter simply because the X server takes time to respond to
a request and reply - and the server amplifies this with its own
execution model and assumptions. If you have parallelism then the server
and client thread (or threads increasingly I suspect) will execute in
parallel.

> outside that. Of course last I looked Google seem to suggest writing in
> Java and compiling to Javascript (which might work better).

The logical step beyond that then becomes "the javascript vm doesn't
suck, so why are we not providing an interface to provide javascript vm
apps".

> 	The HTML5 canvas is inadequate for doing most of the precision font
> rendering that is necessary for big (eg. WYSIWYG) office apps. I would
> love to read the writer layout and spreadsheet re-calculation algorithms
> re-written in Javascript. 

That in essence is part of the challenge. It's usually easier to take a
low featured app and move it to a higher featured environment than the
reverse. Locally executing web apps is a different ball game to web
enabling existing local apps, as several people have found out to their
cost.