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
Windows, No they'd have to do a require which they already tried doing and failed at OS X, Possibly but FreeBSD would have to do it first Linux, yes but probably won't happen until the 2.8 kernel since it would rework how the kernel works while making sure it still runs on older hardware. glibc would also have to include support but its much more likely on GNU/Linux being that its all open source and thus anyone can work on it.
Nice try with the /. friendly, but ultimately meaningless and ignorant, tirade. CPU cores don't get deadlocked, threads in a cyclic wait pattern get deadlocked. It doesn't matter which core they run on. You could have a million cores, but if two threads are deadlocked, you're still screwed as far as the program goes. And the article was about BeOS, not microsoft!
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
given that Windows still bogs down at the drop of a hat.
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.
The time to load apps is still routed in the size of the exe and the work needed doing to run it.
Old systems didn't have bloat because characters were bytes and graphical entities were flat bitmaps.
Nowadays we have jpeg encoded resources and double byte strings and all sorts of other magical crap.
Programs were (mostly) written for one language and didn't need to adapt themselves to multiple systems.
I bet if you tried to work inside the restrictions of olders systems programs would fly along now, startup times would be low, response times would be low.
Just because we have faster systems does not mean we can add more bloat.
liqbase
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.
ffs, nitpicking git :P
v2:
Haiku from BeOS
Multitasking all programs no delay
Open source for the win
(5-7-5 syllables)
liqbase
How on earth did you fit "multitasking all programs no delay" into seven syllables?
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.
It also wasn't pre-emptive, nor did it have protected memory. It also didn't keep up with progress, when it ultimately died there really wasn't anything special to it, and the various recreation projects are struggling to retrofit more modern concepts into the basic design.
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.
The important thing to keep in mind is that BeOS was not a mature OS. In many ways, they had done just enough to get it going. My guess is that once they had the resources, it would have fattened up to the size of OSX or Windows easily, and all that performance you saw when it was young and new would go out the window.
BeOS had a lot of problems as well, for instance the OS was written in C++, which meant that when you wrote drivers, they had to be in C++. The software loaded fast, because it wasn't very mature. It was like loading notepad or kedit. Simple and easy, but once big apps were running on it, they wouldn't be quite so snappy as they loaded in the dozens or maybe even hundreds of components.
If you need web hosting, you could do worse than here
Forgive me, but STM is a crutch.
Yes, it will help the programmer masses not shoot themselves in the foot, but the overhead in STM is phenomenal, and you're relying on Moore's Law to save you.
If you want a responsive system (running on thread-unfriendly OSs like Windows) there's no substitute for knowing what you're doing.
We currently have some offshore developers who are peppering their code with Thread.Sleep() statements, with sleep values selected so that the code kinda-sorta works on their machines. They might as well as be doing Thread.Sleep(Rnd()) for all the good it's doing them.
What's needed is some education in how to write multithreaded programs -- and most universities are not able to provide that education or experience in the time available for a bachelor's degree.
I wish that Palm had open-sourced the BeOs source when they acquired the company. Or at least the parts that weren't encumbered by other people's IP. If it had been placed on Sourceforge, it would have been a good starting point for people to learn how to do it correctly, and gotten some eyeballs on it to fix some it's warts.
Chip H.
Nice try with the intelligence friendly, but ultimately lacking in humor and clueless, tirade. Threads in a cyclical wait pattern don't laugh at jokes, people laugh at jokes. It doesn't matter what country they are from, if someone on slashdot says something funny, they will get modded +5 funny of course. And the GP was about having fun and laughing, not that deep cyclical-multilocking-thread-muju-muju!
Qxe4
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.
IBM made a decision in 1980 to go with the Intel 8088 (8/16 bit) processor instead of the Motorola 68000 (16/32 bit) processor. At the time, the Motorola processor was designed to be the processor of the future. On the other hand, the 8088 was intended to be almost compatible with 8080A assembly code. This created the need for the 8088 segmented architecture, and segments suck.
The use of segment registers set PC development back over a decade. Essentially, all the 80's was spent fighting segmentation wars. The IBM PC didn't get proper 32-bit computing until the widespread popularity of 386 PC hardware in about 1992, and the subsequent introduction of Windows 95. Windows XP was the first unified 32-bit Microsoft O/S in 2001. DOS mode was finally eliminated in Windows Vista in 2007!!! I think you had to live through segmentation and far pointers to understand how incredibly awful they were.
Interestingly, the Apple Mac had a 68000 processor in 1984. If that caught on, then it would have saved the PC industry a decade of pain. Apple made the decision not to license the operating system for the Apple Mac. The result was Apple hardware was expensive, so few purchased it. The problem was so severe that Apple almost went bankrupt before Steve Jobs returned.
IBM built Microsoft and Intel when they created the IBM PC. Apple rested on the laurels of a better architecture and almost went bankrupt. These two decisions defined at least 15 years of software history. It isn't until know where we see a few different pure 32-bit operating systems fighting it out on a common hardware platform. The Windows XP, Vista, OS/X, Linux battles will be interesting. The 32/64 bit battles will take place on PC hardware that is still almost completely assembly language compatible with the first widely used 8-bit Intel Microprocessor: the 8080A!
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
Wow. You seem awful sure of the future. Can I borrow your crystal ball? I'd like to look up next week's lottery numbers...
Looking at history, the computer industry seems to show a remarkable propensity to not learn from experience, and instead keep making the same mistakes over and over again (with different names). What evidence do you have that suggests that is going to change?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Given that you actually suggested rewriting in C instead of Python or something similar, I think your boss made the right call.
To be blunt: writing VB business apps in C is usually a stupid idea. Business app requirements change often and usually for nontechnical reasons. C is a low level language. But for business apps you'd only need to manipulate stuff at the "Lego level", not the "molecular level". So why use it?
It's near impossible for a normal company to hire programmers who can _rapidly_ write reasonably bug free C and maintain it AND _WILL_ do so.
And it usually takes a lot longer to get a new C program to decent standards than say a Python/Perl/Ruby program.
Getting a faster machine to run app = $$.
Weeks of programmer coding, testing and debugging = $$$$
Weeks of programmer NOT being able to do other stuff because busy rewriting old stuff = $$$$$$ - $$$$$$$$
Assuming a reasonable programmer ability, if you used a higher level language, changes would usually be done faster and with a better chance of correctness.
So my suggestion for most stuff nowadays is:
1) Use a high level language. Usually the performance bottlenecks for a business app are not due to the language but the architecture and design, or just plain IO.
2) Spend a lot of time designing it right with the future in mind - getting time and resources to rewrite in a business environment is rare - so if you do it right you maximize the lifespan of your software before cruft builds up to extremely annoying or even dangerous levels.
3) Leave the low level stuff to the John Carmacks.
So what if those high level languages are 20x slower than C? Unless totally braindead they are a _CONSTANT_FACTOR_ slower, so if they are fast enough NOW, then that's good enough. In 3-5 years time, even if the performance requirements may go up, new hardware is likely to run the programs at least 2-3X faster, and it's probably about time to replace the hardware as part of a preventative measure. If you are lucky and wise and your architecture can scale OUT instead of UP then that's a good situation to be in.
Since version 5, the Java platform introduced the Concurrency Utilities, a threading framework which significantly reduces the complexity, and increases the performance, of a large number of threading-related tasks. Things like creating controlled pools of threads that concurrently use data structures used to be very complex to implement, but now I teach my students this in a day. This, coupled with Just-In-Time compilation (and the clever optimisation possibilities this provides), may see Java as the best platform to develop software with in a future filled with multi-core machines. We are a small, specialist software development/training/consulting house, and Java's performance has allowed us to do unbelievable things with it, yet never having to sacrifice sound design for the sake of "performance optimisation". Java 6, which builds on this stuff, and includes full hardware-accelerated GUI, will (I believe) make very, very responsive and powerful GUI applications possible, without having to lock into some OS-specific framework (or X). Watch that space.
IMHO, the primary reason BeOS died is that they never got a real web browser working on it, at least not until it was too late. The web was exploding right around that time and the lack of a web browser was the kiss of death. Worse, it was a pain in the rear to compile Open Source apps on BeOS, the library support was incomplete and apparently there was some weirdness with the socket layer (which you need when you write an internet application). There were efforts to port open source projects to BeOS, but they were always slow with the internet applications.
Most of my experience comes from a roommate I had in college who used it. He liked showing off how he could play 4 mp3s simultaneously (the OS I was using, FreeBSD, had difficulty playing any MP3s at the time), but other than that he was always lacking for application support. I wanted to try it out once, but the hardware support was too picky for my meager budget--I would have had to buy a bunch of new hardware just to get stuff that was supported, which I couldn't afford.
I read the internet for the articles.
Hmmm, possibly just displaying lack of knowledge here, but doesn't pervasive sort of mean "included in every layer and possible application" (sort of synonymous with "ubiquitous")? Most unlikely, I don't mean to bash Windows here, actually the more of that they can cram in there the better for people using it (true for every OS), but "extending pervasiveness" seems to be somewhat of an oxymoron in my understanding.
/F
Am I completely wrong in this?
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
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.
There is nothing magic about threads. Sometimes a multi-threaded process is the right approach, sometimes a multi-PROCESS application is better. Sometimes a process is intrinsically serial in nature and any gain from threading will be more than swamped by the overhead.
While sometimes obscured by terminology, threading isn't a single entity. For example, if a process mmaps in blocks of memory with MAP_SHARED, then creates pipe pairs and forks, it IS a multi-threaded application in some sense, but isn't what many think of as threaded. For that matter, the mmap step can be skipped for some server applications and still be multi-threaded.
A single process with a single thread in it MIGHT be somewhat multi-threaded if it does it's I/O through various asynchronous calls.
At the same time, an application that explicitly calls thread creation functions might be effectively single threaded if resource (lock) contention is such that no more than one ever runs at the same time. Another case of being effectively single threaded is when an application is event driven and even though events are dispatched to worker threads, the thread typically completes it's handling before the next event comes in. This will often be true of interactive applications where the user won't likely keep issuing commands until they see the results of the previous command.
OTOH, things like image processing in GIMP could stand to be multi-threaded where the work is tiled and dispatched to worker threads.
Until recntly, multi-threading has only been beneficial to a small percentage of users anyway. Most people until recently have had single processor systems.
BeOS's legendary media handling was more the result of carefully designed and tuned media subsystems than pervasive threading.