Slashdot Mirror
Multicore Requires OS Rework, Windows Expert Says
alphadogg writes "With chip makers continuing to increase the number of cores they include on each new generation of their processors, perhaps it's time to rethink the basic architecture of today's operating systems, suggested Dave Probert, a kernel architect within the Windows core operating systems division at Microsoft. The current approach to harnessing the power of multicore processors is complicated and not entirely successful, he argued. The key may not be in throwing more energy into refining techniques such as parallel programming, but rather rethinking the basic abstractions that make up the operating systems model. Today's computers don't get enough performance out of their multicore chips, Probert said. 'Why should you ever, with all this parallel hardware, ever be waiting for your computer?' he asked. Probert made his presentation at the University of Illinois at Urbana-Champaign's Universal Parallel Computing Research Center."
Oh please, this has been coming for years now. Why has it taken so long for the OS designers to get with the program? We've had multi-CPU servers for literally decades.
'Why should you ever, with all this parallel hardware, ever be waiting for your computer?'
Because I/O is always going to be slow.
Sent from my PDP-11
Why should you ever, with all this parallel hardware, ever be waiting for your computer?' he asked.
Because it might be waiting for I/O.
...I do a lot more waiting on my XP machine than on my Mac. Almost identical hardware, but when I'm opening an XLS file, Outlook and Word grind to a halt on the PC. Sometimes, closing a window locks up the whole system for 30 seconds. Shutting down takes an eternity, but the only thing worse than that is how slow the system gets after I leave it running for more than 4 days straight.
My Mac, on the other hand, can stay running for months at a time, and maybe once a month I have to force quit an application. But even then, it's to access that application, not anything else.
The CB App. What's your 20?
FOR IO.
DON'T LAND THERE.
The problem is that most (if not all) peripheral hardware is not parallel in many senses. Hardware in today's computers is serial: You access one device, then another, then another. There are some cases (such as a few good emulators) which use muti-threaded emulation (sound in one thread, graphics in another) but fundamentally the biggest performance kill is the final IRQs that get called to process data. The structure of modern day computers must change to take advantage of multicore systems.
is Probertly right.
Isn't this the reason for Apple to have rolled out GrandCentral in Snow Leopard? If so, it seems it's not THAT hard to do - at least not that hard for a non-Windows OS.
I dunno - maybe because optimal multiprocessor scheduling is an NP-complete problem? Or because concurrent computations require coordination at certain points, which is an issue that doesn't exist with single-threaded systems, and it's therefore wishful thinking to assume you'll get linear scaling as you add more cores?
...the implementation sucks.
Why for example does Windows Explorer decide to freeze ALL network connections when a single URN isn't quickly resolved? Why is it that when my USB drive wakes up, all explorer windows freeze? If you are trying to tell me there's no way using the current abstractions to implement this I say you're mad. For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem is. You're left piecing together what has and hasn't been moved. File requests make up a good deal of what we're waiting for. It's not the bus or the drives that are usually the limitation. It's the shitty coding. I can live with a hit at startup. I can live with delays if I have to eat into swap. But I'm sick and tired of basic functionality being missing or broken.
These posts express my own personal views, not those of my employer
You wait because some programmer thought it was more important to have animated menus than a fast algorithm. You wait because someone was told "computers have lots of disk space." You wait because the engineers never tested their database on a large enough scale. You wait because programmers today are taught to write everything themselves, and to simply expect new hardware to make their mistakes irrelevant.
You do not have a moral or legal right to do absolutely anything you want.
Fist post!
I come to /. to read tech news... not so see people fisting.
Interesting.
Here you go: R r
Copy & paste as needed.
You do not have a moral or legal right to do absolutely anything you want.
Seems like you've come to the wrong place.
It's called Grand Central Dispatch.
Microsoft should go back and read some of the literature on parallel computing from 20-30 years ago. Machines with many cores are nothing new. And Microsoft could have designed for it if they hadn't been busy re-implementing a bloated version of VMS.
>For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem is...
Agreed, I can't believe that's still a problem in Win7.
However, you can get around it by just using the built-in RoboCopy instead of Explorer in situations where this is a potential problem. I'm sure there are also 3rd party GUI extensions that do the same thing but RoboCopy is good enough.
This is a very weak talk to give at a University. Rather than talking about 'parallel programming' and adding an "It Sucks" button., I would expect a discussion on CSP http://en.wikipedia.org/wiki/Communicating_sequential_processes or perhaps real time hard to guarantee responsiveness. This is the indoctrination you get when you work for Microsoft, you start spruiking low-level marketing jumbo-jumbo to a very technical audience.
... for NFS to give up on a disconnected server... By the original design and the continuing default settings, the stuck processes are neither killable nor interruptible. You can reboot the whole system, but you can't kill one process.
Hurray for the OS designers!
In Soviet Washington the swamp drains you.
With computers past and present -- Atari 8-bit, Atari ST, iPhone -- with "instant on", why does Windows not have this yet? This goes back to the lost decade. What has Microsoft been doing since XP was released?
I'm not an OS designer, so I'll admit to possibly being wrong.
Doesn't a microkernel split parts of the kernel into individual processes? In the case of a multicore system, different parts of the OS can be running on different cores at the same time. So inserting a CD doesn't cause the display to freeze, since each are running on a different core.
Windows explorer sucks. It always just abandons copies after a fail - even if you're moving thousands of files over a network. Yes, you're left wondering which files did/didn't make it. It's actually easier to sometimes copy all the files you want to shift locally, then move the copy, so that you can resume after a fail. It's laughable you have to do this, however.
But it's not a concurrency issue, and neither, really, are the first 2 problems you mention. They're also down to Windows Explorer sucking.
I come to /. to read tech news... not so see people fisting.
Well, I came here to see the fisting. And frankly, so far this site has been a real disappointment.
I don't care if it's 90,000 hectares. That lake was not my doing.
The largest single system image I'm aware of runs Linux on a 4096 processor SGI machine with 17TB RAM. Maybe He means that Windows needs rework?
Can You Say Linux? I Knew That You Could.
The Problem with Threads (UC Berkeley's Prof Edward Lee)
How to Solve the Parallel Programming Crisis
Half a Century of Crappy Computing
The computer industry will have to wake up to reality sooner or later. We must reinvent the computer; there is no getting around this. The old paradigms from the 20th century do not work anymore because they were not designed for parallel processing.
For Windows 2K/XP You can use SuperCopier (http://supercopier.sfxteam.org/) It replaces the standard copy/move dialog with its own; supports pause/resume; can recover from most failures gracefully; not too bad.
Doesn't support x64 but.
Edit: Support is now there for Vista/7 and X64
Often times Explorer will hang while waiting for I/O over the network to complete. Usually when I accidentally drag some files briefly over a folder symlinked to a network folder. Other times when I'm just scrolling down a list of folders on a remote machine I get lots of hitching. The drives are slow but this is really no excuse for the poor performance on THIS machine. This is Windows 7 btw.
Power users use robocopy.exe to copy lots of files. Shows you progress without taking 5 minutes beforehand to count all the files first, automatically retries failed transfers, control over files to transfer or not based on name/size/date/etc criteria, support to sync or mirror folders, etc.
That's called transaction and is a good thing (except the part where it doesn't tell exactly why it failed). I'd hate if it would not behave like that.
BeOS was working on this well before multicore CPUs were the norm on the desktop and the level of responsiveness they managed on hardware that is stone-age tech by today's standard was extremely impressive. Haiku will be picking up where BeOS left off, but it's got a lot of catching up to do on the details, big and small, to become an everyday user's system.
Yet another innovative player that Microsoft extinguished, and the whole tech world is worse off because of it. :(
Do what thou wilt shall be the whole of the Law
Why should you ever, with all this parallel hardware, ever be waiting for your computer?'
For a lot of problems, for the same reason that some guy who just married 8 brides will still have to wait for his baby.
I find Teracopy to be an excellent Windows copy dialog replacement. Gives you per-file and per-batch progress bars, better filename collision options, and a status list. Good from XP through to Win7.
( Redundancy is ) ^ n
A big problem is the event-driven model of most user interfaces. Almost anything that needs to be done is placed on a serial event queue, which is then processed one event at a time. This prevents race conditions within the GUI, but at a high cost. Both the Mac and Windows started that way, and to a considerable extent, they still work that way. So any event which takes more time than expected stalls the whole event queue. There are attempts to fix this by having "background" processing for events known to be slow, but you have to know which ones are going to be slow in advance. Intermittently slow operations, like an DNS lookup or something which infrequently requires disk I/O, tend to be bottlenecks.
Most languages still handle concurrency very badly. C and C++ are clueless about concurrency. Java and C# know a little about it. Erlang and Go take it more seriously, but are intended for server-side processing. So GUI programmers don't get much help from the language.
In particular, in C and C++, there's locking, but there's no way within the language to even talk about which locks protect which data. Thus, concurrency can't be analyzed automatically. This has become a huge mess in C/C++, as more attributes ("mutable", "volatile", per-thread storage, etc.) have been bolted on to give some hints to the compiler. There's still race condition trouble between compilers and CPUs with long look-ahead and programs with heavy concurrency.
We need better hard-compiled languages that don't punt on concurrency issues. C++ could potentially have been fixed, but the C++ committee is in denial about the problem; they're still in template la-la land, adding features few need and fewer will use correctly, rather than trying to do something about reliability issues. C# is only slightly better; Microsoft Research did some work on "Polyphonic C#", but nobody seems to use that. Yes, there are lots of obscure academic languages that address concurrency. Few are used in the real world.
Game programmers have more of a clue in this area. They're used to designing software that has to keep the GUI not only updated but visually consistent, even if there are delays in getting data from some external source. Game developers think a lot about systems which look consistent at all times, and come gracefully into synchronization with outside data sources as the data catches up. Modern MMORPGs do far better at handling lag than browsers do. Game developers, though, assume they own most of the available compute resources; they're not trying to minimize CPU consumption so that other work can run. (Nor do they worry too much about not running down the battery, the other big constraint today.)
Incidentally, modern tools for hardware design know far more about timing and concurrency than anything in the programming world. It's quite possible to deal with concurrency effectively. But you pay $100,000 per year per seat for the software tools used in modern CPU design.
I wish I could mod you higher than +5, you just summed up some of the things that bother me most about the OS that is somehow still the most popular desktop OS in the world.
.
To anyone using Windows (XP, Vista or 7) right now, go ahead and open up an Explorer window, and type in ftp:// followed by any url.
Even when it's a name that obviously won't resolve, or an ip of your very own local network of a machine that just doesn't exist, this'll hang your Explorer window for a couple of solid seconds. If you're a truly patient person, try doing that with a name that does resolve, like ftp://microsoft.com . Better yet, try stopping it.... say goodbye to your explorer.exe
This is one of the worst user experiences possible, all for a mundane task like using ftp. And this has been present in Windows for what, a decade?
+1 Funny Signature
AAH you must be using Vista (the disfunctioal redneck of operating systems). Some of this was actually fixed (gasp) in Windows 7. I'm still amazed that stuff actually works. For example, If you use the search panel at the bottom of the start menu it actually finds the program you want without going through a bunch of useless menu's. This is especially helpful to me as I support a bunch of end users that don't know their computer. If you get a 404 error sometimes the "diagnose" button actually will restore your connection. I've even seen it recover from a 169. ip address (kiss of death for tech support). Anyway, get Win 7 and you'll be happy.
"We are just a war away from Amerikastan. When god vs god the undoing of man." Dave Mustaine
Larry McVoy argued for a pretty fundamental shift about 7 years ago. Think what you will of the guy and his company, I'm just saying...
Sadly, I can not find a link right now.
The real reason behind the problem is that the way a computer operates is totally inappropriate for parallelism. The concept of data moving through a bus to a proccessing core is totally at odds with parallelism.
We do see tremendous parallelism around us. Why? Because, in the real world, there is no bus to move the data over, and there is no central core! In the real world, each object is its own cpu! If reality was like a computer, all objects would have to be moved to a special place in order to be processed!
If we could take a hint from nature...in our bodies, it's not data that are moved around, it's commands that travel on our "buses", i.e. our nervous system!
....for those buying Windows 7.
As is this not an admittance of Microsoft continued failure to properly support the hardware it runs on?
I joke at work that the reason I have to select tools twice sometimes in autocad is because the dual processors are figuring the other processor is doing it, but when I pick the tool twice, they run out of excuses and do it...mostly.
Now I know ....its not a joke....
For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem is.
You can as of Vista.
Plan 9 was designed around the idea of completely separate processes that could be running on separate CPUs. Why not start there?
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
I use it sometimes, but usually I can't be bothered. I'd like that functionality without having to use the command line (especially seeing as I'm usually using it to copy deep within one mapped drive to another). Also, I seem to often be on old boxes which don't have NT4 service pack 3 with NT utilities v3 sp2 or wherever the hell it was hidden before it became easier to find.
So programmers were dumb for designing an OS that was built around existing hardware and still meets the needs of most software users? Wow that was really dumb of them to design an OS that would be have been useless then and only useful to about 1% of the population today. For consumer multitasking a dual core and Windows 7 is plenty responsive. The gains from this theoretical OS would be imperceptible to most.
No, it's not a transaction (it doesn't tidy up after a fail) - just regular shitty Windows behaviour when a file copy fails to complete. You must never use Windows or you'd not have posted that comment (although I suppose you might be one of the lucky ones who've never had a copy fail because of a lack of disk space, transient network failure etc).
The article is about gaining even greater power from multicore systems by redesigning the OS.
UI responsiveness issues have more to do with crappy software and flawed legacy windows APIs (ahhmm DDE) waiting for I/Os from network, naming services, disk drives..etc. It really has nothing to do with CPU limited activities or SMP aware operations in your typical desktop workstation.
If you want your home PC to be faster your best bang for the money is to purchase more memory not faster disk drives or faster processors.
WRT HPC at some point SMP simply does not scale because of memory/cache coherency requirements...kernel codes of insert your favorite operating system here can't work around fundemental lack of available memory bandwidth.
Thats why we have NUMA and believe it or not windows supports NUMA. Unfortunately if you thought writing SMP applications was difficult when you have to consider the locality of memory you access in your algorithms things really start to suck quick.
The only solution that I know of is to have smart programming languages which auto-parallelize and auto-optimize codes because people hate doing such things themselves.
One of the problems is how they implement concurrency. One approach is to have multiple threads of execution and some common area used to synchronize all these threads. Because it would lead to havoc if any thread could write to the common area, there's a locking system in place. Think of it like a key that you hang on a door. When you need to enter the room, you unlock the door then take the key with you. When you're done, you hang the key back on the door. If you don't do it right you can have a queue form outside the door.
What happens in many cases is that a single thread is locking that common area. The system hangs while that common area is locked. In many cases this happens because of I/O. If your I/O subsystem cannot properly keep up with multiple requests you can have major bottlenecks. Now, you certainly don't want writes and reads to occur in the wrong order so you make sure that any process that needs to perform I/O is essentially serialized. Sometimes the OS has no control over it. Maybe it's sending out requests to a piece of hardware and the hardware is just taking a long time.
But we certainly should rethink how we do certain things. Databases figured out certain ways to maintain consistency and maintain performance (in most cases). Maybe we need to approach filesystems as a big database (and there have been attempts before to do this). Imagine a filesystem containing millions of separate files. In a traditional filesystem this can cause performance nightmares, but any reasonably modern database can handle millions of rows with ease. An 'ls' in such a filesystem might use a select. A 'find . -name "foo.*.bar"' would just be a select. Underneath this, multiple threads could work on multiple levels to return results.
or basically replaces windows with something else.
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Transaction is copying some files, failing in the middle, and not rolling back those copied over??
Hint. It's not transaction. It's just a bad piece of software that fails badly at doing it's basic job. Handling files.
There are two types of people in the world: Those who crave closure
From the article:
Today's typical desktop computer runs multiple programs at once, playing music while the user writes an e-mail and surfs the Web, for instance.
"Responsiveness really is king," he said. "This is what people want."
If you can't get those few programs right on a single core, you are going to really suck at getting them going properly on more cores.
I realise M$ don't have much control over the third party programs but if they use a core to study the instruction loading/unloading patterns, cache/memory access patterns, etc of the core doing the work and self optimise that then they may have a chance.
.
The author is talking about a complete OS redesign, not a new threading system.
Linux: 2 cores = 2 times faster, usually. And so forth... it's had scalable multicore/multiprocessor support for years.
Windows: extra core means 10% of programs are faster. So I very much confirm windows needs a rewrite for this.
Now some specific apps under linux still need work - but only if they are resource hogs. The only programs I've run into problems with this with of late are firefox (I'm now mostly running chrome - which is far smoother), thunderbird and - possibly - the X server itself. (I've looked into X server code though - it looks like it's now set to scale)
I can't say anything about BSD or MacOSX as I've never run either on a multicore system. For MacOSX though I'd wager that if it isn't already up to par - it will be. The OSX and even NextStep GUIs are designed to scale.
So you are basically saying: "It already scales perfectly to hugely parallel machines, so don't bother buying anything else, but in a couple of years, it will scale even more perfectly."
Give me a break. The NT kernel was never meant or designed for this kind of parallelism; other operating systems were.
I made the mistake of moving a massive amount of files from one server to another with teracopy. When the move failed due to a dropped network connection, teracopy deleted all of the files in the queue, including those that it had failed to copy to the server.
The television will not be revolutionized.
You don't even need one which can run in different threads. You just need one which can flag various tasks as "uh, come back to that in a bit", and then very quickly go to the next thing on the list.
That's actually pretty good typing with your fists. Do you have a comically large keyboard?
I love how Microsoft can come along in 2010 and with a straight face say it's about time they took multiprocessing seriously. Or say it's about time we started putting HTML5 features into our browser. And we're finally going to support the ISO audio video standard from 2002. And by the way, it's about time we let you know that our answer to the 2007 iPhone will be shipping in 2011. And look how great it is that we just got 10% of our platform modernized off the 2001 XP version! And our office suite is just about ready to discover that the World Wide Web exists. It's like they are in a time warp.
I know they have product managers instead of product designers, and so have to crib design from the rest of the industry, necessitating them to be years behind, but on engineering stuff like multiprocessing, you expect them to at least have read the memo from Intel in 2005 about single cores not scaling and how the future was going to be 128 core chips before you know it.
I guess when you recognize that Windows Vista was really Windows 2003 and Windows 7 is really Windows 2005 then it makes some sense. It really is time for them to start taking multiprocessing seriously.
I am so glad I stopped using their products in 1999.
A little off-topic, but I was wondering if anyone knows if a GrandCentral clone may be coming to Linux?
I know FreeBSD has integrated libdispatch into their kernel, but due to licensing issues this can't be done with the Linux kernel.
In windows Vista and 7 file copy is improved to avoid these problem, fyi.
Most software sits and waits for a user response or data from a device. It's a tiny minority of software that can make use of multi-threading. Programs like AutoCad and Photoshop already do.
...the implementation sucks.
Why for example does Windows Explorer decide to freeze ALL network connections when a single URN isn't quickly resolved? Why is it that when my USB drive wakes up, all explorer windows freeze? If you are trying to tell me there's no way using the current abstractions to implement this I say you're mad. For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem is. You're left piecing together what has and hasn't been moved. File requests make up a good deal of what we're waiting for. It's not the bus or the drives that are usually the limitation. It's the shitty coding. I can live with a hit at startup. I can live with delays if I have to eat into swap. But I'm sick and tired of basic functionality being missing or broken.
That's because most Windows applications are written in C/C++, and it would be a royal pain to make them asynchronous.
People confuse "multi-threaded" and "asynchronous". They mean almost the same thing, but there's a substantial difference in development styles. Multi-threaded (or "multi-core") is usually when an algorithm is split to run parallel across 'n' threads, asynchronous is when a program does something in the background without blocking. The former is actually quite easy in C/C++, the latter is very hard, because tracking memory ownership across a bunch of threads is a huge pain. It would help a lot if the core Windows user-space apps were re-written in a managed language like C# so that they could use asynchronous code heavily without the developers twisting their brains into knots.
What doesn't help matters is that Microsoft's multi-threading APIs and libraries have been terrible since forever, and their new push towards multi-threaded programming has been to polish the turd a little. They just don't seem to have smart guys working for them any more who can design something as complex as a general purpose multi-threading library (akin to OSX's "Grand Central Dispatch"). I've seen Microsoft's weak attempt at it in .NET 4, and it's just... sad.
there is a option, at least as far back as xp that allows explorer windows to run as their own tasks. Why its not enabled by default i have no clue about (except that i have seen some issues with custom icons when doing so).
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
You'd just be completing tasks faster that were never causing the program to appear slow in the first place. Complex games and heavy apps like internet browsers need to be multi-threaded but not your typical business or consumer application when the typical laptop has a 2.0 ghz dual core cpu.
On the contrary, everything in software should be event driven, down to the individual instructions. That is true parallelism, the future of computing.
Half a Century of Crappy Computing
The part of the article where Probert discusses the operating system becoming something like a hypervisor reminds me of the Cache Kernel from a Stanford University paper back in 1994. http://www-dsg.stanford.edu/papers/cachekernel/main.html
The way I understand it, the cache kernel in kernel mode doesn't really have built-in policy for traditional OS tasks like scheduing or resource management. It just serves as a cache for loading and unloading for things like addresses spaces and threads and making them active. The policy for working with these things comes from separate application kernels in user mode and kernel objects that are loaded by the cache kernel.
There's also a 1997 MIT paper on exokernels (http://pdos.csail.mit.edu/papers/exo-sosp97/exo-sosp97.html). The idea is separating the responsibility of management from the responsibility of protection. The exokernel knows how to protect resources and the application knows how to make them sing. In the paper, they build a webserver on this architecture and it performs very well.
Both of these papers have research operating systems that demonstate specialized "native" applications running alongside unmodified UNIX applications running on UNIX emulators. That would suggest rebuilding an operating system in one of these styles wouldn't entail throwing out all the existing software or immediately forcing a new programming model on developers who aren't ready.
Microsoft used to talk about "personalities" in NT. It had subsystems for OS/2 1.x, WIn16, and Win32 that would allow apps from OS/2 (character mode), Windows 3.1 and Windows NT running as peers on top of the NT kernel. Perhaps someday the subsystems come back, some as OS personalities running traditional apps, and some as whole applications with resource management policy in their own right. Notepad might just run on the Win32 subsystem, but Photoshop might be interested in managing its own memory as well as disk space.
The mid-90s were fun for OS research, weren't they? :)
-- John Truong
"For the talk, he set out to define what a new operating system, if designed by scratch, would look like today. He concluded it would be quite different from Windows or Unix."
But if you want to take the article as just an NT bash then go ahead, I suppose this is Slashdot.
I seriously have to ask, what is this guy on? Of course moving to multicore machines requires an OS rework. Frankly even windows has already been reworked to support this, and will continue to evolve in ways that prove beneficial. This is how development works, you gain a better understanding of the problem and then change things for the theoretical better then investigate then next holdup.
Why should you ever, with all this parallel hardware, ever be waiting for your computer?
Processing takes time. Chucking multiple cores at a problem doesn't magically make this time disappear. There are always physical limitations with the hardware available. Most of the delays you see nowadays in consumer applications (and others) are not from a lack of processing power, but instead from poor memory speed. For a processor to be able to do any real work it has to load all of the information from the hard drive into memory. Only then does the power of a single core come into play, and for a surprisingly short period of time. Even then accessing memory is an extremely slow operation, as information has to be brought into the caches, and written back/through to memory. The moment you start adding multiple cores on top of this, you suddenly start getting coherence issues between the caches, where one cache writes to data that is shared between the cores.
The OS could assign an application a CPU and some memory, and the program itself, using metadata generated by the compiler, would best know how to use these resources
Is he suggesting that you have as many CPU's as you do programs, each with their own high-speed caches. CPU's in general sit there idling for a large percentage of the time, and that's with multiprogramming already in place. Also, the caches are the most expensive form of memory, are consumers going to pay that price, for something where they'll still just have to wait for IO anyway? This just sounds like an extremely large waste of resources. The last part of that statement is also how things already work. Has this guy not heard of OpenMP before? Granted for the time being people are expected to include this metadata themselves, but this is an area of computing being highly researched, attempting to automate this process as much as possible. Most compilers already do this up to the point of static analysis, and many are gaining new abilities such as speculation to go further.
To get the full benefit from multiple cores, developers need to use parallel programming techniques. It remains a difficult discipline to master and hasn't been used much, outside of specialized scientific programs such as climate simulators.
It is difficult, but it's getting easier. Many programmers learnt to program in a sequential imperative way, it takes time to break out of these habits. It is also a discovery process as we don't entirely know how to make programs in parallel. Languages are adapting to aide this process (many functional languages for example) but they each have their own issues and limitations. These techniques are being widely used, but much of the problem is that consumer level programs don't actually have much parallelism to them. It becomes much more obvious for scientific programs as they are inherently parallel. Again, compilers are making great strides in automating this process for the programmer.
You don't want to wait for Microsoft Word to get started because the antivirus program chose that moment to start scanning all your files. Most OSes have some priority scheduling to avoid these bottlenecks, but they are still crude
So think about the specifics of how the hardware itself is going to react to what you're asking and work on a better scheduling mechanism?
In this approach, the operating system would no longer resemble the kernel mode of today's OSes, but rather act more like a hypervisor. A concept from virtualization, a hypervi
Who need's speling and grammar?
If you are trying to tell me there's no way using the current abstractions to implement this I say you're mad.
That's between me and my psychiatrist... but I suspect current abstractions do have quite a bit to do with the 'overzealous locking' problem you're describing.
The current abstractions promote the idea that sequential operation should be the norm and parallel operation is something you have to manually program for. And that manual programming (processes and threads) is done in a number of incompatible ways derived from different models, and at least one of them (threads) is really, really unsafe and practically impossible to do correctly.
So programmers being lazy and smart, do as little work as they need to, and they tend to lock things in large chunks, because that's simple and it works and can be tested roughly okay.
I believe that if we had finegrained instruction-level parallelism as the paradigm, the opposite state of affairs would hold: things would naturally be done in parallel, and it would take work to create global synchronisation. Programmers would still be lazy, but you wouldn't have the 'gah why did doing one thing lock up a bunch of others' issue - you'd have the 'gah why is my one big task still waiting on lots of little tasks to complete'.
Which I think would be a better world and slightly less broken than the current one.
Admittedly finegrained parallelism does mean the potential for a lot of speed loss in context switching if it's done dumbly, so I think making it work would require highly dynamic languages able to 'recompile' or reallocate code on the fly. Current thinking in language design doesn't favour highly introspective dynamism but is still hung up on compile-time optimisation and hard-coded typing. It would also require a complete ground-up rewrite of code merging language and OS into one abstraction, and nobody's keen to do that.
But in a perfect world, that's where I'd like to go. Parallel everything, and serial as a system-generated local optimisation.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I smell an open-source opportunity to replace Windows Explorer. If each component/function of Windows is slowly replaced by a better open-source version, then eventually people won't need Windows at all without the learning curve transition of Linux distros.
Table-ized A.I.
that comes from neither the Program nor the OS knowing how to schedule the tasks across all CPUs/cores is that when a poorly written or otherwise CPU intensive program pegs one core the OS and other programs running suffer nearly no performance hit.
Morpheus, God of Dreams.
I've been wondering for years why disk I/O makes the machine slow down. Antivirus scans taking 5% CPU time should not reduce the response rate of the system, because disk reads should be the bottleneck, not scanning. But I always see a slowdown when that happens, disk access in general. File copying doesn't see to show as much of a problem, but it should be in theory reading and writing combined. 95% idle CPU should respond instantly, but it doesn't.
I remember watching a 233mHz box run NT 4 server, and things like zipping a file up would make the screen update so slowly you could watch each box paint. First the outline, then the fill, then any text, and on to the next box. It got better, as computers got faster and I assume MS fixed some aspects of it, but it's still there.
I wrote a VBS that uses WMI objects to lower the process priority for several things (I know, we're supposed to disable them from starting up, but I can't in this case). The biggest offenders are: wmiprvse.exe, msiexec.exe, wuauclt.exe. When they start using CPU, the interface locks. I never knew why.
Now it makes sense. Task switching shouldn't be a problem if you're not using all your memory - paging does add a delay, especially if you just have to fetch a little used resource from the far end of a file that's been dropped from memory due to least-recently-used swapping. So without paging, interrupt overhead could explain it - but only if the 'system' process ignores that in its reporting - because I wouldn't even notice if CPU usage spiked when the UI became sluggish.
Then again, shouldn't the UI have highest priority? Programs shouldn't decide what you're working on - if you click something else, it should work. If a runaway program is doing something stupid, it shouldn't take 5 minutes to bring up task manager, or process explorer - that's why I had to run my VBScript on startup in the first place.
When I can't figure out what's using the CPU because task manager won't come up because some program is using all the CPU, that's bad. But when I finally get task manager open and it shows 99% idle and I still can't select a line and "End Process" because the UI is barely responding, that's terrible. Watching task manager paint each line on a dual core 2.53 gHz notebook, with 99% idle time, is unacceptable.
If we want efficient code, we have to figure out ways to reward the programmers that write it. I don't see any sign that people anywhere are interested in doing this. Anyone have suggestions for how it might be done?
It's happening, from a source people didn't expect: portable devices. Battery life is becoming a primary feature of portable devices, and a large fraction of that comes from software efficiency. Take your average cell phone: it's probably got a half dozen cores running in it. One in the wifi, one in the baseband, maybe one doing voice codec, another doing audio decode, one (or more) doing video decode and/or 3d, and some others hiding away doing odds and ends.
The portable devices industry has been doing multi-core for ages. It's how your average cell phone manages immense power savings: you can power on/off those cores as necessary, switch their frequencies, and so on. They have engineers who understand how to do this. They're rewarded for getting it right: the reward is it lives on battery longer, and it's measurable.
Yes, you can get lazy and say 'next generation CPUs will be more efficient', but you'll be beaten by your competitors for battery life. Or, you fit a bigger battery and you lose in form factor.
The world is going mobile, and that'll be the push we need to get software efficient again.
I found a solution to this long ago. After the copies fail, select all of the files and copy them again. When the "this file already exists" prompt is displayed, place your stapler, jam your pencil, or do something of the like to hold the "n" button down since there isn't any way to say "repeat". I recommend having notepad running in the background to catch all of the extra "n"'s.
Luckily, this isn't an issue in Win 7.
that has nothing to do with dumb programmers. Modern programs are not designed for old systems. People with old systems are not the targeted market for shiny new software. This would be like calling Crytek programmers dumb for making a game that doesn't work well on your 5 year old computer. Modern software is designed for modern computers.
For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem
Try TotalCopy which adds a copy/move in the right click menu; or Teracopy commercial (free version available, supports Win7) complete replacement for the sucky Windows copy system.
USB/Network freezes and file copying isn't a fault of CPU cores like you say, Windows is just a sucky OS. Multicore stuff gets complicated, but this isn't going to be a panacea for Microsoft, it's another marketing opportunity.
Went to high school with the guy. If he remembers me, it's only as that dude every one in Chess Club could beat with time enough in a lunch period to start another match.
It seems to me that the history of software architecting has been to write things that were kinda close to correct and then punt on the final polishing until the hardware caught up. One reason why software and computers are so widely loved and respected. From the original article, I suppose the argument is being made that all the folks adding cores should take a break. However, looking at the speculation in the article, there seems also to be the suggestion that by adding more and more cores, each process may be given its own cpu. While this would allow for more simultaneous independent processes, each process still takes as long to complete. There are two things which could cause the user to press the "This Sucks*" button, their music stutters, i.e., a particular process doesn't have the resources it needs, or the user has to go to the meeting but the computer hasn't finished rendering the hand-out, i.e., a particular process requires a certain number of clock ticks.
At its heart, a processor does two things, count and compare. Feeding the jobs to the processors so there's few moments of inactivity is, I believe, an NP problem, which means the better algorithms get the right answer a lot of the time. One could do better if one could predict the length and number of jobs that will enqueue, but, being able to predict in that way seems to contradict the results from The Halting Problem. So, my educated guess would be that 100% efficiency is an unobtainable limit. Now imagine that we are talking about a desktop and the computer is waiting for me to type, read, and type again. Could the system have devoted more resources to housekeeping during the millions and maybe billions of cycles between the events I initiate? Sure, but who's to say that the next event occurs in 0.75 seconds or 20 minutes (because I went and had a snack or got a phone call). Context switching will always have a cost and my tasks will be the ones I notice as slow or unresponsive. Operating systems are written to give me the illusion that it gets right on the things I ask.
The article suggests there's a "Field of Dreams" effect regarding hardware and that this is a problem. I remember being taught that anything one may do in hardware one may do in software and vice versa. So, it makes sense to me that hardware folks should build the best processors they can imagine and left the software people figure out utilization tactics and strategies.
That, though, leads me to the other big hairball. Legacy software. We have concurrency/parallel sensitive languages. We have semantics that have been added to existing languages so that blocks of code may be noted by the runtime and distributed to the good-enough and sometimes best choice among available processors. But, where's the business case for hiring programmers to go back, rewrite and re-debug old software to identify the blocks? This point applies to the new wished-for architecture as well, if it existed. What are the odds that C will be the best higher level language for the bare-metal systems programming in this new hardware architecture? (What about real-world patent/marketing issues with a new architecture and, by this, I ask unless it was invented by Intel, wouldn't Intel do everything in their power to kill it?) Would it be fair to say that one problem with a pc on every desktop is that when the pc needs to be changed, it takes forever?
* A performance monitoring and adaptation mechanism suggested in the article. Which reminds me, how much of our desktops' poor performance may be laid to network latency, congestion, and the economics of bandwidth capacity?
It isn't.
Multicore has been with us for over a decade now. It is practical and conducive to build open cores from class declaration up so methods, file types and handlers exist between architectures and at same time there's decoupling of needed resources as processes.
To point the way to what exists now there's Yellow Dog Linux for both Macintosh and Apple's PPC platform:
http://www.yellowdoglinux.com/products/faq/
The older version works on MacOS 8/9. The new one works on Mac OS X.
Linmac or lintel would be most nice for us micro-engineers. The smaller businesses we want to associate with could branch away from both static software design and largescale deployment tied to that very design, focusing more on customizing digital end-pieces to attach to current semiconductor inputs if the correlated software to do that in places (like EAGLE for Ubuntu) is manufactured and delivered in an open core form of engagement.
FreeFileSync has a decent enough GUI, for the timid:
http://sourceforge.net/projects/freefilesync/
(a nice feature is that 'compare' and 'synchronize' are separate steps, with a visual display of the comparison)
Nerd rage is the funniest rage.
I'm getting really sick of posting this, but I'll continue to do so until you do.
BUILD A WORKING PROTOTYPE OF THIS "UNIVERSAL BEHAVING MACHINE", OR SHUT THE HELL UP.
Those of us who aren't insane aren't impressed by talk, we're impressed by results. If you spend half as much effort building the thing as you do flapping your damn jaw, you'd be done by now.
(For any uninitiated mods, this fellow is slashdot poster "rebelscience", and maintains a website of the same name. Every time a multiprocessing-related thread comes up, he posts this tripe but has never actually done anything about it. Visit his website, and you'll see why I call him a lunatic)
The key may not be in throwing more energy into refining techniques such as parallel programming, but rather rethinking the basic abstractions that make up the Microsoft operating systems model.
There. Fixed it.
Windows is a lot like Apple's old OS 6/7/8 was - old and haggard and full of legacy cruft that just needs a complete ground-up re-write to address. Sure, it looks pretty and runs fairly decently now, but it's plainly also at the end if its life-cycle and showing extreme signs of stress.
Apple took an enormous risk in making a clean break from the past and it seems to be working well for them. Microsoft needs to as well. I doubt that it will, though, as it tends to operate more like GM than anything else. Tons of levels of bureaucracy and a general unwillingness to do serious innovation. After all, what worked in the past should work in the future? Right?
Let's hope that they figure it out sooner rather than later. Or else it's going to get very very lonely at the top.
The most popular consumer apps are based on old codebases that were written in c++. There are actually few .net apps in comparison and one of the most popular (Paint.net) is very light on resources. It's far lighter than The Gimp which is written in c++.
.net apps are compiled to native code, it's a myth that they use a virtual machine.
.NET has nothing to do with heavy cpu usage.
Oh and
You can write a cpu-heavy program in any language.
Well, I came here to see the fisting. And frankly, so far this site has been a real disappointment.
You have to read at -1 to see the goatse trolls.
I am becoming gerund, destroyer of verbs.
"Responsiveness really is king," he said. "This is what people want." The problem in being responsive, he noted, is "how does the OS know [which task] is the important thing?" You don't want to wait for Microsoft Word to get started because the antivirus program chose that moment to start scanning all your files.
.NET but the article isn't about .NET or Grand Central. The author wrote about how a completely new OS needs to be designed around multi-core machines.
Microsoft has made multi-threading easier for Windows programmers as well with
Yay. Lets get it started!
Grand Central doesn't address issues that the author went over. He's proposing a new OS that gives applications direct access to resources.
But I guess questioning Apple praise on Slashdot is a good way to get modded down.
I use FastCopy since it's free software and skips files that haven't changed. Has lots of other nice features as well but I've not seen it widely mentioned anywhere. Enjoy.
since there isn't any way to say "repeat"
Actually, there is.
How can I believe you when you tell me what I don't want to hear?
Fixed in Vista and 7, you can ignore errors and continue copying.
I come to /. to read tech news...
you must be new here
This seemed like a reasonable sig at the time.
The article in question talks about Winblows.
What about Linux?
Does it need retooling as well?
Muchas Gracias, Señor Edward Snowden !
The myth is that .net apps run inside a virtual machine just like ye olden Java apps.
From what I understand, the author is calling for a complete reinvention of the computer and computer programming. It's not something you can do in your spare time on a shoestring. Apparently, there are a handful of people interested in starting an open source project to implement it. Maybe you can contribute.
I've always thought that both data flow languages and fortran95 had some innovations for multi-core programming worthy of being copied.
Data flow languages such as "G" which is sold as national instruments "labview" brand are intrinsically parallel at many levels. What they do is look at a function call as a list of unsatisfied inputs. These inputs are waiting for the data to arrive to make the variables valid. Then the subroutine fires. Thus every single function is potenitally a parallel process. it's just waiting on it's data. If you program in a serial fashion then of course those functions get called serially. But with graphic programming in 2D, you almost never are programming serially. You are just wiring outputs of other functions to inputs of others. Serial dependencies do arise but these are asynchronous and localized cliques. everything else is parallel. Yet you never ever ever actually write parallel code. it just happens automatically. Perl data language had a glimpse of this but it's not the same thing since the language is still perl and thus not parallel.
Objective-C with it's "message passing" abstraction is perhaps getting closer to the idea of a data flow. While one might complain that well objective-C message passing is just a different sugar coating of C just like C++ is. This would be true from the user's point of view. But it's not as true from the Operating system's point of view. IN OSX, these messages are passing more like actual socket programming at the kernel level. So there's more to objective C on apple's than meets the eye. But I don't know how far you can push that abstraction.
In fortran there are some rather simple but powerful multi-processor optimizations. First there's loops like "forall" that designate that a loop can be done in any order of the loop index and even in parallel. and then there's vectorized statements as part of the language like matrix multiplies. those are rather simple things so don't solve much but they do show that you can put a lot of compiler hinting into the language itself without re-inventing the language.
Some drink at the fountain of knowledge. Others just gargle.
Say for arguments sake that every application created for a PC ran on bare metal CPU or at worst on a BIOS to provide access to hardware: hard drives, input devices, peripherals, networking, etc.
This should make those applications much faster as there would be no middle man OS getting in the way telling the app what it could or couldn't do with resources. Every request by the app was responded to as fast as the CPU was able.
This is what the poor MS guy is talking about. How many apps do you want to run at a time? More than 32? Well there's going to be 128 cores available in the not so distant future. You could run 128 applications that could talk to each other (conceivably) without any standard OS getting in the way. Now of course you would likely need a few 'applications' which we take for granted as part of the System OS - File management and Search, Basic Networking (getting IPs, DNS, DHCP, etc), Print Manager, etc. so some cores would be taken up by these utility apps.
Overall though you would be running one app, one core with a Hypervisor of sorts managing the interconnect.
You have to admit that it's an interesting perspective if nothing else... stop trying to manage threads, processes, optimization for parallel computing... just stop and realize that you don't have to any more. There are plenty of cores to go around... just give the app it's own core and let it run hog wild.
A fool throws a stone into a well and a thousand sages can not remove it.
Grand Central makes threading easier but so does .NET.
If you are going to write a 3D game for OSX you sure as hell can't just write it as single-threaded and have the OS figure the rest out. GCD is just an improved threading system. You still have to figure out how you are going to break the program up.
it can't have anything to do with decisions based on cost/benefits.
I'm no CPU expert, but here goes.
We dont need any more CPU Cores. Aint GPU and OpenCL here
to solve most of this problem?
I mean, for most of us, all we ever need is use a nice fast,
efficient DualCore, and a massive GPU.
Enlighten me.
Coding this stuff by hand is a hassle. It's not horrible, but it isnt anywhere near the ease of coding non-threaded message-less communications. Now quite a bit can be done by adjusting a library call to make use of multiple CPU's.. Calling a sort function on a large list should auto parallelize with no intervention by the programmer.
The programs need to have a supervisor that gets and transmits a heartbeat of the status of a program. Where the supervisor is virtually crash-proof.. And has the ability to properly release resources should the system enter a suspected deadlock (no this isnt remotely easy to do right, but easy to code a simple version that works well enough)..
Coding Efficiently isnt really going to happen, there will just be efficient-enough. But using all the hardware so that software can be snappy is going to help, and functions that let a person do big things without having the ability to butcher the small things.
some of the things that bother me most about the OS
Blame goes to Microsoft Management for that one
that is somehow still the most popular desktop OS in the world.
Credit goes to Microsoft Legal for that one there.
Glad to help clarify things for you.
If youre moving thousands of files over the network and youre not using xcopy, youre doing it wrong.
I haven't seen the code, but my guess is that Explorer freezes because it was written back when gethostbyname() was the only option for DNS lookup. Unfortunately, that function was both synchronous and non-reentrant, so it might have helped if they'd updated the code to use WSAAsyncGetHostByName(), but that function actually isn't reentrant either!
MSDN says:
The WSAAsyncGetHostByName function is not designed to provide parallel resolution of several names. Therefore, applications that issue several requests should not expect them to be executed concurrently. Alternatively, applications can start another thread and use the getaddrinfo function to resolve names in an IP-version agnostic manner. Developers creating Windows Sockets 2 applications are urged to use the getaddrinfo function to enable smooth transition to IPv6 compatibility.
So the current "best practice" is to use getaddrinfo() in another thread. I guess the Explorer team didn't get the memo.
He does it the same way Strongbad does
Cheers, Chris
First, the article in question talks about OS architecture, not Windows specifically. He specifically states that what he is speaking about is not something MS is working on. Quite the opposite, many of his MS colleagues disagree with him.
Second, the fundamental problems with OS design are exactly that: fundamental problems with OS design. Nobody is making an OS that truly takes advantage of multiple cores, it's still single-processor thinking with the ability to use more than one processor, and this leads to a number of inherent problems.
The article talks about what an OS might look like if built from scratch specifically for multiple core processing power, and there is nothing on the market like it at the moment. It's basically a hypervisor-based OS, where instead of giving programs slices of CPU time, the OS gives programs actual CPUs and slices of memory to use.
Something like that would be extremely slick, we already do that for virtual machines and we end up with 8+ full-fledged servers running on the same machine. Why can't you pull that back a little more so it's individual programs assigned to each CPU such that they don't have to interact with the OS at all once they are up and running? Can you imagine?
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Apple's grand-central dispatch (GCD) solution is really primitive. It's just a simple thread-pool, where the programmer breaks their program down into tasks that can be executed independently then queues them for execution by the thread-pool.
GCD is not in the slightest innovative, except for a hack that allows "c" programmers to write tasks with slightly more convenience, by adding limited "closure" support to the language.
Similar concepts can be found all over the place; just see the "see also" section on the wikipedia article:
http://en.wikipedia.org/wiki/Grand_Central_Dispatch
Using any of the libs listed in that "see also" section, you can get GCD equivalent behaviour on unix/windows, and have been able to for years.
There are also languages with far superior parallel-processing abilities, where the effort is done by the compiler/environment, not the programmer. See any functional language, eg Haskell or Erlang. Write a program in these languages, and the parallel-processing happens just about automatically.
Adding parallelism to the *OS* is quite a different issue, and not one that Apple's GCD addresses.
Windows Explorer no longer kills network transfers after a failure as of Windows Vista.
Maybe some of the people complaining about Windows should stop using a version thats 9 years old (XP). Red Hat 7.2 isn't particularly great by today's standards either.
Microsoft is not satisfied with getting nine women pregnant and getting a baby in a month - they think we should get 259 women pregnant, and get a baby in a day.
Somethings just *HAVE* to happen in sequence, and can't happen in parallel. You can't add x and y to get z *WHILE* you're adding z and w to get n.
There is no information in the article. He asks if we have multi-core CPUs why would we ever be waiting for something to happen on our PC? Well, cuz the slowest thing in the PC is the hard drive... and more people only have one. Prioritized IOs don't make that much of a difference because even if my disk was idle, and the low priority IO (Vista has these BTW, 2 IO priorities) moves the disk head, and then my higher priority IO comes in, it's been delayed because it has to move back.
Disk IO is the biggest bottleneck and redesigning Linux or Windows isn't going to solve that problem. L1,2,3..X cache -> memory -> disk, as long as we have that heirarchy and there is such a disparity between the layers, no OS rewrite will help.
That's why massively parallel systems are so radically different from general purpose computers and ususally only useful on specific tasks (e.g. SIMD implementations etc.)
Research in highly parallel IO is addressing the issue, but won't help home/small business.
No wonder this dude's peers at MS disagree w/him.
You will have to design your apps and supporting hardware to take advantage of whatever parallelism you have available, and break up your workload intelligently.
Yeah you'll have to pay people who understand how to do concurrent programming properly.
How comes that, after a Microsloth lackey talks about "rethinking OS's" and gets everyone hot and horny with mental masturbations of what needs to be done to that disgrace to Computer Sciences called Windows, not a single mention has been made to the fact that Sun Microsystems developed the Niagara processor, with 8 cores capable of running 4 concurrent threads each, for a massive total of 32 concurrent threads in a single chip. And how the Solaris O.S. has evolved to a massively multithreaded system capable of using that processing capability. And how that was done in the past century. But since at the time Microsloth was too busy extorting our money with Lentium single core/thread processors, all that technology was conveniently ignored. Now that the low hanging fruit is gone and the going's rough, they will want us to believe they "invented" together with their Intel cohorts the multicore/multithread/paralell processing idea so they can raise the price of Windoze 8?
It should be enabled by default, but it's not. The Microsoft reasoning behind this is that it uses additional RAM per Explorer.EXE process.
Life is not for the lazy.
To anyone using Windows (XP, Vista or 7) right now, go ahead and open up an Explorer window, and type in ftp:// followed by any url.
I just tried this on a Windows 7 PC. An unresolvable name returns an error in a few seconds. A resolvable name, with no FTP server on the other end, produces the wait cursor, but I can click on another drive or folder and it responds in a few seconds (other Explorer windows are instantly responsive while this happens). A working FTP site (eg: ftp.microsoft.com) opens with a listing pretty much instantly.
Where's the problem here ?
Let's not say that modern operating systems need to be reworked when the only one that needs to be reworked is Windows. Don't act like everyone else has the same problem. I'm not trying to be a fanboy here, but see this page - specifically the section marked "grand central dispatch" : http://www.apple.com/macosx/technology/
or else!
Windows explorer sucks. It always just abandons copies after a fail - even if you're moving thousands of files over a network. Yes, you're left wondering which files did/didn't make it. It's actually easier to sometimes copy all the files you want to shift locally, then move the copy, so that you can resume after a fail. It's laughable you have to do this, however.
But it's not a concurrency issue, and neither, really, are the first 2 problems you mention. They're also down to Windows Explorer sucking.
They seem to have fixed those issues with Windows 7. But ya, it really pissed me off too. The other thing that has made me literally destroy hardware is the way XP would lock your whole goddamn system if a network resource stopped responding.... even when you weren't trying to access it.
Please move along
I still cannot find the droids I am looking for...
For that matter when a copy or move fails in Explorer, why can't I simply resume it once I've fixed whatever the problem is.
Are you still running XP? They fixed that in Vista.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
App programmers do not deserve all the blame. The tools for multithreaded development are primitive and difficult to use correctly. It is difficult and expensive to make good reliable MT software.
Many years ago if I wanted a list of data I would manually malloc, memset and free data. There were lots of bugs because of the tedious management of memory. Now in C++ I write vector, or in Python I use a_list = [] and POOF! I don't need to keep track of ANY details.
The state of multithreading libraries and tools must evolve to the point where normal (ie not VERY skilled or creative) developers can handle them without much thinking. This may require a paradigm shift similar to the object-oriented one in the eighties.
Objects and exceptions and stack unwinding seem almost obvious to us, but some people had to pave the way for their use. We need some skilled computer scientists to work with skilled library developers to make a new paradigm for developing MT apps. When these ase of yet undiscoverd (or unpopularized) paradigms have been developed, we better hope that big players have the incentive and capacity to implement them in their current systems.
I for one welcome our multithreaded overlords... when they get here.
What's wrong with at least some operating systems doesn't even have anything to do with multiple cores per se. They're simply designing the OS and its UI incorrectly, assigning the wrong priorities to events. No event should EVER supersede the ability of a user to interact and intercede with the operating system (and applications). Nothing should EVER happen to prevent a user being able to move the mouse, access the start menu, etc., yet this still happens in both Windows and Linux distributions. That's a fucked-up set of priorities, when the user sitting in front of the damned box - who probably paid for it - gets second billing when it comes to CPU cycles.
It doesn't matter if there's one CPU core or a hundred. It's the fundamental design priorities that are screwed up. Hell should freeze over before a user is denied the ability to interact, intercede, or override, regardless how many cores are present. Apparently hell has already frozen over and I just didn't get the memo?
What doesn't help matters is that Microsoft's multi-threading APIs and libraries have been terrible since forever, and their new push towards multi-threaded programming has been to polish the turd a little. They just don't seem to have smart guys working for them any more who can design something as complex as a general purpose multi-threading library (akin to OSX's "Grand Central Dispatch"). I've seen Microsoft's weak attempt at it in .NET 4, and it's just... sad.
I love when Some Guy on SlashDot mocks those silly (Ph.D, very very highly paid, very experienced) idiot developers at Microsoft. I'm sure you're a paragon of the software world, dude.
Paragon.
There is rsync, scp and a pile of other things for MS Windows now. It's growing up.
"Why should you ever, with all this parallel hardware, ever be waiting for your computer?"
Well for starters its only the CPU thats parallell in most computers. Your bloated pig of an OS that takes 4 Gig to run is causing more waiting because of I/O than because of CPU tasks. Stop writing often used routines in high level languages and youll see performance gains much bigger than any hardware can bring the next couple of years.
HTTP/1.1 400
I guess it's up to MS to make a easy to use idiot-proof threaded framework for crappy programmers to use.
Simon Peyton-Jones is woking on Haskell and Software Transaction Memory. Instead of specifying "lock here" and "unlock here" you say "this block should be executed atomically", with the posibiity of aborting, pausing or retrying the transaction (say, if you're waiting for a queue to be nonempty).
I won't call it idiot-proof, but it's more human-fallibility-proof than threads and locks (I guess: I haven't tried it).
The research on software for multi-core/cpu computers wasn't stopped once people thought their desktops were fast enough, it's been continued for decades and the results have lead to more and more efficient servers. The point is that the PC, the desktop/laptop computer isn't setup as a server with multiple cpu's, shared memory and what not, and in there lies the problem. Not the research, not the software design principles, not the lack of research in languages.
Never underestimate the relief of true separation of Religion and State.
I've personally seen Windows Vista somehow cause a Windows 2000 file server to crash when copying large files from the network drive. That was before any Vista service packs, so it was the same Vista whose network performance turned to ass to keep the music from skipping.
Looks like Tanenbaum will have been right after all, I mean, a vast amount of cores and huge parallelism is the advent of the micro- and exokernel, isn't it? This would be the simplest way to harness the multiple cores (instead of modifying a monolithic kernel to use multiple cores)
What doesn't help matters is that Microsoft's multi-threading APIs and libraries have been terrible since forever, and their new push towards multi-threaded programming has been to polish the turd a little. They just don't seem to have smart guys working for them any more who can design something as complex as a general purpose multi-threading library (akin to OSX's "Grand Central Dispatch"). I've seen Microsoft's weak attempt at it in .NET 4, and it's just... sad.
I love when Some Guy on SlashDot mocks those silly (Ph.D, very very highly paid, very experienced) idiot developers at Microsoft. I'm sure you're a paragon of the software world, dude.
Paragon.
Oh, I'm not, other people are. Like the guys who work for SUN, who integrated the best available multi-threading library for Java into the standard libraries. This was like... many years ago.
Keeping in mind that C# and Java are virtually identical, why the hell wouldn't Microsoft implement a library that is "as good, or better"? Why would they implement some toy library that can't handle even trivial scenarios, let alone scale to hundreds of cores or handle huge enterprise apps?
The only reason I can think of that they wouldn't do things well is that they... can't.
perhaps it's time to rethink the basic architecture of today's operating systems, suggested Dave Probert, a kernel architect within the Windows core operating systems division at Microsoft.
Well, perhaps it's time you stop to equate "Windows" with "today's operating systems".
Every other major OS on the planet has been moving towards multiple cores for several years, and is ready for the multi-core systems currently on and coming to the market in the coming years. All, except Windows.
Assorted stuff I do sometimes: Lemuria.org
Windows XP Service Pack 3 was released on April 21, 2008, and my explorer.exe is dated April 14, 2008. Surely there has been time to fix Explorer's behaviour during those seven years.
"Stop failing the Turing test!" -- Dilbert
Maybe that "few seconds" is about 200 times slower than it should be?
I'd browse at -2 if I could.
English is not this
One of the reasons for not being parallel enough is that the C programming language is not easy for parallelism. It's not that it can't be done, but the language's basic purpose is at odds with the principles of parallelism. Something like Haskell is much easier to automatically parallelize, because of the lack of destructive updating, but Haskell goes to the other extreme. Something in between is required, but it's not here yet.
Because CPU power isn't the bottleneck in most systems, duh. What's slowing todays computer down are things like mass store access times and bandwidth, RAM size and bandwith, etc.
I've done that - I'm using Ubuntu as a base OS, and only use Windows when I have to (and as a VM, so it's sandboxed away from my regular desktop).
Well, I came here to see the fisting. And frankly, so far this site has been a real disappointment.
I know, /. was a lot better when goatse was all the craze.
Well, he said things like parallelism in filesystem access is just a gimmick. (See Linus-Tannenbaum debate.)
BeOS!
But you killed it, so apologise for that first.
The STM transaction are not monitors, because they are not objects (http://en.wikipedia.org/wiki/Monitor_(synchronization) says monitors are objects). Also, STM transactions nest.
Suppose your queue has a shift method, which does something like { while (empty) wait; ret=first; --size; return ret; }. Suppose it has a similar push method.
Now, I want to do a queue transfer: grab one element from one queue and put it in another. How?
{ while (q1.empty) wait; while (q2.full) wait; q2.push(q1.shift()); }
How do you do that with threads and locks? Well, if you don't reach into the locks inside of q2, you can have it fill up after you shifted out of q1, leaving you dangling (perhaps causing a deadlock somewhere else). So really, you have to violate the encapsulation of the queue class to add new atomic methods _using_ queues (not extending them).
That is why STM beats locks and conds, and incidentally why it beats monitors implemented using locks and conds (yeah, you can use semaphores instead, but you don't want to).
http://www.barrelfish.org/
That's actually pretty good typing with your fists. Do you have a comically large keyboard?
Yes, yes I do !
~Sent from my iPad
In the subject, since you asked.
solutions for the copy/move problems:
- teracopy: 3rd party, nice and neat
- robocopy: MS app, kinda clunky but better than nothing
too lazy to add links, just google
"There is nothing more frightful than ignorance in action." Johann Wolfgang von Goethe
Pervasive multithreading gives you the best user experience. Hell, even the Linux kernel is self-preemptible to provide a faster-looking user experience.
I want to delete my account but Slashdot doesn't allow it.
if you are a developer/user, then you care.
If however you are a developer/seller then the hardware costs are bourne by your customers and you don't give a shit... Hence ruby on rails.
Deleted
That's actually pretty good typing with your fists. Do you have a comically large keyboard?
He must have learned how to do it from Strongbad!
Right... an issue which was fixed 3 years ago with Windows Vista
How do we test software written to be heavily parallel? For example, the games industry, we'd love to have ultra complicated path finding for 1000s of NPCs, we'd love to have bazillions of particles in a scene, but when we are presented with the task of developing a game for a quad core machine, or the PS3 (which are both about as parallel-capable as you can get at the moment), how do we write software that we can test on 16, 32 or 64 cores. TBH, we'll do what the games industry has always done and write for the target hardware.
And It will be implemented if not allready in freeBSD... after that maybe Linux will follow if that group of people understand the significanse of the technology. Under OSX 10.6.x it's called Grand Central Dispatch. And is opensourced under a different namne libdispatch, it utilise block that has been sent for standardisation and implemented int C, C++, and objC. Gcc compiler supports blocks it's just upp to you developers to utilize it. Automatic muliti threding, opimiates automatically for the hardware the user uses without compilation, all is done. Only thing that the developer needs to do is to state what parts of their code should be mulit thredded. The system desides amount of threads, syncronisation and all the rest. Programming for the rest of us. Souns likte too good to be true, an Apple fanboys geek talk or trolling. Why dont you check it out yourselfes. MS. could benefit from the blocks, but still need to implement their own GCD or opensource their kernel, If i understand the Apache license correctly which I havn't read myself. Apple opensource : http://opensource.apple.com/source/libdispatch/libdispatch-84.5.3/ Apple white paper on GCD: http://www.apple.com/macosx/technology/#grandcentral
He concluded it would be quite different from Windows or Unix.
Well, duh! Talk about stating the obvious. Those were not the systems I was referring to. My point is that he needs to read the literature, since there were plenty of operating system and programming languages other than Windows and UNIX/Linux at one point, some of them for massively parallel systems.
"Why should you ever, with all this parallel hardware, ever be waiting for your computer?"
Cause it still needs to goto 1 display screen likely. Single display? there's your bottleneck.
'Why should you ever, with all this parallel hardware, ever be waiting for your computer?'
In my experience, the vast majority of waiting that I do is because of hard disk I/O, not computation. I suspect that focusing effort on the intelligent and wide-spread use of SSDs and other faster-than-hard-drive media will do more to minimize my wait time.
In a similar vein, you can bolt a newer desktop environment onto that Red Hat 7.2 box. At least, you can leave the kernel and glibc behind in ancient history, as the GUI is not part of the operating system. (It's part of the Red Hat distribution, but you can replace it with anything you like. Like replacing OS X Finder with PathFinder or something.)
Now, if you want suck, how about an NFS server that freezes all client connections because one filesystem it is serving is over 95% full and the filesystem driver has a disastrous big-O complexity problem in the free block location algorithm? One that isn't solved by the normal "reserved for superuser" hack that's been in UNIX since the days of a 14-byte filename limit.
"Windows soon hopes to catch up to where Unix was in 1993."
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Have one virtual CPU that is really 4 cores. So it can issue 4 cores X 6 instructions/cycle = 24 full instructions dispatched in one cycle. OK, maybe overkill for small programs.
Have you ever actually programmed in either of these two languages? In neither does parallel processing happen automatically. They both simply happen to come with easier-to-use thread synchronization mechanisms. You still have to decide what are your program's threads and the details of how they communicate.
Are you adequate?
Optimising OS code to milk every cycle from the available CPUs is exactly what OS programmers have done from the start (even at Microsoft).
I'm on a core2 duo, and the only time I ever wait on my processor is when I'm playing a game or when I'm using keepass, because my db is reencrypted I think 1000 times.
I do a lot of waiting though, but it's waiting on my hard drive. Don't think multicore is going to do much about that.
I haven't read TFA, but quoted like that it looks pretty daft.
http://developer.apple.com/leopard/overview/objectivec2.html
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
Remember how much Mac OS 7-9 sucked? One reason was that every application had to re-implement all kinds of resource management code that the OS normally took care of. Shared resources, and a CPU is a shared resource even if you have dozens of the things, just as files are a shared resource and managed by the OS even though you have hundreds of thousands of them, should be managed centrally.
This doesn't mean that the specific APIs devised to share single processors between hundreds of programs are necessarily ideal, but there's a hell of a lot of a difference between that and throwing up your hands and saying "let's just give each program its own VM".
... for the multi-core era.
Too bad it is not microsoft: http://www.top500.org/stats/list/34/osfam
Those options still require that the programmer choose the parallelization points (and therefore synchronization points) explicitly. That is a far cry from what you claimed in the grandparent post:
par and pseq require you to designate parallelization points explicitly, which already means that the parallel processing doesn't happen automatically when I write a program. OTOH you don't have to have explicit synchronization points; but using the value of the "sparked" argument causes synchronization at some unpredictable point in time (because of laziness). That's a minor issue, though; the bigger deal is that if you choose your parallelization points unwisely, you can get bad performance (through excessive low-level synchronization) or insufficient throughput.
Data Parallel Haskell requires you to use special data structures, which also means that the parallelism also doesn't happen automatically. I either have to know beforehand where the use of DPC will actually be useful, or I'm going to have to modify an earlier program (possibly extensively) to make use of DPC.
I hadn't run into Parallel Strategies already. Thanks for pointing that one out. I need to have a look.
Are you adequate?
I run linux. When I build a kernel, I can specify how many cores get used. Symmetric multi-threading, also known by a certain companies trade name "hyperthreading", causes the number of execution threads to double (on my core i7-920 it shows up as eight). When building a kernel, it shows 8 cores all running at 100%. When compiling any other program, I can also specify how many cores, and it uses all of them fully. When rendering a blender image, I can specify how many threads Blender uses (up to a maximum of 64), and Blender seems to use them all up to a maximum of 100% each (800% total). Now I know that Linux is used a lot on computers much larger than mine. I go to sites like www.top500.org and see computers with hundreds of thousands of multi-core processors, running at the same speed as mine or faster. These machines are usually not given jobs that take more that two weeks to finish. They are not multi-user machines, but single user, single job, 10,000 processors or 40,000 cores, taking two weeks to finish (larger jobs not accepted). Now if these computers with 10000 times as much power as mine, take two weeks to finish some jobs, why is it wrong for my computer, when computing pi to 750,000,000 digits, to take nearly half an hour? It consumes nearly all of the 12GB of ram on my system to calculate it out, and with my terminal spewing as fast as it can, 45 minutes to print out the results (if I can display 13000 digits on the screen at once, thats a measly 21 screen fulls per second). I suspect the problem might be that some jobs are just large. I suspect buddy is talking about spread sheets and word processors and clippy (he's a microsoft guy after all). My commodore vic20 had really great performance. If microsoft needs to look for performance, they should look to the vic20 as a way to make their systems better. After all, windows is only at 7, and commodore was already at 20. Thats nearly 3 times as fast. You can all thank me now.
this'll hang your Explorer window for a couple of solid seconds
Not sure what you're talking about here, I haven't seen this kind of behavior in XP for a while at least.
Besides, I just attempted this, and for hosts that resolve, I am not seeing any appreciable delay between the time I press enter and the time that an anonymous ftp session begins, where anonymous ftp sessions are allowed.
For hosts that do not allow anonymous ftp, there is some delay.
For hosts that do not have port 21 open, there is no delay.
For non-resolving hosts, there is no delay and an error message pops up.