[lkml]   [1996]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: real kernel bloat
>  >The place stuff like OSF/1 should still win is going to 12
> > processor .5Gb Alpha's. The really big stuff, and thats primarily because we
> > don't have any of those handy for a Linux port and to do all the tuning.
> That's precisely what they are after. It appears to me, that neither
> Sun nor Dec are after mass market. They are keeping to themselves
> the workstation users by spewing out a better hardware every once
> in a while, and trying to expand in their "really big" stuff.

No argument at all. Things like a half gigabyte memory aren't quite the same
as a PC. I'm not even sure a giant clustered database engine is a place
Linux in its current incarnation (or anything close to that) fits. The rules
for the OS start to change dramatically that high end. Nor would I suggest
running a giant corporate fault tolerant database on Linux ;)

> > Given the performance, the hideous TCP problems with Solaris, the fact Linux
> > is faster, has source, has more useful tools I think most of us here know.
> > My SMP box is happily doing bbthreaded stuff, PvmPovray etc. (PVMPovray is
> > funky btw..)
> I think both of us show some bias. BTW, about useful tools. Can you
> recommend a nice C++ compiler for Linux ? Don't tell me that g++ is
> nice - it will be, when it supports ANSI C++ working papers. How
> about P6 specific optimizations? When are they coming? Wouldn't
> they do more for the kernel performance, than all the optimizing in
> the next 10 years?

How about the Microway compilers. Their Fortran is out for Linux and I
believe all their C compiler kits are as well. There is a pile of funding for
gcc work to handle things like the Alpha and P5/P6 cleanly now as well that
will soon produce results. Using a P5/P6 optimising compiler wont make any
odds to kernel performance looking at the effects of the pentium compiler
groups gcc extensions. All the hot spots are hand optimised and tuned
already. There are a few other gags like the FPU memcpy to go in and push it
further. Come to think of it does the sun stuff run under iBCS2 ;)

> to writing it as a means of self expression. And this suggests the way
> how to really improve Linux' chances on BIG success - make it EASY
> for the commercial entities to write for Linux. It means supporting
> Spec 1170, instead of POSIX. The reason for that is, that people,

Caldera are indicating they intend to put money into going all the way past
Spec 1170 to Unix 95. Good luck to them on that, its one place where
commercialising Linux brings rewards back to all. OSF+ Apple are investing in real
linux work, SGI are getting Dave Miller to do an OSF port, Digital kicked
off the Alpha (and one assumes will soon the StrongARM) ports of Linux.

There are some quite big people getting involved.

> I read your answer to Alexey regarding STREAMS. I am sure, you
> are right that it's slower than sockets, but it does not matter.
> If someone recompiles or starts developing an application for
> Linux because of this feature, it will benefit Linux much more
> than a better benchmarks with no applications to use.

Its important to implement stuff right. Like streams in a way that doesnt
slow the socket performance down (and Linux has a lot of users purely for
performance reasons on small hardware, as does FreeBSD). There is a
difference between "not supporting" and "supporting the right way".

> Let me sum things up: Linux has not conquered the world yet,
> but keep up a great job, guys.

I don't think its possible to have one OS that does everything brilliantly.
There is a vast amount of difference between the 8-128Mb desktop/small
server environment and a 10 processor SGI monster hammering gigabytes of
data off journalled raid arrays onto ATM.


 \ /
  Last update: 2005-03-22 13:37    [W:0.164 / U:1.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site