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!
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
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
BeOS was like JFK.
The both got gunned down before we could possibly see any downsides to them.
There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later.
Gentoo Sucks
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.
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.
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
Well, it's not really an OS issue. Sure the OS has to provide some underpinnings so that the programmers can take advantage of it. But I think most of it is already mature enough for applications to use it. Why don't they use what is already there? I mean everybody whines about how unresponsive X is. Until X is rewritten to be multi-threaded, you won't see the UI responsiveness that you see in BeOS. On your typical Linux box, X is the real bottleneck. There is no point in rewriting QT or any UI toolkit until X is fixed. You won't be able to replicate the multiple videos trick unless X is fixed first and then the applications are modified to use multi-threading to its fullest.
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.
I believe that's covered by "There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later."
Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.
Gentoo Sucks
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.
Bah. Today's programmers aren't better or worse than they were ten years ago - they're just distributed differently. Programming video games on a console is an exercise in (frustration) poor tools, worse documentation, highly constrained memory / CPU / IO / bus, multiple threads utilitizing multiple specialized processors, microcode, assembly, etc. Ditto for cell phones. Not so for business applications.
So yes, if you mean "developers of business applications aren't generally hardcore down to the metal programmers," then I'd agree with you. John Carmack and Michael Abrash would be bored out of their skulls working on UI issues for Quicken 2008. And, given their aesthetic sensibilities, they wouldn't necessarily be the best choices (just *try* to balance your checkbook).
But if you mean that great programmers are no longer among us, then I'd say that you should change jobs, because it's more likely that they're simply not around *you*.
The source under a Free Software license is, I should think, a prerequisite to be in the running for "best OS of its time". That's why the Hurd was the best OS of the BeOS era.
It was not. The five hours I spent trying to get a simple modem to work in BeOS, with no OS diagnostics to guide me, and very poor support from BeOS the company, was all the proof I needed that BeOS wasn't all it was hyped up to be. I can understand that Be did not have the resources to support every piece of hardware under ths sun, but I found it inexcusable that their support for diagnostics was so incredibly rudimentary. At the time, with Linux (this was 1999 or so), if I had a problem with some hardware I could either read the source (OK Be could never match this since it was proprietary and closed-source so that's not quite fair), or look at the copious amount of system logging that would generally point to the problem (stuff in dmesg, kernel logs, /var/log/messages, lots of tools and documentation to help me out). With BeOS, I was getting pop-up dialogs that just said stuff like "Error 0xFFFFFFFF occurred", with absolutely no useful information whatsoever. It was impossible for me to diagnose the problem no matter how hard I might try because the operating system just wasn't going to give me enough information to go on.
Also BeOS the company didn't respond at all to my requests for help with this. They provided zero technical support to me. Emails went unanswered.
Maybe BeOS had some nice architecture, but there is more to an OS than its handling of threads - much, much more, and I think that BeOS was not even close to ready for prime time. And the developers clearly had glossed over many aspects of an operating system (such as the aforementioned error diagnostics) to get to the pretty demos that the OS was capable of.
[BSOD]
. , . . , . . [BSOD]
- . [BS0D]
[BSOD]
. . , . [BS0D]
- . [BSOD]
Table-ized A.I.
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.
While C++, assembly and C might no longer be "cool", it definitely teaches people how to write optimal code, how to debug efficiently, understand a wide variety of computing concepts.
The same college today is too busy teaching C# and Java. While those languages are nice and all, not teaching low level C, C++ and assembly IMO leads to sloppy coders, people who don't understand the byte code generated, people who don't mind wasting system resources because hey
I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed.
X is being fixed, thankfully (finally). There are a lot of interesting projects, including but not limited to Xegl. Xegl, is the long term goal of the X server and pretty much reduces the X server to a tiny part of the system, basically mediating the input devices, rotation and display management and TCP/over-the-wire GL, if I understand correctly, by using the Embedded GL specifications.
This is a multithreaded comment, 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.
"I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed"
Was it more cost effective to have a programmer recode it in C (which includes the required maintenance) or use the less optimal but easier to maintain VB COM? I'm all for using C over C#, Java, and VB, but sometimes you need to look at the situation from a business standpoint.
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.
Programming languages like Haskell and Erlang has very little problems with using a massive amounts of CPUs/cores. Look them up and learn about them, and you'll see that they can, without any fuss, spread over many many threads without any special code at all.
Well, that's it, read up and then maybe we can get some more interesting Slashdot postings about new computers:)
And it is quite amazing that Sun hasn't picked up on this. Their little Java thingie doesn't scale that well after all:)
I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version.
His reaction likely had little to do with code and alot to do with business. To managment's ears you said "This part is done, but I want to take time and money and re-do it really shiny." Now if craftsmanship meant anything in terms of the sales of software, you may have been listened to. But since the hardware companies are all too quick to step up and offer a new gizmo that will have you computer running "blazing fast", the consumer thinks that the sluggish performance is a hardware problem. The end result of all of this is the management of software companies sees little to no reason to take any more time or money than necessary to make a program clean and efficient.
We are all just people.
Apple are adding the NSOperation and NSOperationQueue in Leopard to help with creating multithreaded applications. There's no public documentation on these yet, but based on what has been told in public it seems that it's mainly a worker thread API.
This is good, I like this political stuff:
MS-DOS 1.0 was Herbert Hoover, aloof to the problems of the common man but friend of the engineer in all of us. Also discovered Transformers.
Mac OS 7-8-9, all Franklin Roosevelt, very competent, lead us through difficult times, but left a legacy of programs which have become quite a mixed bag.
Windows 3.1, Dwight Eisenhower, amiable enough, competent, but leaving historians (and many contemporaries) very wanting.
Windows 95 thru ME, Lyndon Johnson, one of the boys, very able at getting things done, but in the end a disaster, rightfully ceding his throne.
Windows NT, Richard Nixon, the archetypal back-room politician, ruthless, and ultimately brought down by little faults, but many believe he was a great president and did much to modernize the Republican Party.
Windows XP, Ronald Reagan, everybody who hates him never met him, he could charm anyone, the Great Communicator. Bought Iranian weapons for contras with drug money.
Mac OS X, Bill Clinton, cheerful and smart, if not the most productive. Known for his speeches.
Don't blame me, I voted for Baltar.
I believe the mere fact he mentioned the HURD is sufficient proof that he was not being serious.
Vista, George W. Bush, elected because of his name, even though the prior iteration wasn't especially respected or well-liked. Introduced instability and performance issues, all in the name of "security". Many of the corporate interests who promoted him early on are having second thoughts.
IBM made a decision in 1980 to go with the Intel 8088 (8/16 bit) processor instead of the Motorola 68000 (16/32 bit) processor. At the time, the Motorola processor was designed to be the processor of the future. On the other hand, the 8088 was intended to be almost compatible with 8080A assembly code. This created the need for the 8088 segmented architecture, and segments suck.
The use of segment registers set PC development back over a decade. Essentially, all the 80's was spent fighting segmentation wars. The IBM PC didn't get proper 32-bit computing until the widespread popularity of 386 PC hardware in about 1992, and the subsequent introduction of Windows 95. Windows XP was the first unified 32-bit Microsoft O/S in 2001. DOS mode was finally eliminated in Windows Vista in 2007!!! I think you had to live through segmentation and far pointers to understand how incredibly awful they were.
Interestingly, the Apple Mac had a 68000 processor in 1984. If that caught on, then it would have saved the PC industry a decade of pain. Apple made the decision not to license the operating system for the Apple Mac. The result was Apple hardware was expensive, so few purchased it. The problem was so severe that Apple almost went bankrupt before Steve Jobs returned.
IBM built Microsoft and Intel when they created the IBM PC. Apple rested on the laurels of a better architecture and almost went bankrupt. These two decisions defined at least 15 years of software history. It isn't until know where we see a few different pure 32-bit operating systems fighting it out on a common hardware platform. The Windows XP, Vista, OS/X, Linux battles will be interesting. The 32/64 bit battles will take place on PC hardware that is still almost completely assembly language compatible with the first widely used 8-bit Intel Microprocessor: the 8080A!
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.
> When I was a university, I had classes in.. assembler, Pascal, Concurrent Euclid, Simula, Prolog and C
... eye-opening ... computer-related experience I have ever had. It was the first time I REALLY "got it" -- and understood EVERYTHING that was happening under the hood as a system of disjoint events, acting together in concert.
Concurrent Euclid? Dude, where did you go to school? U of T? In the 80s?
I had the distinct pleasure of having Jim Cordy as a prof when I was an undergrad in the 90s. In particular, studying compilers with the man was the single most
Actually, thinking back to the days reminds me of a funny story I haven't thought about in about a decade. I was taking first year computer science. There was a fellow in my class, smart guy, good C coder.. couldn't see the forest for the trees. In fact, he still owes me a pair of Sony headphones he borrowed about a thousand years ago. Anyhow. He stood up in class one day and asked Cordy something like "What kind of an IDIOT would design a language like TURING?".. "Well, Mr xxx... that idiot would be me".
Haha hahaha
I kind of miss being in school.
But I don't miss stats.
I do miss forging usenet control messages.
Too bad you can't do that any more. Kids are missing so much nowadays!
Do daemons dream of electric sleep()?
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:
I disagree with the premise that there wasn't acceptable justification for rewriting things from the ground up. Remember that the key players at Be were Jean-Louis Gasse (sorry for the lack of grave or accent or whatever the French thing is...) and Steve Sakoman. Their primary prior experience was at Apple. The biggest mistake that they made was in trying to create a better Mac OS than Mac OS. What they ended up doing was creating something that looked more like a better UNIX than UNIX, except that it lacked all the things that made UNIX great in the first place. To start with, the biggest thing they left out of BeOS was multi-user capability. That, IMO, more than anything else was what led to the downfall of Be.
I lost a bit of change on Be stock. It still pisses me off, because Be had the nucleus of a great idea, but failed to follow through.
Utimately it's a version of #1. The Gui blocks if you make the mistake of doing work in the Gui thread!
I've made work around classes to fix that so that it's only a few key strokes in C++ to chain (ie call) a routine that doesn't run in the current (GUI) thread, it runs in a work thread, and to chain back to a completion routine in the gui when its finished.
It works like a charm, and programs can be completely responsive 100% of the time, like BEOS, I suppose. You can be loading a file, and still the menu works and you can move around the subwindows and edit them... And if a window is recalculating, it's still responsive during that - and it redraws the new data, when done.
You have to specifically decide what the program can do and not do while it's calculating, and code that. So there is more work in keeping a program responsive. You have to code for responsiveness.
I think Windows 2000 would be Reagan for the reasons you pointed out. Windows XP would be George H. W. Bush for following in the footsteps of its predecessor while having a couple accomplishments of its own (Persian Gulf War). Vista would be George W. Bush--trying desperately to follow in the footsteps of its predecessors, security-obsessed, but overall a miserable failure with dire consequences for privacy and freedom.
In Repressive Burma, it's not just your connection that dies. slashdot.org/comments.pl?sid=314547&cid=20819199
I realize that I may be treading on shaky NDA ground, but I can say that Leopard makes some serious advances in this respect. I don't know if QuickTime and AppKit are fully multi-threaded yet -- but I can say that they seem to be a hell of a lot closer than in Tiger. Also, xnu has had a HUGE amount of work put into it in an effort to reduce locking situations, and it seems to have paid off -- a lot of stuff that would cause a UI hang in Tiger is no longer an issue in Leopard. It also seems that CoreVideo/CoreAnimation have been written with SMP situations in mind.
That's about all I can say without the black helicopters descending on^NO CARRIER
The real litigious bastards...
Wow. You seem awful sure of the future. Can I borrow your crystal ball? I'd like to look up next week's lottery numbers...
Looking at history, the computer industry seems to show a remarkable propensity to not learn from experience, and instead keep making the same mistakes over and over again (with different names). What evidence do you have that suggests that is going to change?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Given that you actually suggested rewriting in C instead of Python or something similar, I think your boss made the right call.
To be blunt: writing VB business apps in C is usually a stupid idea. Business app requirements change often and usually for nontechnical reasons. C is a low level language. But for business apps you'd only need to manipulate stuff at the "Lego level", not the "molecular level". So why use it?
It's near impossible for a normal company to hire programmers who can _rapidly_ write reasonably bug free C and maintain it AND _WILL_ do so.
And it usually takes a lot longer to get a new C program to decent standards than say a Python/Perl/Ruby program.
Getting a faster machine to run app = $$.
Weeks of programmer coding, testing and debugging = $$$$
Weeks of programmer NOT being able to do other stuff because busy rewriting old stuff = $$$$$$ - $$$$$$$$
Assuming a reasonable programmer ability, if you used a higher level language, changes would usually be done faster and with a better chance of correctness.
So my suggestion for most stuff nowadays is:
1) Use a high level language. Usually the performance bottlenecks for a business app are not due to the language but the architecture and design, or just plain IO.
2) Spend a lot of time designing it right with the future in mind - getting time and resources to rewrite in a business environment is rare - so if you do it right you maximize the lifespan of your software before cruft builds up to extremely annoying or even dangerous levels.
3) Leave the low level stuff to the John Carmacks.
So what if those high level languages are 20x slower than C? Unless totally braindead they are a _CONSTANT_FACTOR_ slower, so if they are fast enough NOW, then that's good enough. In 3-5 years time, even if the performance requirements may go up, new hardware is likely to run the programs at least 2-3X faster, and it's probably about time to replace the hardware as part of a preventative measure. If you are lucky and wise and your architecture can scale OUT instead of UP then that's a good situation to be in.
Let me know how long it takes to start OpenOffice on BeOS.
Apple spoke about multithreading in last year's WWDC "Mac OS X State of the Union" session. Apple provided a recording of that session (among two others) for free though iTunes. Since they're free, I uploaded a short clip. Once Veoh encoded that video, it will be available at http://www.veoh.com/videos/v801272G85gFFER.
Linux, Fidel Castro, the communist leader that has been in office for ages, just refuses to resign or die and points nukes at Windows from time to time.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
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.
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."
You learn it the way any programmer learns it.
1) Look for a job/project you want to do
2) Lie and claim you can do it, and commit to doing it
3) Learn the hard way how to do it. Because you committed to doing it, you can't quit when you get stuck and hate it.
4) Do just a good enough job to impress the people that asked you to do it
5) Do another project, this time doing it the right way (or at least better).
6) Repeat until virtually no one knows much more than you on the topic.
7) Profit!
Does it hurt to hear them lying? Was this the only world you had?
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.
Speaking of tech demos, the "book" demo where you put four quicktime movies on the pages of a book and flipped the pages with the mouse, did you ever see that? On a 66MHz BeBox (dual 603e, hardly a speed demon) you could have four 320x240 (biotch!) videos playing on this book. Well, you could only see two at first. But then you flip the page around as you like with the mouse and you can see (part of) four videos playing at once. And the whole thing was quite smooth. The framerate would sometimes degrade but the page still moved smoothly and the rest of the OS was still responsive.
That was the one that really impressed me. They obviously really cared about responsiveness in a way that no one else seems to.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"