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?"
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.
||| I still can't believe Parkay's not butter.
Back in the OS/2 days, we could format 72 floppies simultaneous with no slowdown to our 14.4 connections!
The obvious lack of software etc. notwithstanding, would Slashdot agree that BeOS was the best OS of its time?
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.
No sig today...
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.
I still hate that BeOS went belly up. It was a great operating system but was crushed before it ever got very far. The hardware support was also amazing: it would run winmodems and other windows only hardware. I've never tried writing an operating system, but I hope some of the features from BeOS make it into linux/OSX. One interesting thing to note is Be was originally a mac alternative and was only later moved to x86.
Another cool operating system to check out is MenuetOS... it is written entirely in Assembly! Very fast boot times and the GUI and eevrything fits easily on a floppy!
Get a web developer
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.
...QuickTime and the AppKit become threadsafe. Which might be a priority for Apple, but then again might not, given that they've had multicore machines for a long time. Cocoa doesn't lend itself well to the UNIX approach of multiple processes, so if we really want to take advantage of multiple cores, Apple's going to need to seriously step up their multithreading support.
The AppKit docs are riddled with notes like "on the main thread" or "some thread will receive this notification". Maybe Leopard will change that.
I would like to see bit-slice systems return. I had an AMD system built around four of the 2900 4-bit slices and an old TTL Xerox Alto.
I like them because you could microcode these to act like a whole range of different machines. Intel, Motorola, Signetics (2650), Mesa, etc. They were a lot of fun, fast and resource efficient.
Yes, they were power hungry because of all the TTL but a single computer could be configured to be many different machines depending on what you wanted.
Banjo - The more I know about Windoze, the more I love *nix
A few years ago, on a Dual Celeron 366Mhz with 256MB of RAM, I went out of my way to attempt to crash it. I opened about 120 OpenGL demos with only minor decrease in performance. After inherriting that mainboard, processors and RAM from my uncle and then increasing it to 512MB, the same test ground both FreeBSD and Linux to a halt.
Today's programmers are not trained to write efficient code (i.e. massively parallel) using good tools, or even in making good technical decisions. The goals of "cheapest available coders" won, so now they will need to develop AI programs to generate this kind of code becuase today's group of lowest-cost "programmers" certainly cannot do it.
for older (p2 & p3) laptops. I have the opportunity several times a year to receive old laptops to use to teach my students with. Whenever I need to I use Beos Max on the machines and it is just amazing to watch how effecient and responsive Beos really is.
Check out Beos Max
Beos is still a lot of fun on older hardware.
load "$",8,1
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.)
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.
There are no atheists when recovering from tape backup.
Aside from having "legendary responsiveness", from a single CPU box to SMP monstrosities, you could even guarantee disk/cpu/whatever throughput.
A lot of the old unixes had "legendary responsiveness"; you are not a unique and beautiful snowflake.
BeOS fanboys are funny.
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.
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.
My blog
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.
This is just another example of wonderful old technology that has gotten lost instead of getting incorporated into the current technology.
It makes old folks boring, but when they go on and on about how wonderful something was in many cases they are right. Burroughs processor architecture... Multics security... AppleTalk networkings ease of use... why can't the new stuff be as good as the old stuff, rather than being a quantum leap ahead in some aspects but a quantum leap behind in others?
As nearly as I can tell, the computer industry has the worst case of Not Invented Here I've ever seen. Somehow it seems as if we lovingly keep all the worst crap from the past, but completely throw out the good stuff.
given that Windows still bogs down at the drop of a hat.
Serious back in the mid 1980's I used to love putting PC and Mac owners to shame by showing them literally dozens of open, active graphics applications displaying animations, while formatting a floppy disk, and downloading a file online, and still having a normal responsive system with no hic-ups, all in a computer with on 128MB RAM.
Amiga was a multi-tasking, multi-threaded OS, with multiple processors (graphics and I/O were separate co-processors operating on opposite clock cycles from the CPU, and the graphics co-processor could be dynamically loaded with special executable code).
It was so far ahead of it's time that people today still don't believe it existed in the 80's when I tell them about it.
But just because it was better than everything else did not assure it's success. A concept the BeOS fanbois might be familiar with.
[BSOD]
. , . . , . . [BSOD]
- . [BS0D]
[BSOD]
. . , . [BS0D]
- . [BSOD]
Table-ized A.I.
I still get weird clicks when my XP box plays mp3s. My iMac (core2duo 3gb-ram) gets a bit flaky when it gets busy, and it will lag a bit when asked to move things around.
When I completely blasted my Be and it still manages to keep the mp3 from sounding like garbage. It was freaky smooth to deal with.. I still think of the Bebox when thing get weird.. Shame that it got killed the way it did.
Storm
Eight 160x100 videos simultaneously?
That was just plain suicidal. Which is why Hillary will never be VP.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
No, really.
He was shot in the temple.
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
If/when the CPU designers currently screaming "more threads, more threads!" at us coders get around to implementing efficient h/w transactional memory, painless fine grain parallelism may become a reality. Until then, STM may be fine for very large applications on systems with huge memories and lots of cores, but probably isn't an option for the average desktop.
But STM does present some intriguing possibilities for distributed parallel environments (think STM + DSM).
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
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.
Windows, as it stands today with it's Window NT origins, developed by VMS developers, has always had mutli-threading as part of the OS. *nix, on the other hand, has only had multi-threading as a pathetic add-on library long after the kernel was developed without multi-threading in mind. *nix has far more catching up to do than Windows, full stop.
I find it amusing when hearing people whine about how hard multi-threading and synchronization is. It just illustrates your weaknesses in coding. If I am hiring on a project that requires multi-threading (pretty much everything these days) I'll put Linux fan bois at the bottom of the resume pile.
"." they separate the sentences. Usa "." to break up the ideas into pieces that humans can follow.
Their signal at Pearl Harbor was Torah Torah Torah.
Infuriate left and right
What you say may have been true some years ago. Nowadays Linux is far more advanced technically than Windows with respect to multi-threading and even more multi-processor / multi-core support.
E.g. gcc does thread-safe initialization of local static variables -- Visual C++ does not. Linux runs on up to 4096 processor machines -- Windows does not. Linux can be run tickless (to some extend) -- Windows can be not. Linux has support for the SUSv3 realtime API with support for nanosecond resolution timers -- Windows has nothing comparable. Linux will shortly have the new completely fair scheduler (CFS) were a user reported that the system is still quite usable with 32k busy threads running in parallel -- Windows would be 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.
gcc does thread-safe initialization of local static variables -- Visual C++ does not.
VC++ does do threadsafe static initialization. And in any case, gcc runs on windows so it's not exactly a windows issue is it?
Windows has better support for multithreaded apps, it has a far richer set of thread/process synchronisation objects (mutexs, critical sections, semaphores, alertable wait states, events) than unix does.
Now, as far as 32k 'busy' running threads leaving the machine still responsive... let's just try that out..
DWORD WINAPI Th(LPVOID){ while(true); }
int main(int,char**) { DWORD id; for(int n = 0; n < 31999; n++) { CreateThread(0,0,Th,NULL,0,&id); } while(true); return 0; }
And I can report that yes, you're quite right, Windows is pretty much killed stone dead running these two lines of code. I'd love to hear a report from how Linux does running the equivalent.
Comment removed based on user account deletion
"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."
Funny how Apple gets left out in these discussions. Guess BeOS style performance on a Mac wouldn't be noticed.
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 think both NeXTStep and BeOS are living (dead) proof that Microsoft set the computer industry back over a decade"
Pfft! All it's proof of is that geeks don't know their history. Both CEOs made plenty of mistakes serious enough to keep their respective OS from taking off. At least Jobs got his revenge when Apple bought them.
On all your points. Transactional memory is a great cop-out, but nothing more. The overhead of ever having to use it for correctness is just too high to make it worthwhile. (Even on hardware like the stanford TCC system.) Unfortunately it's easy, and will therefore probably be the cop-out of choice, resulting in large amounts of crappy software that does scale, but much less well than it could have...
BeOs had no support for a multi user environment. People complain about the hardware support, but BeOs 5 PE supported all of the hardware I had Including a tv tuner that win 98 really didn't support very well. Much better support than I could find from Linux at the time ( circa 1999-2000 ). Again lack of software was a downer. I didn't have the gobe office suite, so I still had to use windows for office 97. I loved net surf browser and its haiku error messages. It made its lack of support for html fun.
Well.. maybe. Or Maybe not. But Definitely not sort of.
never tried BE, but if it managed to come up with an easy way to deal with threading then i'm impressed.
If you mod me down, I will become more powerful than you can imagine....
The thing is, you cannot truly compare Amiga with current OSs, because it had no memory protection and didn't run on PC's hardware, BeOS did.
And it was much more responsive than anything we have now.. Unfortunately, the situation won't change for a long time, because to have the same level of responsiveness as BeOS users enjoyed, you have to recode a big part of each application..
The availability of multi-core PC will ensure that the designers of new applications take into account multi-threading from the start, increasing the responsiveness of these new applications, but the migration will take a long time, *sigh*.
If someone want to see BeOS and it's open source counterpart in action and you live close to san-francisco, try to attend waltercon 2007 in august http://haiku-os.org/ (registration are open).
On the subject of multithread, it could be interesting if individual or computer store could bring some mad hardware for testing purpose. The amount of knowlegable folk present + the usual casual feel of the event would make that very possible think.
In my current work project (Java based) I decided to approach scalability in a manner that defies the normal J2EE (scale by adding container nodes) paradigm. The application scales by adding instances of services. The application itself consists of multiple services, that are independent and that do its own task and nothing else, the communications between the services are message based and can be implemented in multiple different ways, anything from a message queue to a custom servlet subsystem (sort of like webservices.) The scalability in this case depends on the design and not on the underlying container, and it appears to be a more robust design. Each service is multi-threaded and can be instantiated on different processors, basically it is a signal based architecture. Seems to work quite well for this particular project. Probably other applications can be created in this way to allow true scaling.
You can't handle the truth.
Or maybe you could say Microsoft has the biggest sort of stuttering problem in my house. Their software can't seem to even get started running at all here.
But I _can_ say it never stutters in the middle of a video.
"The NeXT was trying to bring a Unix-like OS to the desktop."
Microsoft did it first.
Apple was late.
"The fact that MS-Windows was sold by all PC vendors is what killed NeXT. It was stillborn."
Revising history, are we?
"Be Inc. offered to let PC vendors install BeOS for free, even in a dual-boot configuration. According to Jean-Louis Gassée, the PC manufacturers told him their deals with Microsoft wouldn't let them."
He had his chance when Apple was shopping for a new OS. Apparently he wanted too much money for the company.
"Microsoft's stranglehold on the distribution chain has caused much, much damage. You can blame DR-DOS, OS/2, BeOS, NeXT, and a slew of other vendors/products on "market forces," but the only market force that matters to any degree is Microsoft's regulation of the PC distributors."
No I blame it on their mistakes and greed. Something you intentionally glossed over.
Locks suck. Nobody really understands efficient locking schemes. You either wind up with (a) a system with a few giant locks, and little parallelism, or (b) a system with lots of locks, but also lots of crashes and deadlocks. Very few programmers can deal with this stuff.
As for lockless algorithms, even fewer people understand how to make these work. In the papers I've read on lock-free hash tables, there are many with bugs or very bad misfeatures in the algorithms. Additionally, system-dependent things (like cache coherency protocols, and precise definitions of how instructions work in various edge conditions) can leave you with code that *looks* portable, but isn't. (Don't get me started on varying degrees of quality of compiler treatment of 'volatile' and various extensions that amount to 'noalias' . . . and compiler bugs).
STM will likely bottom-out when (a) the cost of re-do becomes a huge issue, and (b) the cache coherency traffic becomes the real bottleneck. The first you can solve with code reviews and education, the second is just going to be a wall.
Message-passing looks (to me) to be the likely successful road. I guess it's time to do something real with Erlang. No smiley.
Any sufficiently advanced technology is insufficiently documented.
Hooray for the 6 bit character! (Was the byte 12 bit or 60?)
A huge file being copied, or a movie (or a few of them at the same time (a favorite trick of this OS)) being played back, and while I am interacting the UI, my commands are promptly being taken care of. No matter how huge the file being copied is, there is no delay between my mouseclicks and the UIs response. When Windows 2000 came out, I was hoping it finally implemented this feature, but it didn't. So when XP came out, the ultimate user-experience desktop, I hoped it would listen to me as BeOS did in the early days, but it didn't. I gave up on Linux doing so long ago, but then I tried Kubuntu, and was (not) disappointed (wasn't disappointed because I didn't expect much from the OS in this regard).
So why can't anyone else make the OS actually listen to the user's commands? I mean, that damned file copy can be late some milliseconds, if that will make the user interaction smooth. With BeOS (as I said, I first tried 4.0) there was no mouse pointer frozen, ever. Never ever was I clicking "blindly", all UI interactions produced the desired response.
And finally, no application would steal the focus. Windows just can't seem to get this right, while Linux, at least, has this one nailed.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
The OS that will work best will be the one that can schedule memory bandwidth the best. You can have all the cores you want, but if your memory bandwidth is not scaling nearly as fast (pin rates are not) then your cores will be completely stalled unless the programmer either blocks data correctly or the OS does something magical. Personally I'm not holding my breath for either. I'm just hoping that the cores power themselves off when they're waiting their 1000s of cycles for a memory request.
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!
" "; they separate the words. Use a " " to break up the ideas into tokens that humans can follow.
Personal opinion:
I think that the problem with STM is actually that there is little direct hardware support.
And by that, I don't mean fully transactional caches, though it'd be great if that could be done efficiently. The problem is that existing thread synchronisation mechanisms can be implemented fairly efficiently on top of existing hardware (atomic test-and-set, compare-and-swap or LL/SC). We don't yet know what the appropriate hardware operations are to support STM efficiently.
So I think that pervasive STM will happen, even on desktop hardware, and it'll be very efficient when it does happen. But it won't be for a decade or so at least.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
As one commenter mentioned many programmers are bad at writing reliable multithreaded code.
Microsoft realized this early on and put a bunch of barriers into windows (and more so into MFC) that are designed to prevent programmers from even writing multithreaded GUIs.
Let me make this clear. If you call an MFC gui routine from a thread other than the main GUI thread it will return without executing. If you "send" or "post" a message to a control from the wrong thread using the MFC versions of send() and post(), it will return without doing anything. Microsoft used thread local memory to prevent programmers from being able to write multi-threaded GUIs.
I've programmed work-arounds many times with user-messages and created programs that were as responsive as BEOS programs. Understand that the fact that most programs' guis lock up for a few seconds when opening files, etc. is the result of MS' decision to not trust programmers with multithreading the GUI.
I've also worked on multiprocessor, high performance server apps, and I know how obscure multithreaded techniques are, and how small mistakes can make software unreliable. I don't entirely blame MS for preferring reliability to responsiveness, but they are in a position where they could educate rather than restrict, and they chose restricting.
If it were that easy, wouldn't we be discussing how Linux has it and Windows has "missed the bus" on yet another innovative feature? I may be speaking from ignorance, but I suspect that the only reason BeOS could do it ten years ago, and none of the key players can do it as well today, is that it would require a massive (and expensive) redesign of the low-level components of the OS. (which didn't affect BeOS, because the developers factored it into the original design)
- Do we really need higher performance? Seriously, I don't notice that much difference between my old AMD XP 2200+ and the newest Core2 Duo processors, because the vast majority of the time, a process doesn't even stay on it for longer than a few timeslices. Truth be told, I just now noticed that my CPU is actually running at the speed of a 1500+ because of a BIOS reset that accidentally happened some month ago. I only noticed it because I wanted to check how fast my CPU really was. Almost all performance bottlenecks are caused by I/O anyway.
- Isn't that fact that you can run more processes simultaneously enough? As for me, I'd be happy enough by being able to run "make -j2" and actually having the compile go faster.
I can agree that there are a few cases where multithreading would make sense, and those would include such things as 3D rendering and multimedia encoding (although I'm not completely convinced that fork() is a perfectly acceptable solution there, too). There may be some others, too. But really, those applications are the minority. There just aren't that many CPU-bound programs these days.People seem to argue that it would make the UI of many programs more responsive, but IMNSHO, that doesn't necessarily mean multithreading. The basic problem is that the program in question runs several coroutines, and multithreading is only one of a great many solutions to good coroutine performance, and I would argue that it is far from the best one. The problem is not that the program is actually not getting enough CPU time (except in a few cases like Firefox, but one might argue that that's a bug).
The point of having end-user software be very highly concurrent isn't necessarily to make it have very high performance according to some absolute metric. You can use concurrency to make the software have a very responsive feel to the end-user. In fact, it's very often acceptable to make a program be slower overall in the absolute sense, just to make it respond faster to the end-user.
Are you adequate?
Are you adequate?
Depends on your point of view. Marketing sure thought segments were useful.
...
But the funny thing was that the segments might have actually been an engineering management benefit. The low ceiling helped keep projects small and manageable while budgets were small.
Of course, management (and marketing) that thought that even initial versions on 68K had to be significantly better than initial versions of comparable products on x86 probably contributed as much to the killing-by-adding-features as the lack of segment ceiling, but ceilings do have a use.
(And, of course, many engineers and managers saw the short address mode as a different kind of hidden ceiling instead of an opportunity for later optimization, especially since long branches weren't available until the 68020. (or was it the 68012? dang wet-ware database.)
As far as the assembly language compatibility, no, that compatibility can no longer be claimed. AMD has provided the path away from the other bottleneck in the x86, which is the lack of useable index registers, and iNTEL is following. x86 compatibility doesn't exist in the parts of the architecture where the "battles" of the future market will take place.
joudanzuki
Someday I'd like to have tens of millions of dollars to throw away trying to prove the 68K is a superior architecture to the x86. I mean, if iNTEL can burn up so much cash shoehorning the x86 into the future,
Me fail English. That's unpossible.
I think it is hilarious that you guys are having to compare the 1984 Amiga to modern day PCs, hardware, and operating systems just to try to find some way to trash it. Look at the original subject line, "Amiga beat them all" If you can find a personal computer and OS from 1984 that even comes close to the Amiga, then I'll take notice.
The fact remains that it took over 10 years for the rest of the personal computer industry to finally offer all the technology that was in the original Amiga (i.e. Co-processors, a pre-emptive multi-tasking 32-bit OS, high color graphics, real-time high color animation, stereo digital sound, etc.)
Hell, the Mac still is stuck with it's one menu windowing environment that hearkens back to the days of only being able to have one active application at a time. Pathetic!
The point being, just like the Amiga didn't take over even though it was 10 years ahead of it's time, BeOS and it's OS features will also be relegated to the trash heap of PC history. Having the best technology is no guarantee of success.
For an unbenchark, running 32K threads of while(1); on linux-2.6.20 on a pentium 3 gave Gnome fits, but the console remains mostly usable. It took about 20 minutes to start all the threads. Occasionally forking a new process takes about a minute and there's sometimes a delay echoing input. Other than that, it seems ok.
I think you misunderstand the ways in which STM are relevant to this sort of issue. Sure you can do full blown STM with crazy commits and rollbacks that are large and complex but that isn't what causes the problems with most threading issues. Really the primary benefit of STM is just to give an understandable and intuitive means to manage simple things that programmers now do with locks, e.g., making sure the other thread doesn't update part of the object while your thread is making some small change to it.
As far as performance the key here is compiler design. Sure in the fully general case STM may be fairly resource intensive but most cases aren't the general case. The hope is that compilers can be improved to natively support STM and recognize where simplifying assumptions can be made.
In other words practical STM is a way to get the compiler to meet the programmer halfway. Compilers can't do auto-parrililization and won't be able to anytime in the foreseeable future but having programmers deal with very low level constructs like locks and semaphores is confusing and a waste of time. This is a nice comprimise to meet in the middle. At least as long as it is used correctly.
If you liked this thought maybe you would find my blog nice too:
> gcc does thread-safe initialization of local static variables -- Visual C++ does not.
3 .html/ 08/85901.aspx
VC++ does do threadsafe static initialization.
You're dead wrong and grandparent is dead-right. References follow.
GCC: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg0229
MSVC: http://blogs.msdn.com/oldnewthing/archive/2004/03
Microsoft's position is that the standard requires their (undesirable) behavior. I guess GCC either disagrees or is providing a language extension. For what it's worth, MSVC doesn't have a great track record on correct standard interpretation. (C++ header file naming bug, for one example...)
> And in any case, gcc runs on windows so it's not exactly a windows issue is it?
gcc runs on everything. Consider it a comparison of the "native" compilers of both OSes.
> Windows has better support for multithreaded apps, it has a far richer set of thread/process synchronisation objects (mutexs, critical sections, semaphores, alertable wait states, events) than unix does.
Now you're just throwing out random terms for multithreaded programming concepts, all of which can be implemented in any OS that provides an API for multithreaded programming. As is typical, the Windows uses a nonstandard, proprietary API, while Linux uses an open standard (the POSIX pthreads library).
Just to make it clear that the Windows API is not "richer", let me point out that you can actually write a wrapper around either API that makes it look like the other, and people have done so.
> Now, as far as 32k 'busy' running threads leaving the machine still responsive... let's just try that out..
Don't be retarded. But since you already were, my sibling poster has responded that this doesn't kill Linux stone-dead, though it does slow it down quite a bit, so you even lose your own retarded benchmark contest. Ouch.
vi ~/.emacs # I'm probably going to Hell for this.
It could run all the software it didn't have with incredible efficiency and make full use of all the hardware it didn't support.
Seriously, it wasn't an OS - it was a tech demo.
Quit pretending that it was ever a viable OS or that it is anything special nowadays. Yeah, yeah, it could run multiple videos at once. But then again we're talking multiple 160x120 videos because that was about as good as video got at that time.
Let's see it running multiple, hi-res Xvid or h264 videos without dropping a frame. If there isn't a multithreaded port of those codecs, or a sufficiently good video driver available in 2007 then it's not a viable OS is it? If it was as well designed as the fanboys always claim then it would have been easy to write drivers and applications for it.
Sure it was a fast OS, but what was really taxing it?
Don't be retarded. But since you already were, my sibling poster has responded that this doesn't kill Linux stone-dead, though it does slow it down quite a bit, so you even lose your own retarded benchmark contest. Ouch.
.
Oh for god's sake. Isn't it quite obvious that I was genuinley interested in discovering how well Linux runs the 32k thread test? I'm not having a 'retarded benchmark contest'
As for the rest of your tirade, Well.... crap. It seems that you're quite right about the static stuff. Looks like I will have to more careful in the future. I was sure I'd seen a mutex or whatever when looking at the implementation of statics. So I apologise about that.
But...
I think that you can still describe the set of windows sync objects as 'richer', even if you can (obviously!) implement one in terms of the other. Windows threading and thread synchronisation API is richer out of the box. You can almost always implement one (richer) API in terms of the another. This means nothing.
And honestly, slashdot people are so mean. I mean! Retarded? How exactly is that sort of language called for? And yes, of course I'm new here.
How can programmers like me (I have only had very limited threading experience, mostly due to the many pitfalls of doing it right - I'm lazy and stupid) get the training and education we desperately need to do multithreading right? Multithreading can never become pervasive, IMO, until everyone is properly educated on it.
So where do I go? What do I need to do? I want to learn this stuff. I need to learn this stuff. And most importantly, I want to do it right.
All of the other code I write is as damn near bug-free as I'm capable - I want to be equally proficient with threading and locking, because until then, I may as well still be in my diapers hacking assembly on a 6502.
I want to be a better programmer, and so far, this is my only roadblock.
grey wolf
LET FORTRAN DIE!
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
"assuming you present a fair characterization of the issue"
I simplified it, partially because I didn't remember all of the details. I think they put handles into thread local memory. So when you use an MFC class in place of a handle, it only works from the Gui thread that created that handle.
No doubt they give some official way to work around the blocks they put in. I know that they have some way of letting users fork a subwindow and give it it's own gui thread, apart from the main gui thread. They made it complicated to implement, but the fact is that if you never do work (other than drawing or managing UI elements) in your gui thread, there's no reason to have more than one gui thread. Anyway multiple gui thread still doesn't solve the problem of allowing you to access a window object or its handles from another thread, gui thread or not.
If you make multiple gui threads the Microsoft way you get subwindows that stop responding when there's work instead of getting a whole ap that blocks on work.
It's better to separate the work in it's own threads - then the whole ap is always responsive. And MS made that harder than they should.
On the other hand, I admit that I never bothered to learn Microsoft's horrible Frankenstein C-code version of Smalltalk's (much cleaner) Model, View, Controller gui model since even Smalltalk's MVC is unnecessarily complicated. In any case, 99.999% of Windows software blocks unnecessarily (even Firefox). So I don't think that Microsoft ever created a work around that works as well as mine does.
Multithreading is important to GUI performance, but not for the reason people think.
For ordinary computer users, CPUs aren't the bottleneck, and they haven't been for a while. It's all about I/O.
Experiencing GUI slowness? Chances are it's one of the following:
- your application stupidly lets its GUI threads block on I/O. your application won't redraw or respond until it gets what it wants from the disk or network.
- your OS is stupidly letting the VM system thrash, madly swapping applications in and out of memory (the sound of this phenomenon is your hard disk churning)
- (least likely) you are truly doing something CPU intensive, like using Google Maps in Safari (which, for whatever reason, is horribly slow. Safari must have a slow JS interpreter or something).
Sadly, I don't see things getting better anytime soon.
I have never heard goatse described so eloquently! I nearly died laughing...
www.purevolume.com/martyd
Those things can be hard. The fastest UI experience I'd had prior to BeOS was the Amiga. It was equally impressive, relative to its contemporary competition. But part of that came from shortcuts: it didn't have a couple little features like memory protection and device independent graphics. The reasons the Amiga died were probably not mostly technical, but those technical problems were not overcome before the Amiga was dead.
BeOS was cool, but denial and closed source is not a valid approach to surmounting huge technical hurdles. Remember, before Apple picked up NeXT, the approach Apple and Apple fanboys took was just that. You'd constantly see Apple fanboys saying things like "preemptive multi-tasking is slower than cooperative, it's completely useless." Microsoft always took almost the same approach publicly: preemptive multitasking, color, video, windowing, graphics acceleration, etc. were all useless fluff. But behind the scenes MS was actually working on them. And then they'd put them on the market and claim to have invented them. During that time Apple was, as far as anybody can tell, jerking off to its own marketing. Nearly a fatal case of denial.
Why is Beos more responsive and in what way?
Does it, for instance, have a model where it wakes up a new thread for each gui message, not waiting for the previous one to finish? That would make even badly written programs responsive, but it would require programmers to put locks on everything and check state on every message.
I am re-posting this as it was moderated offtopic a few months back - it is still to an extent off topic but again I'd like to discuss responsiveness of an operating system and why Windows UI seems so sluggish.
Gents,
I have a relatively simple and odd question.
What's with Vista and XP's UI?
See the thing is, I keep upgrading machines, 1ghz, 2ghz, 3ghz, 3ghz dual core, 512mb, 1gb, 2gb - etc
The user interface is laggy
EVER so slightly laggy but laggy, there's this 'engine' underneath the hood, since the days of 95 (yes 95) where it just feels wrong, it feels like the same code to be honest from version to version?
It's a ridiculous claim, have no doubt, I realise that but god-damnit it just seems that way.
Here's an example
You open a copy of Windows Explorer under Windows 95 with a floppy in the drive, 2 networked drives mapped and a cdrom in the drive.
It pauses for X amount of time, then it kind of starts to move, then suddenly bam it's done.
Do the same thing in XP.
It seems to behave identically - I mean the entire thing feels like the same chunk of code.
I was under the impression 95 / XP and Vista were all very very different under the hood, am I incorrect?
Has the primary 'engine' changed, has the kernel drastically changed but the Explorer UI remained similar?
It's not just opening Explorer, it's the start menu, it's alt tabbing, it's maximising it's the 'feel' - I'm well I'm sick of it!
It feels the same from version to version!
I don't need a slick graphical UI and well in all honesty I don't NEED to learn Mac OSX but the fact it is more responsive in some ways is great, I just want an OS which I feel in control of.
Sorry to make such a vague post but what am I doing wrong? Is there some magical tweaks out there which make Windows behave ultra reliably and snappily?
I know about the tweak ui power tool and I know about changing the figures to 0ms delays but even then things don't feel 'right'
Will a quad core help, I found a dual core did not actually fix many of these problems.
On this note, somewhat on topic (to my post) - I recall the 'bitboys' claiming they were going to release their 'glaze 3d' card with drivers which sync'd windows native 'frame rate' to the refresh rate of a monitor.
It sounds like nothing but it was going to create the illusion of an incredibly smooth scrolling Window for 2D - just moving windows around
Trivial sounding but the end result IMPRESSION of slickness, of responsiveness - no more tearing.
Such a small thing but from an end user perspective it might make things smoother.
Does anyone have any thoughts on this? Any answers or sadly flames?
When oh when, if ever will Microsofts interface and 'back end' truely be something special and new, if ever?
It's the lag of sending all of your clicks and key strokes to homeland security before displaying them.
What do you need a micro-kernel for? Linux is already a multi-threaded kernel, and can already balance said threads between cores. You don't need a micro-kernel for that. Performance could probably be improved, and the granularity of kernel threads might need some work, but there is nothing at all that stops a monolithic kernel from doing those things.
The lines between monolithic and micro kernels are pretty blurry these days. The only remaining big differentiator is that kernel "threads" in a micro kernel are generally more like processes and have hardware-enforced memory separation from the rest of the kernel. Useful for stability, not really relevant or beneficial for performance.
I'll subscribe to Slashdot when I see a month without a dupe, a typo, or an article the "editors" didn't read.
the whole Windows desktop usually locks-up if you have one operation in progress and you try and start another operation, even under Vista. Having a multi-core CPU makes little or no improvement either.
yes
(this is offended to the end of comments you post, 120 chars)
There are many ways to multithread - multitask - parallel process - and distributed process.
Most of them require some heavy lifting and systems programming knowledge. Almost all require at the very least understanding of the processes involved in "fork"ing.
However lately I've been doing some multithreading through - of all languages - PHP. There are two keys to understanding when to do this. First is recognizing what can be processed in parallel. The second is to understand how to wait and regroup for processes once processing needs to be linear again.
Web development is inherently multi/distributed processing. Many developers do it without even thinking about it. For instance if you create a page with frames, you are aggregating content from multiple processes and possibly from multiple servers. The regrouping of the data is all handled by the browser. This is very simplistic because usually there is no further processing done once all *threads* are complete.
Taking this a step further you can design a system that touches multiple scripts at the server level (rather than brower/client) without waiting for them to complete. In PHP you can simply do a:
fclose(fopen("http:/server/script.php", "r"));
This touches script.php and does not wait for data to come back - data is stored by script.php in a common area(filesystem or database for instance.)
In script.php you simply call:
ignore_user_abort(TRUE);
This tells the script to continue running even if the connection has been broken.
If you want to start up 10 parallel threads you would simply do this:
$count=10;
while ($count--) fclose(fopen("http:/server/script.php", "r"));
This works great for processing queues (email retrieval/sending for instance) and data that is loosely coupled. The key is to be able to identify what can be processed in parallel. After that you can just let the webserver and OS take care of forking and system level stuff.
-CF
occam was built explicitely to write parallel programs. I'd like to see it ported to multi-core CPUs.
Engineering is the art of compromise.
Back in the day, I loaded a machine with up with BeOS and OS/2 Warp 4 and tried that very trick. I was expecting OS/2 to stutter but no, it kept pace with BeOS with many movies open and playing at the same time, all the while remaining just as responsive.
I tried a few other similar "benchmarks" and couldn't see what the hype was about. Add to the problem that OS/2 actually had some serious office applications to get some work done (no Gobe wasn't good enough, I tried that too), web-browser on par with everyone else (Mozilla/Seamonkey), it was hard to justify BeOS, no matter how much I wanted to like it. Sure, BeOS was prettier I guess...
The technology was already there, once BeOS left the PowerPC platform, there wasn't any good reason to exist since it basically re-invented the wheel...and didn't do it much better, if at all.
STM isn't just a compiler issue, it's actually a whole other model for synchronisation (though it's part of a large family of lock-free models, such as RCU).
Today, mutexes, condition variables, semaphores and so on are implemented inside the operating system for a very good reason. We want the same for lock-free models.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
After all, they invented the Mazel Tov Cocktail!
(I know, I know.. 'in Soviet Russia, cocktail invents YOU!')
But at too steep a price. The messaging system relied on passing pointers between processes. So if we're both processes and I wanted to send a message to you, I'd build the message in my memory space, and then pass you a pointer to it. Fast, for sure, but it meant a lack of memory protection was a requirement built-in to the OS API. That's a real problem. It's not just a matter of "knowing what you were doing", as you put it. Even ignoring that fact that a great many programmers apparently don't know what they're doing, even the best programmers make mistakes (being human).
The Amiga was a neat platform, and did some really cool things, but let's not get too carried away with our rose-colored glasses. :)
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
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.
"Yeah, but yesterday's supercomputers are todays commodity machines. "
Indeed? Do you know were I can pick up a Cray for the house? And while you're out shopping, can you pick up a connection machine as well? I need a new coffee table.
I think there are deeper problems with GUI responsiveness in Windows than the ones you mentioned in your post.
At work, I have a 3Ghz quad-processor box with 2 GB of memory. The thing screams. I can have two 4-way builds going in two copies of Developer Studio at the same time---it takes 8 compiler processes running at the same time in order to max out the CPU on this thing!
Except, whenever its doing disk accesses (to a 160GB 7200 RPM EIDE drive), it really struggles to do *anything* else. Disabling the corporate-supplied virus scanning software doesn't help.
My frigging MOUSE POINTER will lock up and NOT BE MOVABLE FOR SEVERAL SECONDS when its doing heavy disk access. Linking a 25-megabyte executable will take a couple minutes (up to 10 mins for a debug version with its 100 megabyte symbol file). Task Manager will show CPU utilization under 10%, and yet I can't move my mouse pointer. (Or if I can, then I can click on anything I want and it will take forever for it to activate whatever app I clicked on because idiot Windows swapped it out to *disk* despite me having 2 gigs of RAM).
"Most of them require some heavy lifting and systems programming knowledge. Almost all require at the very least understanding of the processes involved in "fork"ing."
Or group and graph theory, but that's approaching from another angle.
"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."
Then what would have been the point of Palm buying the company in the first place? I know slashdot is unable to see the value in such things (but apparently want it open sourced so there's hope). But others do.
I'll give a simple example of why this may be so:
Run any version of windows on an emulator - a *very* slow one. (A good example is a 486 emulator running on an Amiga 3000 - one that reports itself as being a 486DX4-16.) And I don't mean sluggish, I mean painfully slow.
What you're likely to see when a window is created is this: First, the rectangular border is drawn. Second, the title bar is drawn, but no text filled in. Third, the border is erased and redrawn. Text is filled in in the title bar, then the border again erased and redrawn. When you resize a window, you'll likely get to watch the border get erased, drawn in the new position, the nerased and redrawn while the program begins drawing its window's contents.
The UI is horribly inefficient for several reasons, and I seriously doubt it's been properly fixed before Vista, since 3.0. I truly suspect you'll see similar behavior on the standard UI widgets as well.
(This process was described to me by a friend after he ran Windows on his Amiga's PC emulator. We laughed then, but it made me feel sick inside. Why not just draw it once and be done with it?)
grey wolf
LET FORTRAN DIE!
All I have to say about BeOS is this:
To this day, NO OTHER OS IN EXISTANCE makes installing a tv tuner easier. I threw my v1 Brooktree Video Grappler card into my BeOS (not zeta crap or haiku, true BeOS pe5) and it JUST WORKS. 0 config necessary at all. Linux chokes and confuses the GPIOS. Windows blue screens a dozen times and forces about 4 driver reinstalls before working. OSX won't even talk to it, period. But it's not just the ancient tech. I threw in a much newer Conexant based video card, exact same deal. BeOS just worked first time 0 config. Linux sort of works, in black and white, and after some trickery passed to modprobe. Windows has a spastic fit before eventually working with terrible TERRIBLE frame rates and picture quality. OSX doesn't even attempt to talk to it. Why is it so hard for everyone else to design a video capture subsystem that works so flawlessly? And how the heck did the BeOS guys get it so right that it still works with new hardware designed YEARS after BeOS was shelved?
Seriously, when it comes to TV tuners, nothing at all in the world is even a close second to BeOS. And this looks to be true for a long time yet.
That's not quite what I'm asking. All you're describing is the function of a simple fork().
What I'm interested in is full-blown in-process threading, where I break off parallel sections of (for example) a large C++ framework that operate on shared chunks of data.
I already understand what threads are and how to create them. I just don't understand locking mechanisms. I mean, conceptually, sure, I understand that in one locking model, one thread locks a mutex and other threads will block if they try to lock the same mutex. But I want to understand semaphores and lockless structures on more than a merely conceptual level, and I've found little beyond a few theoretical items or white papers - stuff that was frankly over my head.
I'm simply not interested in implementing this kind of thing in PHP - that's child's play. I've got a project I'm writing in C++ that I want to thread properly. I just don't know how to do it without making a huge mess of things.
grey wolf
LET FORTRAN DIE!
"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?"
First of all - it's not threading itself that is the issue. And the answer is no - Future versions of Windows won't ever be as perfectly smooth as BeOS was/is.
Why? Because of backwards compatibility that's built into each version of Windows.
Even in 32bit versions of Windows Vista, you can take your poorly built 16bit Win 3.11 App that did all sorts of wrong things, and still expect that it'll work just the same as it did on 95, 98, ME, 2000 and XP. Sure, you might need to run with Admin rights, and it won't be able to handle long file names - but still, it'll probably work.
It's precisely this in-built backward compatability that is Windows' biggest strength, and it's biggest weakness. For every version of Windows, Microsoft has to spend vast amounts of time ensuring that apps, where possible, continue to work. Despite large changes to architecture and how things operate.
Sure, MS could say 'screw it' and break compatibility - after all, they did (to a limited extent) with Vista already. But then you're resetting your OS's application base back to (practically) zero. Oh, and don't forget drivers - they're important too. As anyone who jumped on the early Vista builds and noticed their graphics card ran like crap will tell you.
I'll probably get flamed for this next bit, but Linux and (to some extent Mac OS) developers are more willing to break things between OS versions. So, running an older version of some app on a newer version of the OS is more likely to break. The trade off is that apps on Linux are more likely to be open source, so at least someone can update it to fix whatever the issue was.
- Will.
(Who writes Windows "Business Software" for a living and has absolutely no issue spinning up threads on a server backend as needed to process data. Just don't mention the UI.)
beos was released before even mac os 8.0, with the proprietary BeBox before they admitted failure of their platform (powerpc based) and ported the os to run on macs, and then eventually, x86.
every BeBox came with at least two processors, along with hardware-implemented processor usage meters on the front. these meters were amazingly responsive with no latency or cpu usage and a sampling timeslice of like a tenth of a second or so. (fast enough to wow the eye but slow enough to still show short processing bursts or smaller workloads as such instead of quick flickering spikes) the dancing lights were the tipping factor for more than one nerd! (obviously not enough though)
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.
I hope he joins wikipedia as a writer. Deaf people, with the aid of a speech synthesizer can finally understand what the whole goatse thing is all about.
-- Using the preview button since 2005
Let me know how long it takes to start OpenOffice on BeOS.
A little bit oblique there, but look at the example set by Parallels on MacOS X - it is entirely practical to run a complete virtual machine inside an OS, and have seamless access to the applications within.
Maybe it isn't possible to make a BeOS out of Windows, but that simply doesn't matter. An OS should be built from the ground up to learn all the lessons of the past, and implement all the advanced features required, with backwards compatibility entirely handled by virtual machine trickery.
Vista would have been so much less of a pig's ear if they had ditched the half-baked, broken, attempt to remain compatible with XP, et al, and left running old applications to a virtual machine running a complete XP environment (a la Parallels).
lol, deaf people?
you meant 'blind' people!
Thank you.
Exactly the kind of response I was looking for, I'd be willing to bet Vista does exactly the same thing as 95 does in regards to that kind of thing.
It's like there's a piece of code that's been sitting around for 15 years that is 'good enough, let's keep it!'... not good.
You got me there. In my defence I was posting before 9am.
-- Using the preview button since 2005
One which DragonflyBSD is taking up.
About the 32k threads, read this.
Parent comment was insightful; probably the most insightful comment here about BeOS. Not funny.
BeOS looked nice, but it never did much that even pushed a system never mind actually letting you get work done, so it's hard to tell.
Didn't Palm Source buy BeOS, and claim to be releasing their next generation of PalmOS based on BeOS?
That was years ago, and obviously never happened. But, did any part of BeOS make it into a Palm product?
Is there anything left of BeOS, any chance of some life for that codebase?
Do you like greco-roman wrestling?
You open a copy of Windows Explorer under Windows 95 with a floppy in the drive, 2 networked drives mapped and a cdrom in the drive...
For whatever reason, Windows has an obsession with not displaying ANYTHING until it can spin up the CD-ROM drive. I absolutely hate this "feature," and I really wish someone would create a way to turn it off, because there's no reason I should need to wait 5 seconds for the CD to spin up before I can choose a location to SAVE a file.
I went to one of the BeOS traveling road shows, in Ann Arbor MI, way back when. I was blown away by it.. it was way beyond anything else at the time. I didn't buy a BeBox, but I did get BeOS when it was available for Intel boxes. It's a real shame for that codebase to be lost for practical use.
The same thing almost happened to NeXTStep. They were bleeding money, and not making much progress in the market. If Apple hadn't screwed up so many of their efforts at creating their next-gen OS, NeXTStep surely would have died. (Of course, Apple almost chose BeOS anyway. And, NeXT had some open-ness in OpenStep).
But, it just makes me wonder, what would it take for a competitor OS to make it? MS can suffocate any commercial competitor. But, one as advanced as BeOS surely would have lived on if they were Open Sourced. There would have been many people interested in developing the OS or apps for it. But, then again, without a core organization providing direction, the project would probably run off into the weeds - lacking a customer/usability orientation like 95% of all open source projects.
That's a pet peeve of mine. Ha-i-ku is three syllables.
There's a sign hanging in the restroom here at work, and I just realized it was a haiku.
Isogutomo
kokoro shizukani
te wo soete
soto ni kobosuna
-Matsutake no Tsuyu
Even when hurried
Quiet your heart
Steady with your hand
And don't spill any on the outside
-Mushroom Dew
Beautiful, isn't it? The English version just says, "We aim to please, so please aim."
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
Back when BeOS was still cool, and Rhapsody was hot, and NT was still counting by numbers instead of names, I installed BeOS, Rhapsody DR1, and NT 4 on the same hardware... a Pentium with 16MB of RAM... not exactly state of the art but not ridiculous for the time either.
BeOS showed no exceptional capabilities. Both Rhapsody and NT were easily able to run multiple concurrent applications without slowdown, and BeOS was at least as often bottlenecked on I/O.
BeOS was certainly a competent OS design, but the "remarkable" performance was only remarkable when it was compared with the classic Mac OS and mainstream Windows 9x. With those as the "competition", the legend of BeOS has grown over the years, but any contemporary preemptive multitasking OS could do as well.
if i remember correctly, you could do a forbid() that'd stop all the multitasking, or at least give your task the priority. there were some reasons for using it. though off the top of my head i can't think of any legitimate ones.
Some apps, mostly Adobe, seem like they do it on OS X too. Every time I open/save a new file, Photoshop waits for my two external firewire drives to spin up. Ugh.
Vote for global prefs bug
I think that the nearest candidate would be the Atari ST.
Beef
Totally, what bugs me is it's been like this for over 10 years, what on earth?
There have been examples in other postings about BeOS and its "eight movies at once" performance. If you play eight movies at once under Windows or OS X, they're *already* each in a separate thread. Windows Explorer and OS X Finder are also multhithreaded to some extent, so you can start a big search across your whole drive and not bring the system to a halt.
It feels like the original question is "When will systems feel as responsive as I expect them to be?" but it was phrased as a question about multithreading. In reality, there are processes and threads like crazy under all modern operating systems, but that doesn't always translate to "responsive." I've seen cases where there's a 10 second delay between pressing Windows+E and a new explorer window popping up. That's significantly slower than requesting a list of files on an ftp server halfway around the globe. Multithreading isn't going to fix this.
-- OpenVerse Visual Chat: http://openverse.com
In fairness back to you, if you haven't listened to the mp3 song on goatse, you're missing half the joke.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
The ST ran GEM (which was also available on the PC). It did not come close.
The hardware did have many similarities...however, this discussion isn't really about the hardware.
-- OpenVerse Visual Chat: http://openverse.com
OMG Pervasive Multithreading like NT/2K/XP/Vista?
/. world really NOT KNOW that Windows 2000, XP, Vista all have prevasive Multi-threading, although it is not as extensive as BeOS?
Do people in the
So ya we need more Pervasive multi-threading in other OSes, and Windows needs to extend the level of pervasive multi-threading that is already in the OS architecture.
Slight problem: operating systems can't detect every memory write or read without turning on debugging interrupts or setting up the page tables so that every access page faults. There's no mechanism in current processor architectures to support STM in an OS.
Yep, I too have been waiting years for them to fix this.
Each new Windows version comes out and I try out windows explorer with a CD... same old s**t.
However, at some point they DID multi-thread the folders view so that it first shows + for every folder, then later hides them for folders without subfolders. Probably XP. Windows 2000 still wants to expand everything exactly.
For every expert, there is an equal and opposite expert. - Arthur C. Clarke
Microsoft made their .NET launch with an effort to bring the VB developers into the fold by making things familiar. Because there were a boatload of not-the-most-creative-but-very-numerous VB6 developers out there.
Now, we have a glut of web developers. They are not inclined to find the idea of having multiple servers instead of one intimidating, but rather liberating.
That's what I base my prediction on. That they all categorically won't learn from experience, and that the client-server developers are the ones most likely to thrive in their not learning.
-1 Uncomfortable Truth
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."
Due to a current bug, cannot to uninstall software, such as the relatively unpopular "Iraq Occupation" application.
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.
Fix your own English before you have the audacity to criticize other's use of the language, moron.
Ha ha, that is bloody priceless. Thanks, never knew the MP3s.
-- Using the preview button since 2005
I doubt we know who the first woman poet was, but Sappho from the Aegean island of Lesbos, a classical Greek and female as well, was composing poetry long before Rome was an empire. Emily Dickinson is one the first important female American poets and ranked right up there Henry Wadsworth Longfellow by critics.
As far as literacy goes, look up the term "blue-stocking society" in the mid-19th Century. By the 19th it was a pejorative term, but, consider its antecedents. By the 19th c. it was fairly important that women be able to read and write and calculate. They generally managed household accounts, read to and educated children who were not sent to school, including sons, and in some cases managed businesses as well.
------ The only greater hazard to your liberty than n politicians is n+1 politicians.
Well, first, there's the minor detail that the Amiga (as it was) didn't really survive, and that death happened before the Internet hit the big time. Sure, there's a strong enthusiast community that has done an admirable job keeping the platform alive without OEM support, but you can't exactly ignore the collapse of CBM, either. Well, maybe you can, but most people can't. :)
Second, the mechanism the Amiga used for message passing is well-documented. Try these Google searches for some good results:
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Another useful feature was the way that you could keep the menu open by holding down the right mouse button, and then use the left to select multiple items - particularly useful when you have a series of tickboxes you want to select.
I'd love to have that available now, it's tiring having to open a menu (either a window menu or context menu) multiple times.
What you describe is bad design. The right UI design solution is never to put a lot of tickboxes in menus in the first place.
The reason for the single menu bar on the Macintosh has nothing to do with saving screen real estate. Rather, it's an application of Fitt's Law: the corners and edges of the screen are easier and faster targets to acquire with a mouse than objects elsewhere on the screen, mainly because (with appropriate acceleration curves) it's very fast to slam the mouse to a corner and then slide it along the edge. So Apple designed the menu bar to take advantage of this, and located very frequently used menus nearest to the corner.
What you describe is bad design. The right UI design solution is never to put a lot of tickboxes in menus in the first place.
Doesn't have to be a lot, just more than 1.
Where should the options be placed instead?
I've always felt that the main reason Be didn't make it was that there's only room for one significant competitor to Windows, and the market had already chosen Linux. (MacOS was a special case, due to inhabiting a space where Windows couldn't go. It'll be interesting to see if MacOS can survive moving to Intel.)
Drivers (and to some extent the hardware) are the problem.
Not all DRI/DRM modules support multithreading and multiple contexts well.
Probably, using some piece of code that isn't maintained anymore and whose company has went belly up for a long time (like 3DFx video boards) is going to give much worse results than something that is currently being actively developed on (like Intel i9xx intagrated GPU running AIGLX/XGL).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The substantially different kinds of windows are: 1; 2; 3; NT 3.1; NT 3.5[1]; Windows 95, 98, ME; NT 4.0; Windows 2000, Windows XP, Windows 2003; Vista. Windows 1 and 2 are text mode. Windows 3 includes 3.0, 3.1, and 3.11, which are all graphical shells on top of DOS. They offer 32 bit support through Win32s. Windows NT was originally more microkernel-based than it is today; 3.5 did away with that. Windows 95 was new, mostly 32 bit (but with many 16 bit components.) It was enhanced for USB and AGP in some sub-versions; this was rolled nicely into Windows 98 (with some minor shell improvements) which still had many 16 bit executables in the OS. Windows ME did away with the 16 bit stuff, and stopped flipping into real mode like win95 and win98. NT4 did away with some of the memory space segregation (IIRC they merged Kernel and GDI, leaving only Kernel and User) and got Windows 95's shell (it came before 98 but 95 and 98 are definitely essentially the same thing.) So it got better graphics performance, but less stability. It also got support for volumes over 2GB and 3.51 didn't, so 4.0 was around to stay. Win2k is NT5, has a bunch of changes (including a new driver model) and XP and 2003 are the same thing basically. Vista has yet another new driver model and all the new goodies that we know and hate today :)
Now, the answer to your question: Windows 3.x used to put up the window before it had anything to put into it. Windows 95 and later seems to be based around having something to say before saying anything. I'm pretty sure that's about the whole story.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Well, my XP regularly hangs - that is:
* Click with the Mouse - nothing happens.
* Move the Mouse - nothing happens.
* Type on the Keyboard - nothing happens.
* Type Ctrl-Alt-Del - nothing happens.
* Type Shift-Ctrl-Esc - Task manager does not appear.
Especially the last one is bad as the task manager should enable you to kill evil jobs.
Ah, at work especially the (on access) virus checker grinds the system to a hold.
BTW: It it the same for Linux - with one difference - here it is the xfsdump backup utility which grinds the system to a hold. Probably a Priority Inversion [1].
So, NO: neither Windows nor Linux have really good multi tasking.
Martin
[1] http://en.wikipedia.org/wiki/Priority_inversion
The Windows 2000 desktop I us at work locks on me on a regular basis. See my other post:
d =19884803
http://ask.slashdot.org/comments.pl?sid=250527&ci
Martin
I don't run virus checkers on Windows unless I know the machine's going to be exposed to mundanes or other sources of bad karma. They are *all* abominable pieces of crap... this has nothing to do with whether the OS is multi-tasking, multi-threading, preemptive, or anything else... it has to do with the antivirus itself being a bottleneck. Every antivirus software as far as I can tell just traps whatever random API it feels like, and it locksteps all calls to all APIs it traps by blocking them on its "engine"... which is just a fancy "grep" as far as I can tell.
The security problems in Windows that make antivirus so necessary are a real problem with the OS, but that's got very little to do with the original article. BeOS may or may not have ended up with major security problems, I don't know. It might have... it's so easy to integrate applications with the Tracker that it would just take a sufficiently popular webbish application deciding to take advantage of that and screwing up to make it a big problem.
Abuse any system and it WILL break, eventually. BeOS was particularly sensitive to memory shortfalls, for example. It didn't take much paging activity to make it grind to a halt, even right up to the end.
I considered mentioning that, but I figured everyone had heard that one by now. ;) I wouldn't be surprised if screen real estate played into it as well as it was probably more a consideration then. Especially on the Amiga, where the primary resolution was 640x200, you don't want to waste a whole lot of vertical screen space with menus.
-- OpenVerse Visual Chat: http://openverse.com
At U of M they didn't offer any classes in Java, C# had never been heard of by most of the professors and everything was coded in c/c++ on solaris or linux. If you didn't understand C or Verilog you would never survive the CompE program. Now CompSci is different you could be almost a theoretical mathematician or a coder.
Many amiga users used the "MagicMenu" commodity. That moved the menus to "underneath the mouse pointer", the only place closer than the top of the screen by "Fitt's law" ;-).
That is to say, MagicMenu positioned application's menus like a "modern" context-menu, but not acting quite like the travesty that is the modern context menu:
Amiga menus were always context-sensitive - items ghosted and unghosted when they were inapplicable and applicable. But they didn't disappear and reappear though. That meant they never moved position, so you could learn in muscle-memory how to select them quickly, even without looking at the screen after a while. It's little touches like that that made the Amiga GUI, not the Mac's, the closest to perfect of that era.
Right, which is precisely my point. In addition to the point that we don't know what such a mechanism should look like yet.
But I don't think the problem is unsolvable. Importantly, CPUs are transactional at the microarchitecture level, precisely to support parallelism. Some ISAs support LL/SC, which is a very rudimentary kind of transaction. It may only be a matter of time before transactions become more pervasive at the ISA level, at least in research. Imagine, for example, if you supported small basic block-sized transactions which "roll back" if an interrupt occurrs, or if a branch is mispredicted.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Do you remember the last time a research architecture became prevalent in the field? I can't.
-- OpenVerse Visual Chat: http://openverse.com
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.
Well it would be described as this. NT started off with a strong architecture that was not limited by older micro or mono kernel constraints. So NT had a running start of the non Win32 portion of the OS being pervasively multi-threaded.
However as Win32 has evolved and applications like Explorer that are at the heart of what people see as Windows, this 'level' of prevasive multi-threading has not been as consistent as exists in the underlying NT OS architecture.
So in a way you could say it is an oxymoron, but if you define Windows based on the inherent subsystem lines of the OS, it makes sense.
So NT itself it is already there, and Win32/Win64 are partially there with some applications needing a higher level of threading implemented.
The NT core in Vista is highly threaded and even the lower levels of the subsystem are as well, but when you get down to applications like Movie Maker in Vista it is not 'fully' threaded as far as it should be, as it does split off the conversion and processing in threads quite well, but the UI could use more threading so that while it is processing you get more just a progress dialog box.
So yes the OS itself has full pervasive threading, just not all the applicaitons or components of each subsystem do. (The same is true of the BSD and other Subsystems that run alongside the Win32 subsystem.)
And yes the Win32 subsystem thing is confusing to many, as Win32 acts like an independant OS running on the NT architecture, having its own kernel etc that is separate from the other running NT allowed subsystems. But this is also one of the things that earns NT respect with OS theorists, having a unique client/server kernel architecture that hosts subsystem OS concepts easily.
Take Care
Huh? Memory barriers with hardware assists (MMU updating card table structures without software support) have been available for more than a decade in commodity hardware. Any sort of LRU-style demand paging would be useless without them. Moreover, they are almost a prerequisite for handling out of order operations involving (among others) DMA peripherals.
APIs to expose membars and the dirtiness of pages to user code exist in a number of operating systems, and the concept is not too foreign to incorporate into Linux or any similar OS.
STM only requires that readers know for certain that the data they have been operating on is the most recent.
STM's biggest gotcha is that with a frequently-changing dataset and long running computations, lots of work will be wasted, pushing up the concurrent reader count at which STM efficiency surpasses traditional lock-based techniques. It's next-biggest gotchas are the cost of log maintenance and commits.
While being signalled on page dirtiness may allow an earlier abort, it is not strictly necessary.
This explains why there are at least thirty open source STM and composable memory implementations, in several languages.
The thing that makes multi threaded programming so difficult is concurrency control
You DO realize that concurrency models, distributed databases, and other distributed systems research were virtually beaten to death from 1960s,1970s, and 1980s?
I also challenge you to find one application/environment where concurrency control is a major implementation/design issue.
The amount of computing power found in a typical Pentium III computer sitting out and someones curb far exceeds the needs of most users.
Well it was fast until idiots started using Flash to play real-time video. There are other abuses as well...
Soon, I predict that even our interpreted languages will rely on runtime components that are interpreted themselves. And these will show up on webpages!
I remember when Microsoft Office only occupied a few Mb (10) of disk space and ran on systems with 2MB total memory! I can't name any significant advantage the latest version has over the old one (in terms of usuability).
Most interesting! Actually, my only gripe was with "graduating" pervasiveness, as it is, in my understanding, a natural superlative. But thanks for clarifying the pervasiveness of threading in the win-line of OS'es!
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
It depends what you mean by "prevalent", but the Cell Broadband Engine is probably the biggest at the moment.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Dude. Are you intentionally trying to look stupid? It's called Fitt's law. Look it up.
Fullscreen Support actually was in the QuickTime Player for quite some time before they took it out a few years ago. QuickTime itself has pretty much always had fullscreen support, even when Player did not support it.
Yeah, I need a second processor just to run that damn "idle" task. It eats up 90% of my CPU! Seriously though, most of these tasks barely use any CPU at all.
Very funny but...
What happened with Iran/Contra was that Congress prevented the expenditure of US funds directly to support insurgents in Nicaragua. Leaving out my personal view of this being a. an intrusion onto Presidential powers and b. being stupid because the Sandinistas were actively supporting insurgencies in Costa Rica, Honduras and El Salvador, what Ollie North and company were doing was supplying spare parts for US-built weapons that had been given to Iran during the Shah's regime - mostly aircraft such as the F-14 which required US help to maintain. This material was transferred via an Israeli proxy. The proceeds from that were used to fund the Contras.
Your mistake was 'us buying Iranian weapons' which wasn't what happened. We used the Iranians as a money laundering service fundamentally to circumvent Congress.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.