“If there’s a real bottom line here, the one thing I’m clear on is that I haven’t found it yet, but the questions raised have been more interesting that the answers — so more help would be welcomed.” Read the article at LinuxInsider.
Comparing Linux to System VR4
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t like this article. It’s a buncha talk without proving any of it. I don’t see any citations or examples at all. I also don’t like how the article makes it seem linux is better than everyone else, even if it is.
I have to agree with the first poster that the article was nothing but a bunch of talk. Doesn’t even have the decency to draw up a conclusion.
I’m not sure what the article was about. Why is it important to compare Linux 2.6 to a UNIX kernel from 1992?
RE: “i dont like this article”
He actually doesn’t try to say that Linux is better. He sort of hints that real innovation occured elsewhere, first, and Linux borrowed that.
I concluded that linux really is just a re-implementation of unix and hence does much the same things albeit with incremental improvements in efficiency and the benefits garnered from new hardware.
Basically there has been no real technological innovations from the last decade that have fundamentally changed our computing experiences. Things aren’t really changing much. They are getting better though. (And a LOT more complicated judging by the author’s erratic thought processes)
This sort of makes sense. The way we use computers hasn’t really changed much since the 80s and we now define computing as what we have. A revolution in computing would probably be called something else.
Nothing new under the sun today.
The author is being deliberately obtuse.
“threading doesn’t have a legitimate role in the Intel x86 hardware environment”
What?! Any processor that has a stack, can save context, and has a non-maskable interrupt can do multi-tasking and threading is another form of multi-tasking. If threading didn’t have a legitimate role in the x86 environment then why did Intel add the test-and-set instruction to the 386 IA when all it’s really good for is semaphores?
“because the hardware defeats the goal of true concurrency between threads”
What does this have to do with x86? Single core processors, by their nature, are incapable of “true” concurrency regardless of manufacturer. That is why companies work on multi-process capabilites and multi-core processors.
And he is confusing the relationship between threading and concurrency. Threading is about scheduling multiple execution contexts in a single address space while concurrency is about having multiple scheduling queues running simultaneously. Concurrency needs threading/multi-tasking while threading works fine without it.
every time they publish an article on linux, it’s bullshit. This time they try to make us believe that SCO somehow had influence on the linux dev process. Stoopid. Why is OSnews linking to that ?
… and I can’t see the point.
I’m using Solaris. the latest version.
I’m using Linux. All the time. It is cooler.
The GNU Tool chain has options, the unix binary tools present in Solaris environment per se (without doing additional install of linux gnu binaries – it is said to work) don’t offer.
Well – I’m as you see, biased towards the more developped and feature-rich GNU environment. When you can make a tarball and just add a flag to have it be piped throu the bzip for compression ( tar -cj ), this is way more convenient than tar -c mydir|bz2>mydir.tar.bz2
Other than that … hm, let’s see: I own a Sun Ultra 30. It has pci slots. With solaris you have no chance getting an ordinary rtl8139 NIC to work – it lacks some ROM openBoot needs to register it on the sparc hardware.With Linux this doesn’t matter. It simply queries the pci bus for the module I’m about to load – and voila, i’ve got an eth1 device.
Oh, yes, I’m biased and spoiled towards linux. And I don’t like this article with all this … vague statements claiming much and proving nothing.
none of the previous commentors seem to get at what he is saying in the article.
he isnt making any conclusions.
x86 isnt good at context switching. doing a context switch (ie: changing threads) is VERY EXPENSIVE on x86. it eats lots and lots of cycles. invalidating the cache for each thread is VERY EXPENSIVE. its high latency and long in cycle count.
the article doesnt aim to prove one is better than the other. if your able to comment on the sysv4r codebase or have developed on an r4 system, maybe you could help him out?
Oh, haven’t I?
Oh, well: If I were about to write an Article about “Sys IV vs. Linux”, I’d do my best to reach a conclusion. In the given structure, the article is weak. But of course, you are entitled to your opinion.
ad context switch – being expensive:
It is not more expensive than on any other system, where you have to save away all the registers of the processor. In fact, if you don’t have to reload cr3 on a i386 – and flush the tlb in the same process – it is rather quick at hands because you merely switch over to another flow of control in the same address space.
have a nice day
he isnt making any conclusions.
But he is stating things as fact when at best he needs to offer proof, and at worst he is plain wrong.
x86 isnt good at context switching. doing a context switch (ie: changing threads) is VERY EXPENSIVE on x86. it eats lots and lots of cycles.
A modern operating system (eg. Linux) can do it in a microsecond on modern i386 hardware (one million times per second).
But if your threaded app is doing that much context switching then it is probably broken by design. This is nothing to do with intel hardware or the operating system.
invalidating the cache for each thread is VERY EXPENSIVE. its high latency and long in cycle count.
Luckily intel hardware does not invalidate the cache every time threads are switched. In fact, due to their using the same page tables, not even the TLB need be flushed.
Please don’t argue with me.
I don’t know about you, but in the SunFire server administration class I took awhile back we used LinkSys NIC’s in the Ultra 60’s with no problems. See here (amongst other places) for more info:
http://homepage2.nifty.com/mrym3/taiyodo/eng/
http://sol-enet.sourceforge.net/
Yo, I think we are messing things up.. e.g There’s a guy who state he uses Sun Hardware, “sometimes” you can use x86 hw on it _but_ you got to stick to Sun certified hw, it’s got nothing to do with “bah.. I can’t have my realtek card to work on Solaris SPARC bla bla bla
“…
The GNU Tool chain has options, the unix binary tools present in Solaris environment per se (without doing additional install of linux gnu binaries – it is said to work) don’t offer.
That’s another story… if you want to develop on SunOS either do with GCC or “pay” for the compiler suite.. paying would give you a speed up on your binaries.
Yes, context switching is very expensive on the x86 architecture… nowadays we have > 3ghz processors that makes a little penalty effect on the OS you’re using.. e.g GNU/Linux. Somehow that’s why we have a lot of x86 playing into the enterprise market today.
So, some might agree on the quality of this article, some might not.. but one thing for sure, if you don’t know what’s this guy is talking about, instead of flaming why don’t grab some books and start reading and learning today…?
Peace y’all, culture is a pleasure.
If you’re accusing *me*, state so. *gg* and btw it has got to do with *I can’t get my PCI hardware work with Solaris sparc* You are mixing i386 with PCI. *gg* And no, I am not unhappy, so you can give the
away.
Oh, and thanks for the Links, maybe I have googled the wrong way.
Btw: stating that something is expensive needs a comparison point: more expensive than *what*?
Can you tell me what’s expensive with the context switching on a i386 – i say soft ware task switching, not jumping to a tss, ok? – compared to switching context on Sparc Architecture? Do you know how it is done on sparc architecture? (some task state segment? Need to switch stacks?) Does Sparc have a page directory register (something like cr3 on i386)?
I admit, intel 386 architecture is a bit of cheap and seems lovelessly assembled in some ways – all those backwards compatibility hacks. But proof is asked for concerning expensiveness of context switching (especially without reloading cr3 and flushing tlb). *winkwink*
I’m writing an OS, which is getting to an advanced state by the time, so, I might know what I am talking about, hm? Maybe porting it to my Sun Ultra30 reveals some secrets?
Oh and btw, maybe my arguments don’t come over as expected. I’m rather good in english, but that doesn’t mean I’m perfect with sensitive grammar/words. 🙂
At last, peace. But I enjoy a good discussion. 🙂
“none of the previous commentors seem to get at what he is saying in the article”.
Ceaser, Paul Murphy himself doesn’t seem to know what he is talking about. There are a lot of contradictions in his article. The paragraph where he mentions USB devices illustrates this point :
a) he starts with “Unix threading versus server/desktop distinction fomented by Microsoft”;
b) he goes to “using USB devices and running JVM on a dual processor (in Linux versus SVR4)”;
c) he ends with “the potential use of USB and JVM on NCR MP-RAS”
I’ve followed the link to the article describing the SunOS 5.0 kernel. I believe the initial goal of Paul Murphy was to find out if and how linux implements the following features (compared to SunOS 5.0) :
a) fully preemptible, real-time kernel
b) concurrency on SMP systems
c) support for user threads
d) interrupts handling
e) mutual-exclusion locks
It seems that Paul Murphy cut the answers he got from readers then made an article out of it. It’s almost as bad as the piece Jem Matzan wrote about FreeBSD 5.3.
Shameless plug :
I love multiple tabs; I’m writing this in Konqueror with tabs openned for LinuxInsider, OSNews and the SunOS 5 pdf file. Go open source !
The author goes off topic right away, and never goes back on topic. Seemed that way to me anyway.
The author usually writes good articles, but this one is terrible. Not only it’s pretty unclear and unstructured, but also, any industry veteran will know that it’s not “VR4” but “SVR4” for “UNIX System V Release 4″…. It’s not entirely his fault as he uses an article dating from 1992 where they talk about SunOS 5.0. There was never a SunOS 5.0, at all. It stopped at SunOS 4.1.4. Then they switched from a BSD tree to a SVR4 tree, and called the new OS “Solaris 2”, calling the “old” SunOS “Solaris 1”.
hi beyond infinity how is blueillusion??
task switching is expensive in hardware, as you well know
whats the point in comparing hardware task switch to a single address space system with software context??
even if you switch threads and dont flush etc, your still thrashing the cache and the bus (p4 bus is hopeless for this, amds bus is loads better with p2p bus…)
if it were so easy, everyone would have fastpath low latency threading for things like audio.. even linux has trouble with low latency, same with nt/xp etc… let alone good realtime…
-df, mega-tokyo.com…
“On the other hand, this variation on the main question also raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial — meaning that they don’t seem to be direct continuations of code evolution up to 2.4 and thus raise the suspicion that the SCO/IBM lawsuit might be having some unexpected design consequences.”
He first criticises the kernel of being evolutionary and not revolutionary enough(which he considers BSD to be). Then he criticism the improvements to the kernel because they are revolutionary?? WTF??
There aren’t huge differences in memory management between 2.4 and 2.6 anyway. They both use aa’s new vm.
There are huge differences in things like scheduling, etc..But they are made for a reason and most of these improvements came from Ingo Molnar(who doesn’t work for IBM).
I believe it’s hands-down trolling to say “SCO/IBM lawsuit might be having some unexpected design consequences.”
Any processor that has a stack, can save context, and has a non-maskable interrupt can do multi-tasking and threading is another form of multi-tasking.
The timer interrupt doesn’t have to be a NMI. In fact, sometimes you wouldn’t want it to be (e.g. during boot or when starting another processor). The NMI as defined on x86 would be useless for a task switch interrupt anyway, because the system state is undefined once it has been asserted.
This guy is clueless:
Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now, for obvious design reasons consequent to an underlying sequential processing assumption, but it shouldn’t be impossible.
Yes, it’s impossible (assuming the “efficient executable” proviso), because all higher-level optimizations require information about context. For example, how do you do dead-code elimination in one pass? It’s just not possible, as you can’t elide a definition when you encounter it without knowing if it’s referenced later.
On the other hand, this variation on the main question also raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial
What the hell does that mean? How can a design be “artificial”? And who is this memory-management guru that’s judging it to be so?
Take a good look at Darwin, for example, and you’ll find essentially nothing in the kernel that’s directly from either BSD 4.3 or SunOS 4
In what alternate reality? Really, download the source for both, large portions of many important files are nearly identical.
Don’t think it terms of the x86 processor or the x86 architecture but in terms of what is needed to pre-emptively multi-task on a processor.
The timer interrupt doesn’t have to be a NMI
No it doesn’t but it needs to be non-maskable. A physical NMI fits the bill for processors that don’t implement task restrictions on masking interrupts.
In fact, sometimes you wouldn’t want it to be (e.g. during boot or when starting another processor).
You’re going way beyond the basics. Murphy was trying to imply that Intel has made their processors/architecture hostile to multi-tasking/threading while I was pointing out that the necessary harware requirements for multi-tasking are trivial.
The NMI as defined on x86 would be useless for a task switch interrupt anyway, because the system state is undefined once it has been asserted.
You are talking about the traditional x86 architecture. The processors themselves implement the NMI in the traditional sense but, again, that is going beyond the basics. Intel has designed their architecture explicitly for multi-tasking, i.e. test-and-set for semaphores, multiple ways to implement privileges, memory management, etc, in the processor _and_ in the supporting chipsets.
I know that you, Ryan, understand this at the processor level and at the system level. Murphy doesn’t even grasp the fundamentals of what threading is let alone how to implement it yet he feels it necessary to comment on it critically.
“threading doesn’t have a legitimate role in the Intel x86 hardware environment”
Tell that to IBM and those of us who use OS/2. Its threading model is perhaps the best on any x86 platform.
task switching is expensive in hardware, as you well know
whats the point in comparing hardware task switch to a single address space system with software context??
Task switching is not expensive. A modern x86 can do a million per second. Point me to a sanely coded threaded app that needs even one hundredth that rate.
even if you switch threads and dont flush etc, your still thrashing the cache and the bus (p4 bus is hopeless for this, amds bus is loads better with p2p bus…)
No you don’t nessecarily “thrash the cache and the bus” when switching threads. If your working set fits in cache then you’re fine. If the same system was made single threaded, then it wouldn’t magically shrink its working set size.
And in fact, having multiple threads means you’re more likely to be able to spread the working set over more CPUs, and hence make _better_ utilisation of cache. Pretty standard fare for high performance scientific apps.
if it were so easy, everyone would have fastpath low latency threading for things like audio.. even linux has trouble with low latency, same with nt/xp etc… let alone good realtime…
Buzzword overload. “low latency” has nothing to do with threading, and I can’t even begin to guess why you threw “fastpath” in there. And realtime is, by definition incompatible with a general purpose operating system. Linux is not a realtime system so it doesn’t “have trouble with good realtime”, it simply isn’t a realtime system. Full stop.