Slashdot Mirror
Will Pervasive Multithreading Make a Comeback?
exigentsky writes "Having looked at BeOS technology, it is clear that, like NeXTSTEP, it was ahead of its time. Most remarkable to me is the incredible responsiveness of the whole OS. On relatively slow hardware, BeOS could run eight movies simultaneously while still being responsive in all of its GUI controls, and launching programs almost instantaneously. Today, more than ten years after BeOS's introduction, its legendary responsiveness is still unmatched. There is simply no other major OS that has pervasive multithreading from the lowest level up (requiring no programmer tricks). Is it likely, or at least possible, that future versions of Windows or OS X could become pervasively multithreaded without creating an entirely new OS?"
Given that most machines are already starting to come default with 2 cores, and you can fit 8 cores (2 CPUs) in a nice desktop package, it's pretty clear that it's going to be a requirement.
It's not entirely the operating system's fault. The biggest advance of BeOS wasn't necessarily just that the kernel was designed to multithread nicely, Be also did their best to force you to write multithreaded code when you wrote a Be application.
I suspect that the first thing that's going to become clearly a performance bottleneck is the applications. And that's not going to be fun, because there's a lot of applications out there and you can't just magically recompile them with threads turned on and see much difference. You need to synchronize the data structures for multiple threads touching them at the same time and split things up so that you can actually keep a decent number of cores busy. This is not trivial when you are talking about an app that somebody wrote single threaded in the mid 90s without any notion that threads might be useful later.
Gentoo Sucks
The ability to play eight movies simultaneously is a bad way of determining OS thread performance. Most modern operating systems have efficient, low-overhead threads. How well they play multiple videos depends much more on the display pipeline, the codec, and how the players adapt to load. To say anything about system performance, you'd need to know frame rate, resolution, codec, postprocessing options, etc.
Overall, I really don't see anything in BeOS that you don't get as well or better in a modern Linux system. BeOS has some efficiency gains from having been developed from the ground up with little need for backwards compatibility, but that's probably also why it wasn't successful in the market. And threading and scheduling in particular are highly efficient and mature in Linux.
(Not that OS X is basically a hacked NeXTStep; the NeXTStep kernel is Mach, the same kernel that is the basis of the GNU Hurd.)
I think both NeXTStep and BeOS are living (dead) proof that Microsoft set the computer industry back over a decade. It wasn't until MS-Windows 2k that MS-Windows was even close to NeXTStep in features, and the cost was a lack of simplicity. (The only downside to the NeXT: Netware networking sucked. But Netware networking sucked on everything but DOS, so I guess it's no surprise.)
Same with BeOS. It had many features, including stability, ease-of-use, and responsiveness that MS-Windows can't seem to find today. Granted, neither can GNU/Linux or Mac OSX, but since they are hardly the predominant OS, I can't really fault them to the same extent.
Anyway, it's an old rant. Never mind the ravings of an oldster who never got over the sopranoing Microsoft gave DR-DOS. Those like me are just bitter our careers turned from fun and interesting to tedious and dull because of Microsoft. Y'all go on and play with your shiny new toys. No, really, don't mind me. I'm just gonna sit up here on my porch and get rip-roaring drunk and talk about the old days, whether anybody's listening or not.
Microsoft is to software what Budweiser is to beer.
I believe that's covered by "There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later."
Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.
Gentoo Sucks
Bah. Today's programmers aren't better or worse than they were ten years ago - they're just distributed differently. Programming video games on a console is an exercise in (frustration) poor tools, worse documentation, highly constrained memory / CPU / IO / bus, multiple threads utilitizing multiple specialized processors, microcode, assembly, etc. Ditto for cell phones. Not so for business applications.
So yes, if you mean "developers of business applications aren't generally hardcore down to the metal programmers," then I'd agree with you. John Carmack and Michael Abrash would be bored out of their skulls working on UI issues for Quicken 2008. And, given their aesthetic sensibilities, they wouldn't necessarily be the best choices (just *try* to balance your checkbook).
But if you mean that great programmers are no longer among us, then I'd say that you should change jobs, because it's more likely that they're simply not around *you*.
Thank Gawd Linux isn't using any relic of an OS that started in the 1970's as its base! No, no, all 100% 21st clean legacy-free implementation there.
On a more serious note, I used Beos myself back in the day. It was definitely more responsive than Win98 was, but not everything was perfect either. The networking implementation absolutely sucked. Oh, it had lots of threads, its just that the threads were not all that beneficial to actual performance. The networking stack and some other forms of processing in the system that handle streams of many relatively similar tasks would probably parallelize better via a pipeline scheme where parallelism is achieved by having independent stages of the pipeline run in parallel (much as CPUs break up the task of executing instructions into a pipeline). The type of parallelism that works best can depend on the application, and the one-size fits all philosophy is not usually correct no matter what the solution is.
AntiFA: An abbreviation for Anti First Amendment.
128MB? In the mid 80s? Maybe you mean 4Mb :-)
The big advantage with threads is that the TLB doesn't have to be flushed on a context switch, since they share the same address space. This has great performance advantages over processes, but you lose all of the advantages of protected virtual memory, hence the need for locks, mutexes, critical sections, etc. Threads are actually a step backward from a reliability/security standpoint.
BeOS was a single-user system, if I recall, so that partially reduces the need for the security features that having multiple processes provide.
But beyond that, modern OS's seem to offer a lot more flexibility. They have processes if you want separation of address space, shared memory if you need better performance for communication between threads, threading if you want a shared address space, and user-level threading libraries for the ultimate in performance if you're willing to spend the time to code it properly.
Being able to watch eight movies at a time is a neat trick, but it's not particularly useful, especially when we'll soon have processors with a ridiculous amount of cores on them. With a large number of cores, the overhead of a process context switch is hardly more than that of a thread, since a CPU intensive process can run on its own core.
I think the future of OS's is more likely to be in micro-kernel architectures that can move processes around efficiently to balance the processing load between many CPUs. Or a hybrid microkernel/monolithic architecture that could run the big kernel on one CPU for tasks that require responsiveness, and the rest of the kernel processes balanced between remaining CPU's for throughput.
If moderation could change anything, it would be illegal.
While C++, assembly and C might no longer be "cool", it definitely teaches people how to write optimal code, how to debug efficiently, understand a wide variety of computing concepts.
The same college today is too busy teaching C# and Java. While those languages are nice and all, not teaching low level C, C++ and assembly IMO leads to sloppy coders, people who don't understand the byte code generated, people who don't mind wasting system resources because hey
I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed.
Yeah, but yesterday's supercomputers are todays commodity machines. The last IRIX "super"-computer I used had 16 processors with a uniform memory architecture. We're quickly approaching that level on commodity hardware. My el-cheapo box has 2 processors with a uniform cache-coherent memory architecture.
What I'm getting at here is that perhaps we could look to the past for some ideas about multi-threading, and IRIX is not a bad choice at all, particularly since it was Unix-derived, like the Linux we use now, whereas BeOS is not.
Ask yourself this question, "Is High Performance Computing Really the Goal?" or is herding the consumer to newer shinier hardware the goal? The amount of computing power found in a typical Pentium III computer sitting out and someones curb far exceeds the needs of most users.
Apart from the corrections already brought up, the Amiga was rife with limitations and problems of its own. It worked great in the narrow range that it was designed for, but had all kinds of other issues. For example, upgrading the video was a hack job that usually require patching the ROM libraries with ones that new about the new video hardware. It was tightly integrated, which meant doing anything outside what it was designed for was often difficult and expensive.
And I was an amiga fanatic. And, while I held out hope that Commodore would get their act together and provide the features that were rumored and needed (DSP's, retargetable graphics, etc..) I always knew it would never happen. If only Dave Haynie had been allowed to do what he wanted, but then again that probably would have made it too expensive for people to buy.
If you need web hosting, you could do worse than here
Programming languages like Haskell and Erlang has very little problems with using a massive amounts of CPUs/cores. Look them up and learn about them, and you'll see that they can, without any fuss, spread over many many threads without any special code at all.
Well, that's it, read up and then maybe we can get some more interesting Slashdot postings about new computers:)
And it is quite amazing that Sun hasn't picked up on this. Their little Java thingie doesn't scale that well after all:)
I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version.
His reaction likely had little to do with code and alot to do with business. To managment's ears you said "This part is done, but I want to take time and money and re-do it really shiny." Now if craftsmanship meant anything in terms of the sales of software, you may have been listened to. But since the hardware companies are all too quick to step up and offer a new gizmo that will have you computer running "blazing fast", the consumer thinks that the sluggish performance is a hardware problem. The end result of all of this is the management of software companies sees little to no reason to take any more time or money than necessary to make a program clean and efficient.
We are all just people.
Vista, George W. Bush, elected because of his name, even though the prior iteration wasn't especially respected or well-liked. Introduced instability and performance issues, all in the name of "security". Many of the corporate interests who promoted him early on are having second thoughts.
I disagree with the premise that there wasn't acceptable justification for rewriting things from the ground up. Remember that the key players at Be were Jean-Louis Gasse (sorry for the lack of grave or accent or whatever the French thing is...) and Steve Sakoman. Their primary prior experience was at Apple. The biggest mistake that they made was in trying to create a better Mac OS than Mac OS. What they ended up doing was creating something that looked more like a better UNIX than UNIX, except that it lacked all the things that made UNIX great in the first place. To start with, the biggest thing they left out of BeOS was multi-user capability. That, IMO, more than anything else was what led to the downfall of Be.
I lost a bit of change on Be stock. It still pisses me off, because Be had the nucleus of a great idea, but failed to follow through.
I think Windows 2000 would be Reagan for the reasons you pointed out. Windows XP would be George H. W. Bush for following in the footsteps of its predecessor while having a couple accomplishments of its own (Persian Gulf War). Vista would be George W. Bush--trying desperately to follow in the footsteps of its predecessors, security-obsessed, but overall a miserable failure with dire consequences for privacy and freedom.
In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199
I don't understand this logic that a "full featured" operating system has to be slow. What the hell are you OS designers doing that's eating up all the juice ? Just because Windows XP preloads a gazillion binaries doesn't mean it's a good idea.
An operating system's job is to mediate access to hardware and software resources. The fact that every modern OS is madly bloated is just proof that the world's OS developers are ADHD suburban twits getting lazy and gratuitous with fluffy GUI features, when really they should be focusing on two core things: device drivers and the almighty scheduler.
Just think about it: Windows Vista is, on average, 10% slower than XP for generic tasks and gaming. Why the hell is that ? Someone fucked with the kernel and stuck things in it that don't belong there, like that ever-annoying popup security model.
It's like any other optimization job: you tighten the hell out of the most frequently-called code snippets like the scheduler and memory manager. If your scheduler is so contorted and polluted that it can't even fit in the L1 Cache anymore, you should be beaten with your keyboard!
The BeOS guys probably had a plan, along with some good brains and coding skill, and they stuck to that plan. If a feature isn't in the plan, it doesn't get coded; the system stays lean and fast, and you let the application developers handle all the shiny stuff. That's how it used to be, and still is in some circles... but not Windows nor Linux. That's where we went wrong.
-Billco, Fnarg.com
Oh bullshit. Perfect timing as well. Not five minutes ago my work desktop locked up for 45-60 seconds opening a simple HTML e-mail in Outlook and XP. As has been depressingly common with Windows for ages, having difficulties finding a remote source it simply ignored user inputs to concentrate on a network task presumably requiring well under 1% of the hardware's capabilities. Every Outlook window became unresponsive, as did server-hosted toolbars, etc.. These are architectural design decisions, not 'features' cutting off the use, unless 32-bit colour is now an extreme Windows desktop feature.