Eternal September has hit /prog/. It's over, it's gone. The influx of new users here has overwhelmed the community. They have won. It's time to find a new home.
>>17
you can join our private area of /prog/ if you pay us enough ;)
Name:
HMA MEME FAN2009-04-22 17:11
hax my anus is the best
fuck you if you don't like it
Name:
HMF POSTER FAN2009-04-22 17:12
hax is anus
Name:
Anonymous2009-04-22 17:16
Since I have been able to find an intelligent posting in this thread,
I will respond to it and explain what I can as chief architect of the
SparcLinux port.
The main points of interest are:
1) Solaris's networking stack, in all of it's incantations (one breed
of it was the Lochman code in 2.0, 2.1 and early 2.2 releases, then
it was rewritten by another company for 2.3 onward) is SVR4 streams
based.
2) Linux is light weight, Solaris is a pig.
3) Every BSD and SVR4 based system today, except for Linux, has a very
broken System call mechanism.
4) Solaris cannot even do it's own optimizations correctly because
SunPRO is a broken compiler.
So my question always is, in matters such as these. Who are these
processor cycles for anyways, the kernel or the user? Think about
this when you consider how much overhead is being saved from one OS to
another, and to what scale this is occurring.
I hope that explains some of it, and gives people at least some sort
of idea of the kinds of things that makes Linux scream on just about
any hardware. If people would like more explainations like the above,
I'd be more than happy to chat with you via email about it or
similar. I love talking about performance issues on various
processors and systems.
Oh, and one thing that has not been mentioned yet in this thread (and
yes NetBSD/OpenBSD both have this as well, good work guys). That
SparcLinux kernel that gets all of this incredible performance runs on
both sun4c and sun4m machines. Sun Engineers way back when scratched
their heads for months and couldn't figure out a way to pull it off
(you need a seperate kernel image depending upon whether you are
running on a sun4m or a sun4c, for SunOS/Solaris). And on top of that
Linux obviously pulls it off efficiently.
One final note. When you have to deal with SunSOFT to report a bug,
how "important" do you have (ie. Fortune 500?) to be and how big of a
customer do you have to be (multi million dollar purchases?) to get
direct access to Sun's Engineers at Sun Quentin? With Linux, all you
have to do is send me or one of the other SparcLinux hackers an email
and we will attend to your bug in due time. We have too much pride in
our system to ignore you and not fix the bug.
Name:
Anonymous2009-04-22 17:42
>>21
Since I have been able to find an intelligent posting in this thread, I will respond to it and explain what I can as chief explainer of this board.
1) We conjure the spirits of the computer with our incantations.
2) All pigs must die.
3) System calls are for pussies.
4) Compilers are for pussies.
Processor cycles are for the processor, stupid.
Linux has no mouth and it must scream.
Linux pulls it off. Efficiently.
Let's make a Linux Pride Parade!
>>21 3) Every BSD and SVR4 based system today, except for Linux, has a very broken System call mechanism.
Which explains why FreeBSD has binary compatibility with Linux. That's right. The FreeBSD kernel supports both the BSD syscall conventions and the Linux syscall conventions. So how is BSD broken? IHBT
>>26
dude the sussman called you a pedo are you going to take that
Name:
Anonymous2009-04-23 18:07
>>26 You'd think that when people put together function call conventions
for a particular processor, the OS people would take a look at this
and find a way to take advantage of this. In fact, believe it or
not, they have not to this very day.
Linux from day one, takes advantage of the procedure call
conventions on a particular architecture so that it can process
system calls in the most expediant way possible. I will give
an example on the Sparc to prove this:
Consider your average 3 argument system call. The user level
code does something like this:
At this point control reaches the operating system, it must
prepare to handle this request from the user. On the Sparc, this
is either a two step or a three step process depending upon
whether you are doing it in the traditional broken UNIX way or the
clean, fast, and superior Linux way. First I will show the Linux
method for doing this:
1) Step one, jump onto the kernel stack for this task
and make sure the kernel has a register window to
operate in safely.
For Linux the code path for this runs at ~18 instructions
for the common case (the kernel already has a valid
register to use so now saving needs to be done). It runs
at ~42 instructions for the second most common case (the
kernels needs to allocate a new register window and the
user has a valid stack pointer) and ~82 instructions for
the least common case (kernel needs a window, user has
an invalid stack pointer, thus the kernel needs to save
the user's window into a special per-task save area).
2) Take the system call number, check for valid value, use
this to offset into a table of system call function ptrs.
Move arguments into place and perform the syscall.
Basically this is a simple operations a looks something
like:
That is it, that is the entire system call under Linux.
Under Solaris/SunOS things are wildly different. Step one is
basically the same, but step 2 is disgustingly inefficient for
those systems. Basically they do:
2) Call common system_call() C function.
3) This routine allocates a "system call argument package"
structure on the kernel stack. This is wasteful because
we already have all of this information in registers or
in guarenteed save areas.
4) Then this routine determines the function to call, and
passed this "package" of arguments to the routine.
5) Every system call which expects arguments then must
"unpack" this structure to get at the copy of the arguments
again highly inefficient.
For every system call the system performs, you eat this unnecessary
overhead under SunOS/Solaris, under Linux only the bare minimum is
performed to do the system call successfully.
Name:
Anonymous2010-03-03 7:23
SUCCESSFULLY CALL MY ANUS
Name:
Anonymous2010-03-03 7:27
>>30
this is an interesting thread.
thank you for bumping.