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?"

It makes sense with multi-core cpus

[Thaidog (235587)]

OSes like BeOS and Zeta are ahead of their time. With 8 core cpus coming out soon it just makes since with this technology... no programming tricks are needed.

Re:It makes sense with multi-core cpus

[tolan-b (230077)]

Haiku is coming along very nicely though, and it's open source.

Re:It makes sense with multi-core cpus

[by Anonymous Coward]

Seven syllables
Not seven? so use gzip
compress the fucker


;)

Re:It makes sense with multi-core cpus

[TheRealMindChild (743925)]

Good job I am a software developer and not an English teacher isn't it?

I don't think so.

Re:It makes sense with multi-core cpus

[jbrader (697703)]

You were allowed you to graduate...

Hahahahah! I found an error in your grammar rant, now you look even stupider than the guy you were trying to talk shit about. How does that feel you pedantic ass?

Microsoft's plan is to keep adding cores...

[Joce640k (829181)]

Microsoft's plan is for us to keep adding CPU cores in the hope that at least one of them won't be deadlocked at any given moment in time.

Multithreaded won't be optional any more.

[cmowire (254489)]

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.

Threading isn't any easier when it is pervasive

[mwadams (520080)]

It isn't really the pervasive multithreading that does the job on responsiveness for BeOS, and nor does having the "two threads per window" thing (which I think is what the poster is referring to in terms of "pervasive multithreading) avoid "programmer's tricks" - in fact, you have to be just as careful as if you were developing with Windows, and span up a background thread. One issue for BeOS developers was the amount of hard thinking you had to do to perform simple tasks in a pervasively multi-threaded environment, when you're still having to deal with all the pitfalls of lock-based programming.

However, taking only a few cycles to spin up or kill a thread (rather than the 10,000 plus it takes Windows), or perform a context switch, is a significant help. (There used to be an interesting article benchmarking those things on the Be website, but I can't find it any more).

MS have also added some more interesting stuff to the scheduler in Vista, which helps with uninterrupted sound or movie playback, so at least some of that stuff is possible without a complete redesign.

I don't get it

[nanosquid (1074949)]

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.)

Haiku

[Keruo (771880)]

Is not haiku(beos) open source?
Take the features and port to linux.
New scheduler rules them all.
Speed improvements would increase the desktop performance.
As they would increase performance with services.

Tried (for Windows) and killed

[gnetwerker (526997)]

Recall that this was the effet of Intel's NSP (the ill-named "Native Signal Processing"), a real-time multui-thread scheduler inserted at the device-driver level of Windows. Combined with something called VDI (Video Direct Interface), which allowed applications to bypass the Microsoft GDI graphics layer in certain ways, this allowed multiple video, graphics, and audio streams, mixed and synchronized, on circa-1993 computers, something largely not even possible today. While NSP was intended primarily for media streams, its technology was broadly applicable to more responsive and vivid interfaces. The result was Microsoft's threat to cut off Intel from future Windows development and specifically to withhold 64-bit support from Itanium, to more publically support AMD (which they did, for a while), and to threaten any OEMs using the code with withdrawal of Microsoft software support. Much of this was detailed in the Microsoft anti-trust trial and the accompanying discovery documents. Under this pressure, Intel abandoned the software, transferring VDI to Microsoft (it formed the core of what was later called DirectX), and outright killing NSP. Andy Grove admitted to Fortune magazine "We caved." (http://cyber.law.harvard.edu/msdoj/transcript/sum maries2.html) This is not to suggest that this was the best or only way to do this, or that others haven't done it and done it well. But despite the best efforts of Linus and friends, Windows remains the dominant desktop OS, and Windows continues to be built on a base of 1970s-era operating system principles. Microsoft has, and continues to, build substantial barriers to anyone trying to substantially modify the behaviour of Windows at the HAL/device layer. Whether VMWare and equivalent virtualization technologies are finally a camel's nose under the tent edge remains to be seen. But as long as Windows remains the dominant desktop OS, you can expect the desktop to lag 10-15 years (at best) behind the state of the art in OS, GUI, and real-time developments.

Re:Tried (for Windows) and killed

[CajunArson (465943)]

Windows continues to be built on a base of 1970s-era operating system principles.

Thank Gawd Linux isn't using any relic of an OS [wikipedia.org] 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.

Yes

[MarkPNeyer (729607)]

I'm a CS grad student at the University of North Carolina. I've never used BeOS, but I'm confident that responsiveness will increase, because the work I'm doing right now is attended to address this very issue.

The thing that makes multi threaded programming so difficult is concurrency control - it's extremely easy for programmers to screw up lock-based methods, deadlocking the entire system. The are newer methods of concurrency control that have been proposed, and the most promising method (in my opinion) is 'Software Transactional Memory' which makes it almost trivial to convert correct sequential code to code that is thread-safe. Currently, there are several 'High Performance Computing Languages' in development, and to my knowledge, they all include transactional memory.

The incredible difficulties involved in making chips faster are precipitating a shift to multicore machines. The widespread prevalence of these machines, coupled with newer concurrency control techniques will undoubtedly lead to an increase of responsiveness.

Multithreaded Windows

[Tablizer (95088)]

[BSOD]

  . , . . , . . [BSOD]

  - . [BS0D]

[BSOD]

  . . , . [BS0D]

  - . [BSOD]

Re:Question...

[cmowire (254489)]

BeOS was like JFK.

The both got gunned down before we could possibly see any downsides to them.

There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later.

Re:Question...

[iluvcapra (782887)]

This is good, I like this political stuff:

MS-DOS 1.0 was Herbert Hoover, aloof to the problems of the common man but friend of the engineer in all of us. Also discovered Transformers.

Mac OS 7-8-9, all Franklin Roosevelt, very competent, lead us through difficult times, but left a legacy of programs which have become quite a mixed bag.

Windows 3.1, Dwight Eisenhower, amiable enough, competent, but leaving historians (and many contemporaries) very wanting.

Windows 95 thru ME, Lyndon Johnson, one of the boys, very able at getting things done, but in the end a disaster, rightfully ceding his throne.

Windows NT, Richard Nixon, the archetypal back-room politician, ruthless, and ultimately brought down by little faults, but many believe he was a great president and did much to modernize the Republican Party.

Windows XP, Ronald Reagan, everybody who hates him never met him, he could charm anyone, the Great Communicator. Bought Iranian weapons for contras with drug money.

Mac OS X, Bill Clinton, cheerful and smart, if not the most productive. Known for his speeches.

Re:Question...

[nomadic (141991)]

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.

Re:Question...

[cmowire (254489)]

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.

Re:We had different programmers 10 years ago

[bratboy (649043)]

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*.

Re:We had different programmers 10 years ago

[dc29A (636871)]

Bah. Today's programmers aren't better or worse than they were ten years ago - they're just distributed differently.

I am not so sure. I remember my first C++ class in college, we didn't touch C++ for at least half the semester (well almost). We learned the basics of OOP and the rest of time was spent on learning how compilers compile code. We also learned a lot of assembly. Hell, in mainframe assembly class we wrote an entire assembler. Bonus points were given to people who used their own assembler to generate the code of the assignment.

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 ... the garbage collector will take care of it.

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.

Re:We had different programmers 10 years ago

[Original Replica (908688)]

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.

Re:Amiga beat them all

[nogginthenog (582552)]

128MB? In the mid 80s? Maybe you mean 4Mb :-)

Re:Amiga beat them all

[GreggBz (777373)]

Hey, I'm all for Amiga's but in the mid Eighties, if you had 128MB of ram and was downloading a file online, you must have been from the future.
What the heck are you talking about?

Just to be a little more correct here, I'm no hardware engineer but will try to be far more accurate.

The Amiga had a great messaging system in it's OS, you could easily pass messages to other windows and programs in intuition. Further, you had all that ARexx stuff, and you could script programs to interact very easily with it. Basically, every program could listen on it's own ARexx socket for commands from other programs. Of course, there was the poor (read, no) memory protection which made things very unstable if you did not know what you were doing. Despite all this cool stuff, the OS was actually the weakest link. It was rushed. I remember reading specs on the original intended, but non-implemented file system, and it was about as robust as a single user file system could possibly get.

You also had preemptive multitasking (not true co-operative) and a fantastic unified memory architecture with a very fast blitter. Another nice thing was
that the kernel was contained on ROM so that it booted quicker then any other platform of it's day, and still faster then most this day. And all those chips played nice
and were synced to an internal clock that ran on NTSC (or PAL) timings. This, of course, meant that interrupts worked seamlessly, and the chipset was handily compatible with video signals from television equipment. That last thing turned into an incredible boon for the entire film and television industry.

The strength of the Amiga was it's bus and it's architecture. They absolutely nailed so many things in it's design, it really was a thing of beauty.

Re:No Maybe Yes

[PacoTaco (577292)]

This is a multithreaded comment, right?

Re:No Maybe Yes

[someone300 (891284)]

X is being fixed, thankfully (finally). There are a lot of interesting projects, including but not limited to Xegl. Xegl, is the long term goal of the X server and pretty much reduces the X server to a tiny part of the system, basically mediating the input devices, rotation and display management and TCP/over-the-wire GL, if I understand correctly, by using the Embedded GL specifications.