Re: [linux-audio-dev] Performance and Elegance? (Was: High Cost of IPC)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Performance and Elegance? (Was: High Cost of IPC)
From: Jay Ts (jay_AT_toltec.metran.cx)
Date: Wed May 16 2001 - 06:46:54 EEST


>
> >My concern is that Linux is an OS under continuing development,
> >and I recall that other (non audio development) folks are concerned that
> >Linux's performance drops off under heavy load, too.
>
> Jay, please understand that the central concern here is not "load",
> but unavoidable costs of context switching.

Yes, I understand. I didn't mean my comments to apply exclusively
to the IPC and context switching issue, but in a broader sense to
the development of the technology as a whole. It's hard for me to
explain (so maybe I should shut up... ;-) but I feel that we're focusing
a little too much at the performance end of the design.

I don't agree totally with Abramo, and yet I feel intuitively that there's
a certain beauty to a multithreaded or multiprocess approach. I'm sure
it won't work for all applications, and that means we need to have a
high-performance solution available for sure. But is there perhaps
some way to add on support for a multithreaded/multiprocess way of
doing things too?

As a rough analogy, there are the Unix open/read/write/close
system calls, and also the fopen/fread/fwrite/fclose "stream I/O" calls
in the standard C library. In situations where performance is not a
pressing issue, the stream I/O functions can make programming a lot
easier.

We have had a discussion regarding monolithic vs. "modular" (multiprocess)
implementations. About a year ago, I was thinking that the modular
approach was the way to go. But then I realized that it wasn't even
nearly practical with current hardware and OS technology, and then I
rebounded by thinking that the Steinberg-like monolithic approach was
the way. But now I'm wondering that if not right now, then maybe sometime
in the future, an in-between (hybrid or mix) method might provide the
most benefit.

> there is a very interesting paper at UW CS&E that,
> despite being, oh, 10 years old(?) now, is still totally relevant. I
> don't recall the exact title, but to paraphrase the general message:
> processors have gotten faster, but applications are spending more real
> clock time than ever dealing with the kernel in one way or another, so
> why is this?

Maybe because OSs are much more complex (and needing to do more) than
they used to?

Yes, that's a very valid counterpoint, and I understand. The thing is
of course, although we can have historical retrospective, we don't know
what's going to happen in the next 5, 10, 20 years. Sometimes, it's just
when things seem like they are going to go on forever in the same direction
they always have, it is when the big revolution happens. That's why I'm
suggesting keeping things open-ended as much as possible, while meeting
our immediate needs for performance.

Where I'm coming from on this is that I am considering the possibility
that demand for "realtime" support may increase, and OS designs will
change in accordance with that. (If I were a robot, I would want to
be running Linux, wouldn't you? With good realtime support, of course!)

And 64 bit computers with huge memory may become *very* common..

> the solutions to the kinds of problems that we're discussing are not
> just matters of tuning parts of the kernel. they require a radically
> different kind of OS design, something that Linux is not likely to
> have at any time in the near to mid-term future.

(Sigh.) Yes, for the moment you would seem to be very right about that.
I wasn't trying to argue that point, and I was just concerned with our
general attitude regarding performance. If we focus too much in that area,
we might miss some opportunities.

But then, maybe I am worrying too much...

> Given how little has fundamentally changed in OS design over the last
> 10 years, I am quite content to base a design for what we're talking
> about on the ways that more or less every OS you could run right now
> operates.

That sounds very reasonable.

------------------------------------------
Warning: The following is way off topic...
------------------------------------------
> [ X Windows ]
>
> >focusing on having a huge feature set rather than performance, and it took
> >about 10 years before it would run on common computers with good performance.
>
> I don't feel that's true.
> Unless you're trying to say "it wouldn't run
> on whatever x86 existed in 1986".

That's what I was saying... But 1988, actually...

> Almost nobody using Unix cared about x86,

There were many people running Unix on the x86 in 1986. (The first
release of Xenix ran on the IBM XT!)

And just 2-3 years later, the x86 architecture was the
most popular for running Unix, in the form of Xenix 286/386, Interactive
Unix, and later, FreeBSD and (later still) Linux. I think that most Unix
people still don't understand how popular Xenix was in its time. I would
venture that _maybe_ most Unix systems in 1986 were PCs running Xenix 286.

> and so almost no work was put into efficient x86 (i.e. VGA, SVGA)
> drivers for X.

I think the real reason wasn't numbers, but that most Xenix systems were
being used in business settings, with multiple users logging in from
text terminals. And those systems would have had a hard time running
just one X server for one user. Oh, and the consoles were often not
capable of color bitmapped graphics...

In my opinion, X wasn't really practical until about the Pentiums
came out or maybe even a bit later.

> I was using X10 on
> Sun's in '86-87, and within a year or so of X11 appearing, I was using
> a pretty good (not great, but not bad) X11 implementation for
> Interactive Unix on the x86.

The quality of the driver didn't matter much if you had a 20 MHz 386 with
a Paradise video card. Which is what I had... I installed X and promptly
gave up on it! It was a disaster. (By coincidence, I was also running
Interactive Unix.) If it worked for you, you must have had a system loaded
with memory, disk space, and a very expensive graphics card.

And while you may have enjoyed your experience running X10 on Sun hardware,
very many of Sun's customers were really pissed when Sun replaced SunView
with (much slower) X Window.

- Jay Ts
jayts_AT_bigfoot.com


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 16 2001 - 07:42:31 EEST