Subject: Re[2]: [linux-audio-dev] Performance and Elegance? (Was: High Cost of IPC)
From: Rick Burnett (destinytech_AT_spacey.net)
Date: Thu May 17 2001 - 03:19:35 EEST
I think that you have to consider what-ifs but known when to draw the
line. First, you have to look at the scope, what is our target
audience, what do we all have that we are going to use with the
engine? I doubt that everyone is going to run out and get a 7
processor system just for this :) (Though it would be nice to play
with). The fact is that, unfortunately, windows does tend to dictate
hardware advancement, and when the operating system becomes mature
enough for the general users ( and not NT users ) to use more than one
processor, I think you will see it happen. I don't see it any time
soon. Right now Intel is probably trying to figure out how their next
chip can actually compete with the Athlon in both performance and
price. I think the next biggest breakthroughs that you are going to
see are in memory. I am a chip designer and I resently talked with
one of the designers of the 286 who is working on producing ferrite
memory. This memory works great, low power, cheap to manufacture, and
about 20+ companies have signed on to fab it.
But, the foundation of the PC architecture has always been
compatibility. The performance of the machine suffers from backwards
compatibility issues. Other machines like macintosh (from what I am
told) run much faster but don't stay compatible with older technology.
I think the chances of the PC staying relatively the same are pretty
good!
This also doesn't include the fact that we are not even really
considering the audio hardware at this time!
Well thats my 2 cents :)
Rick
Tuesday, May 15, 2001, you wrote:
>>
>> >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.
JT> Yes, I understand. I didn't mean my comments to apply exclusively
JT> to the IPC and context switching issue, but in a broader sense to
JT> the development of the technology as a whole. It's hard for me to
JT> explain (so maybe I should shut up... ;-) but I feel that we're focusing
JT> a little too much at the performance end of the design.
JT> I don't agree totally with Abramo, and yet I feel intuitively that there's
JT> a certain beauty to a multithreaded or multiprocess approach. I'm sure
JT> it won't work for all applications, and that means we need to have a
JT> high-performance solution available for sure. But is there perhaps
JT> some way to add on support for a multithreaded/multiprocess way of
JT> doing things too?
JT> As a rough analogy, there are the Unix open/read/write/close
JT> system calls, and also the fopen/fread/fwrite/fclose "stream I/O" calls
JT> in the standard C library. In situations where performance is not a
JT> pressing issue, the stream I/O functions can make programming a lot
JT> easier.
JT> We have had a discussion regarding monolithic vs. "modular" (multiprocess)
JT> implementations. About a year ago, I was thinking that the modular
JT> approach was the way to go. But then I realized that it wasn't even
JT> nearly practical with current hardware and OS technology, and then I
JT> rebounded by thinking that the Steinberg-like monolithic approach was
JT> the way. But now I'm wondering that if not right now, then maybe sometime
JT> in the future, an in-between (hybrid or mix) method might provide the
JT> 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?
JT> Maybe because OSs are much more complex (and needing to do more) than
JT> they used to?
JT> Yes, that's a very valid counterpoint, and I understand. The thing is
JT> of course, although we can have historical retrospective, we don't know
JT> what's going to happen in the next 5, 10, 20 years. Sometimes, it's just
JT> when things seem like they are going to go on forever in the same direction
JT> they always have, it is when the big revolution happens. That's why I'm
JT> suggesting keeping things open-ended as much as possible, while meeting
JT> our immediate needs for performance.
JT> Where I'm coming from on this is that I am considering the possibility
JT> that demand for "realtime" support may increase, and OS designs will
JT> change in accordance with that. (If I were a robot, I would want to
JT> be running Linux, wouldn't you? With good realtime support, of course!)
JT> 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.
JT> (Sigh.) Yes, for the moment you would seem to be very right about that.
JT> I wasn't trying to argue that point, and I was just concerned with our
JT> general attitude regarding performance. If we focus too much in that area,
JT> we might miss some opportunities.
JT> 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.
JT> That sounds very reasonable.
JT> ------------------------------------------
JT> Warning: The following is way off topic...
JT> ------------------------------------------
>> [ 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".
JT> That's what I was saying... But 1988, actually...
>> Almost nobody using Unix cared about x86,
JT> There were many people running Unix on the x86 in 1986. (The first
JT> release of Xenix ran on the IBM XT!)
JT> And just 2-3 years later, the x86 architecture was the
JT> most popular for running Unix, in the form of Xenix 286/386, Interactive
JT> Unix, and later, FreeBSD and (later still) Linux. I think that most Unix
JT> people still don't understand how popular Xenix was in its time. I would
JT> 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.
JT> I think the real reason wasn't numbers, but that most Xenix systems were
JT> being used in business settings, with multiple users logging in from
JT> text terminals. And those systems would have had a hard time running
JT> just one X server for one user. Oh, and the consoles were often not
JT> capable of color bitmapped graphics...
JT> In my opinion, X wasn't really practical until about the Pentiums
JT> 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.
JT> The quality of the driver didn't matter much if you had a 20 MHz 386 with
JT> a Paradise video card. Which is what I had... I installed X and promptly
JT> gave up on it! It was a disaster. (By coincidence, I was also running
JT> Interactive Unix.) If it worked for you, you must have had a system loaded
JT> with memory, disk space, and a very expensive graphics card.
JT> And while you may have enjoyed your experience running X10 on Sun hardware,
JT> very many of Sun's customers were really pissed when Sun replaced SunView
JT> with (much slower) X Window.
JT> - Jay Ts
JT> jayts_AT_bigfoot.com
This archive was generated by hypermail 2b28 : Thu May 17 2001 - 03:33:14 EEST