Subject: [linux-audio-dev] Performance and Elegance? (Was: High Cost of IPC)
From: Jay Ts (jay_AT_toltec.metran.cx)
Date: Wed May 16 2001 - 02:23:09 EEST
Hiya,
Regarding the falloff in Linux's ability to supply support with
increasing active processes, I wonder if maybe we're worrying a
bit too much about that?
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. I may be wrong,
but I believe this is a factor that the kernel developers know they
need to look into.
The thing is, if we pick a software architecture that trades simplicity,
beauty, flexibility, etc., for performance, then what happens if
the kernel changes such that our original analysis no longer applies?
It will make us all look really stupid in retrospect if we later find
we've done that.
It seems to me that one of our big issues right now is that we are looking
at these two (at the moment) opposing design goals:
a) Absolute need for ultra-low latency and high data throughput on large data.
b) Open-ended design that will allow for what everyone wants to do.
(And hopefully, a design based on the "simple is beautiful" Unix
philosophy.)
I keep thinking about how what we're up to here is very similar to the
development of a GUI (X Window System) for Unix in the 1980's. At first,
the general thinking was, "Who needs a WIMP? We're Unix users!". And
that kind of thinking is now being echoed (not unlike a 10-15 year digital
delay! :-) by the non-musician, non-audio Unix/Linux users I've been
talking to. (And sometimes maybe even the kernel developers - ouch!)
I've been surprised at how many people I've talked to about Linux
audio, and they respond, essentially, "Why would you even want to do
that? Linux is a *server* OS!" And I have even called an "evangelist".
Ewwww! :(
What happened with the GUI thing is that after some proprietary "solutions"
(that weren't, becasue they were proprietary!) is that MIT developed X,
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.
We obviously cannot take that approach, because:
a) We don't have the luxury of allowing ourselves to ignore performance
issues - we are in a realtime programming situation.
b) We want things to work now, or reasonably soon. I hope I'm speaking
for everyone when I say that 10 years is a bit too long to wait to
be able to use audio/music software on our home/personal computers.
But ... I hope we do not end up programming ourselves into a corner by
focusing too much on performance issues. Now before I sound to critical
to anyone:
I appreciate very much the analysis and discussion that's
been happening recently, and I have been feeling very good
that things are on the right track. In fact, for the first
time I've been feeling good about how things are going in
the LAD discussion. I don't mean to stop talking about
performance; it is very important. This is just a reminder
that anything taken in the extreme can lead to difficulties
later.
So please take this very lightly; I simply wanted to bring up the
subject as a reminder. I'm just saying, once in a while it pays
to take a "future retrospective" view of the present. Are we going
to be happy with this design 10 or 20 years from now? Because if
we're not, we (or someone) is going to have to scrap our (by that time)
standardized and popularized design and do the whole thing over, which
will be very difficult and disruptive.
This is all coming from my readings of Paul's and Abramo's messages
(or should I say arguments? :-) and thinking that the best solution
has got to be balanced in between, and meet with approval from both
perspectives. In other words, a more holistic approach.
(Thanks for paying attention this far.. )
Cheers,
Jay Ts
jayts_AT_bigfoot.com
This archive was generated by hypermail 2b28 : Wed May 16 2001 - 02:41:08 EEST