Re: Thread-private mappings and graphics (was Re: Per-Processor Data

Linus Torvalds (torvalds@transmeta.com)
14 Dec 1999 00:14:26 -0800


In article <19991213235415.A80502@oddhack.engr.sgi.com>,
Jon Leech <ljp@oddhack.engr.sgi.com> wrote:
>
> I assumed these points were both clear from my initial post, and not
>really occasion for a rant about how "unstable and unmaintainable" IRIX
>is, but whatever - so long as in the end Linux allows apps to issue
>vertices at least as fast as other OSes on the same hardware.

You know what? I don't much care.

You can show me an OS that does it five percent faster and claim it is
because of Linux not supporting partial private mappings. And I'll just
tell you to go play with NT or IRIX instead, because Linux WILL NOT DO
IT.

It's not about performanceon any specific benchmark. It's about
_general_ performance of the system, and maintainability of the concepts
in the kernel.

It's about being able to support 7 different CPU's with the same source
base. Without having to worry about some design mistake that is going
to make it be a painful experience.

I'll take portability, sanity and clean design before some "my dick is
bigger than your dick" direct rendering argument any day.

By being clean and maintainable, Linux will get a 60% performance
improvement every year from processor technology alone. In 3D graphics,
that 60% seems to be closer to 300% right now.

Trust me: a "private area" kind of thing may show localized advantages,
but in three to five years you'll end having to come up with the "New
Technology" kind of thing in order to get you out of the corner you
painted yourself into.

It's the old C vs assembly war all over again: sure, you can always win
the performance war by writing perfect assembly code. But you won't be
able to keep up with the hardware or the needs of the users, because you
will waste a lot of time just trying to get it to work and then
maintaining it in the face of changes - possibly rewriting it completely
when you notice that the original design was weak.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/