An Overview of Parallelism 197
Mortimer.CA writes with a recently released report from Berkeley entitled "The Landscape of Parallel Computing Research: A View from Berkeley: "Generally they conclude that the 'evolutionary approach to parallel hardware and software may work from 2- or 8-processor systems, but is likely to face diminishing returns as 16 and 32 processor systems are realized, just as returns fell with greater instruction-level parallelism.' This assumes things stay 'evolutionary' and that programming stays more or less how it has done in previous years (though languages like Erlang can probably help to change this)." Read on for Mortimer.CA's summary from the paper of some "conventional wisdoms" and their replacements.
Old and new conventional wisdoms:
- Old CW: Power is free, but transistors are expensive.
- New CW is the "Power wall": Power is expensive, but transistors are "free." That is, we can put more transistors on a chip than we have the power to turn on.
- Old CW: Monolithic uniprocessors in silicon are reliable internally, with errors occurring only at the pins.
- New CW: As chips drop below 65-nm feature sizes, they will have high soft and hard error rates.
- Old CW: Multiply is slow, but load and store is fast.
- New CW is the "Memory wall" [Wulf and McKee 1995]: Load and store is slow, but multiply is fast.
- Old CW: Don't bother parallelizing your application, as you can just wait a little while and run it on a much faster sequential computer.
- New CW: It will be a very long wait for a faster sequential computer (see above).
would that be (Score:5, Funny)
Would that be a Parallelograph?
Re: (Score:2, Funny)
No, more likely a Berks Eye View.
nothing new here... (Score:3, Informative)
http://vlsi.cs.berkeley.edu/cs252-s06/images/1/1b
and it's pretty much identical (check out slide 3 on the first page of the pdf)
Erlang (Score:5, Insightful)
I'm wating for a language which would parallelize stuff for you. This is most likely to be a functinal language, or an extension to an existing functional language. Maybe even Erlang.
Re: (Score:2)
This is the problem inherent with pure languages. Compilers/runtime systems are simply not sophisticated enough yet to reason about and perform as well as a human can with mutable data structures.
This is why C/C++ will dominate scalable applications for a at least few years more.
Re: (Score:3, Informative)
Haskell comes pretty close, and it's designed from the beginning to be pure.
In fact, it may be these immutable data structures that make the pure functional languages able to perform well
Java invokeLater() (Score:2)
The question or concern I have is that if one programs th
Re: (Score:2)
If you want to now where you're being in-efficient, you've got to profile, baby... Don't
Re: (Score:2)
Re: (Score:2)
Okay, I'll be more specific: they need to address syntax as a human user interface design problem.
Lisp. UI. Heh. Lisp syntax is a good user interface if sendmail.cf is. Its near lack of consistent visual cues disqualifies it completely.
Haskell is a go
Re: (Score:2)
(I realise about Lisp; I was just showing that
Re: (Score:2)
My understanding is that in a functional language io is a bitch. In order to overcome that haskell has invented impure things called monads which are notoriously hard to understand and code.
Given that virtually every computing task involved io why would you design a language that is not optimized specifically for io? Whether it's file access, network access or database access virtually every program ever written uses some io right?
Re: (Score:2)
Mercury is trying to make pure functional IO less anoying by developing syntatic sugar. That shows that functional IO can be easy, with the exception of you being oblied to declare that your functions do IO (what makes debug by printing quite hard).
Now, about the GP question of paralel compilers, I've never seen one, and don't know how hard it would be to build it. The very hard problem of breaking the program on pararelizable chuncks you get for free, but you still need to decide how many threads you'll u
Re: (Score:2)
Re: (Score:3, Insightful)
Re:Erlang (Score:5, Informative)
Re: (Score:2)
You may as well wait for a language which does everything for you.
For many problems, coming up with an algorithm for efficiently solving the
problem on multiple cores is harder than the algorithm on a single core
[eg, try parallelising a large matrix inversion etc etc].
I wouldnt expect languages to come up with algorithms as fundamental
as QuickSort any time soon [when they do, they'll be smarter than we
are, so we wont be programming at all
FP no more parallelizable than imperative (Score:2)
First of all, most functional programs do heavy use of monads (especially the IO monad) and hence they need synchronization primitives around those monads just like imperative programs.
Secondly, those parts that do not use monads still need to be executed in certain order, so there needs to be a scheduler which synchronizes the multiple cores (waiting for results and dispatching computations), which again means using semaphore
Re: (Score:2)
Never heard that one.
I think what you're getting at is:
It's easier to write correct, parallelized code in a functional language.
It's easier to write correct, parallelized code in functional languages because many threading errors come from race conditions when changing the state of some object of datastructure. Functional programming languages avoid having mutable states or datastructure. Therefore witting a race conditio
Re: (Score:2)
I can't see automatic parallelization happening for a long time. Too hard.. What I expect to see is a trend toward functional style programming.. Also maybe things like composable memory transactions.. Maybe thread based synchronization (which is a term I've been using
Re: (Score:3, Insightful)
Most of the time a computer isn't churning away on a single problem that needs to be parallelized. In that respect, the solution rests more with the operating system.
True, and in the short term I'd imagine that's where most of the improvements will appear, but context switches are expensive. It's more efficient if you can switch execution to another thread within the same context, so you can (hopefully) still use the data in your I & D caches, although you do still have a register spill/reload.
Speaking of architecture changes, it sounds like Intel is going down the same road the Alpha team did — more cacheing. I remember reading an article about one system
640k, anyone? (Score:3, Insightful)
What happens when a 1024-core server is too slow to handle 700 concurrent connections, and the only upgrade option is a 2048-core server? Then it matters whether each of those 700 requests is a parallelizable problem. Imagine a server that solves difficult computations like routing delivery traffic, designing tailored clothes from customer snapshots, monitoring security camera feeds at a cas
Re: (Score:2)
Also one may notice that many applications will see a boost in performance, even being sequential. That's because it will suffer less from context switching, since there's more than one processing core to share the load.
I can see this trend as a big win for the OpenSource OSes out there. Remember how the Linux scheduler was slow, and how Apache2 on Windows was faster? That doesn't last long, a new scheduler was written, and the Linux performance for treads got a big boost, and just kept on getting be
It's not hard (Score:5, Insightful)
I think the main reason people say "don't use threads" is because while single threaded apps are easy to debug, multi-threaded ones will crash and burn at seemingly random places if the programmer didn't plan ahead and use proper locking. This is probably good advice to a noob programmer but I otherwise can't stand people who are of the "absolutely, never, ever, use threads" mindset.
Some applications have no need to be multithreaded, but when they do it is a lot easier than people make it out to be. Taking advantage of lock-free algorithms and NUMA for maximum scalability *can* be hard, but the people who need these will have the proper experience to tackle it.
Language extensions for threading would be great, and I'm sure somebody is working on it. But until that magical threading language (maybe c++1x) comes along the current ones work just fine.
Re:It's not hard (Score:4, Interesting)
Also, the second great problem is that thread problems are hard to find. When I write a class hierarchy, an OOP language can help me with seeing design errors (for example, unnecessary multiple inheritance), or misses in const-correctness. Threading, however, is only present as mutexes, conditions etc.
One other issue with threads is that they effectively modify the execution sequence. Traditional single-threaded programs have a sequence that looks like a long line. Threading introduces branches and joins, turning the simple line into a net. Obviously, this complicates things. Petri nets can be useful in modeling this.
Re: (Score:2)
Its just opinion but I think the problem with parallel programming is a substantial lack of processors. If for example a die was made with 10 million processors on it (very simple processors) with modest queue memory, there are applications in optical data processing that would become extremely efficient and much more natural than any solutions as of this time. Otherwise we just spend our time loading the queue of one or 4 processors millions of times to do exactly the same process on the data from each
Re: (Score:2)
Re:It's not hard (Score:4, Insightful)
You could have the first thread processor split the text by white space. Then each block of characters is assigned to any number of processors to find the matching token. I've seen some parsers where the entire document was
read in, converted into an array of tokens before returning back to the calling routine.
Re: (Score:2)
Then there's that you can hardly split by whitespace with a complex syntax. You certainly won't be able to parse C like that.
Re: (Score:2)
I'm in the midst of a project that is trying to use multiple threads, and this example is not far off from the thinking that is going on; by some of the engineer who have not done MT before. Assum
Re: (Score:2)
There is a very interesting theory provided by Trefethen and Bau in Numerical Linear Algebra that the existence of exact algorithms for most of the complicated interesting matrix operations may have slowed our finding a faster
Re: (Score:2)
Obviously some operations do best as serial operations. Any process whereby we do a series of operations to one unit of data that is not done to all of the rest of the data in exactly the same way has obvious advantages being done in series. It is by definition a series of events.
To clarify, using a serial process is sort of like building a stack. You cannot add an item to a stack ahead of the item that is to precede it. If you do you break the intended order. Parallel is sort of like what could ha
Re: (Score:2)
That entirely depends on the type of problem you throw at them. After all, if computers couldn't beat our brains in certain areas, there would be no point in using them.
Re: (Score:2)
I think the main reason people say "don't use threads" is because while single threaded apps are easy to debug, multi-threaded ones will crash and burn at seemingly random places if the programmer didn't plan ahead and use proper locking.
Do the C standard and the C++ standard go into detail as to the semantics of this locking? No, they don't even specify what a thread is. This makes it less likely that students learn proper locking in college.
Language extensions for threading would be great, and I'm sure somebody is working on it. But until that magical threading language (maybe c++1x) comes along the current ones work just fine.
Which "current ones"? Do POSIX threads work on Microsoft Windows?
Re: (Score:2)
AFAIK C++0x (i.e. the next version of the C++ standard) will.
Re: (Score:2)
I don't think that's relevant. The ISO standard for Ada completely specifies the semantics of threads and thread locking, but that doesn't necessarily make the problem any easier. Of course Ada usually isn't taught in schools, but (unfortunately) C and C++ aren't usually taught in schools either,
Razor blade star NUMA NUMA yay (Score:2)
The real application domain of multi-threading and data-level parallelism is stuff that one would never run on a Windows client
New PCs have two cores and two threads per core for a total of four threads executing simultaneously. So why do over 90 percent of them run Windows? Is the killer app the ability to run apps on one processor and the GUI, antivirus, firewall on the other three?
I would also add that to program on many of the new multi-core architectures, a programmer will want to be able to specify what runs on which core.
That's called NUMA-NUMA [wikipedia.org], right?
Take for example the cell processor, where each SPE has only a 256KB local store with limited branch prediction. A miss in the store or a mispredicted branch would be catastrophic for performance. Instead, the programmer writes small specialized programs with that have minimal branching.
So how would an architecture with a large branch penalty efficiently run a spell checker, game opponent, or other things that inherently use branchy algorithms such as binary searches or tree searches?
Looking for ways to maximize cache locality/residence would be much more fruitful in terms of turn around time, though again this tends to be something which must be done explicitly and cannot be abstracted behind a programming language.
So should this b
Re: (Score:2)
Maybe we should teach the basics. I don't remember my CS program (this was '01-'05 or so) teaching anything about working with threads. Everything I know about threads and threaded programming has been picked up by reading books on threading, experimenting with threading, and what I've learned on my job from others who know threading. I'm not going to claim I'm that competent through.
What do I know about NUMA and other complex issues of thread handling and modern computers? What I know in that category cam
Parallelizing Compilers (Score:4, Insightful)
Any reproducable bug in the parallel binary will be reproducable given the same set of inputs on the sequential binary, which you can then debug as you have the corresponding sequential source code.
So why isn't this done? Automagically parallelizing compilers (as opposed to compilers that merely parallelize what you tell them to parallelize) are extremely hard to write. Until the advent of Beowulf clusters, low-cost SMP and low-cost multi-core CPUs, there simply haven't been enough machines out there capable of sufficiently complex parallelism to make it worth the cost. Simply make a complex-enough inter-process communication system, with a million ways to signal and a billion types of events. Any programmer who complains they can't use that mess can then be burned at the stake for their obvious lack of appreciation for all these fine tools.
Have you ever run GCC with maximum profiling over a program, tested the program, then re-run GCC using the profiling output as input to the optimizer? It's painful. Now, to parallelize, the compiler must automatically not just do one trivial run but get as much coverage as possible, and then not just tweak some optimizer flags but run some fairly hefty herustics to guess what a parallel form might look like. And it will need to do this not just the once, but many times over to find a form that is faster than the sequential version and does not result in any timing bugs that can be picked up by automatic tools.
The idea of spending a small fortune on building a compiler that can actually do all that reliably, effectively, portably and quickly, when the total number of purchasers will be in the double or treble digits at most - say what you like about the blatant stupidity rife in commercial software, but they know a bad bet when they see one. You will never see something with that degree of intelligence come out of PCG or Green Hills - if they didn't go bankrupt making it, they'd go bankrupt from the unsold stock, and they know it.
What about a free/open source version? GCC already has some of the key ingredients needed, after all. Aside from the fact that the GCC developers are not known for their speed or responsiveness - particularly to arcane problems - it would take many days to compile even SuperTuxKart and probably months when it came to X11, glibc or even the Linux kernel. This is far longer than the lifetime of most of the source packages - they've usually been patched on that sort of timeframe at least once. The resulting binaries might even be truly perfectly parallel, but they'd still be obsolete. You'd have to do some very heavy research into compiler theory to get GCC fast enough and powerful enough to tackle such problems within the lifetime of the product being compiled. Hey, I'm not saying GCC is bad - as a sequential, single-pass compiler, it's pretty damn good. At the Supercomputer shows, GCC is used as the benchmark to beat, in terms of code produced. The people at such shows aren't easily impressed and would not take boasts of producing binaries a few percent faster than GCC unless that meant a hell of a lot. But I'm not convinced it'll be the launchpad for a new generation of automatic parallelizing compilers. I think that's going to require someone writing such a compiler from scratch.
Automatic parallelization is unlikely to happen in my lifetime, even though the early research was taking place at about the time I first started primary school. It's a hard problem that isn't being made easier by having been largely avoided.
Re: (Score:3, Interesting)
Things you need to have support for in a language/environmen
missed the hint? (Score:2)
until that magical threading language (maybe c++1x) comes along
Studied Erlang much?
functional approaches (Score:2)
Hmmm... (Score:5, Interesting)
Then we are doing something wrong. The human brain provides compelling evidence that massive parallelization works. So: what are we missing?
Re: (Score:2)
Neurons only work on miniscule problems. Pretty much like a single gate.
Our programs are not yet capable of dividing problems into such small pieces.
Plus, so far most of our parallelization efforts are focused on optimizing software. Brains are dedicated wetware machines.
Re: (Score:2)
Re: (Score:2)
Surely someone here could enlighten us.
Re: (Score:2)
Re: (Score:2)
You have stuff like a single neuron that fires just for a specific abstract concept. Go search for "Halle Berry" neuron.
So it could be more like billions of neurons watching "Sensory Channel + Stream of Consciousness", going mostly blah and then suddenly you get one little neuron yelling "It's Halle Berry!!!".
Maybe followed by another one yelling "It's on a TV!"
And then some neuron yelling "It's neurons screaming about Halle Berry on TV!".
Then followed by maybe "Ch
Re:Hmmm... (Score:5, Funny)
Brain scalability is just not that great. Trust me, putting more than four brains in one head is just asking for locking problems out the yin-yang.
Re: (Score:2)
You are missing that our super-great brain isnt even able to calculate more than 1 or 2 additions per second.
Meaning: the parallism thats at work in our brain is absolutely useless for thinks we want to do with a computer.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
And there are lots of more important life affecting problems than visual calculations.
Like whether to go for chocolate or vanilla cake, or both. Or whether this funny smelling stuff should be eaten or not. Or whether I can make it safely up the slope. Or whether I can jump, reach that branch AND it is likely to hold me (this is not just simple visual - since you need to estimate your weight, _current_ strength factoring
Re: (Score:2)
You give an x86 computer PPC binaries and ask it to run them and they'll be slow. Your complex maths problems aren't in your brain's natural format. But anyone (experienced with driving a particular car) can tell you just how hard they'll need break to stop, or how fast they can go round that corner safely. And they can do this whilst telling thei
Re: (Score:2)
Yes, the process will involve some remembering and some calculation, but the point is completely valid: We perform much better in concrete, real-life situations than in abstractions.
Re: (Score:2)
Basically, it said the human brain was designed for algorithmic complexity, not speed. If you take a brain, and make it ten times faster, it won't be any more intelligent. It'll just take 1/10th of the time to get the same answer as it used to, it still won't be able to solve
Here is what we are missing: (Score:2)
1) the brain does not share data. Data in the brain are copied around in the form of signals.
2) the brain is not a generalized turing machine. It can only do pattern matching on images/sounds/smells/touch. Don't be fooled of our ability to do arithmetic of formulate theorems: these are the result of pattern matching as well.
Pattern matching is highly parallelizable, of course: every piece of the pattern is fed to its own 'CPU', which calculates the degree of the matc
Re: (Score:2)
Re: (Score:2)
In other words, you can not do what a Turing machine can do.
Re: (Score:2)
Re: (Score:2)
Have you see a human entering an infinite loop? I haven't.
Actually the brain does not do calculations, it simply does pattern matching. Pattern matching is not a calculation, it is statistics.
Re: (Score:2)
That depends.. In what way is the brain massively parallel?
Sure it uses many neurons but a processor has many transistors. Do I get to say that processors are massively parallel because every time I do an addition a large number of transistors are used at once; each one only doing a small part of the operation?
The amount of parallelism in the brain is most often over-stated. it's impressive but not m
LabVIEW and Parallelism (Score:4, Insightful)
Re: (Score:2)
It's a niche product meant for d
From TFA (Score:5, Funny)
Erlang: The Movie (Score:2, Funny)
I can't wait for the sequel!
Express What, Not How (Score:4, Informative)
Re: (Score:3, Insightful)
Re: (Score:2)
You just described Common Lisp.
Re: (Score:2)
Not sure if that is what you mean, and it probably isn't quite good enough, but it is perhaps the right direction?
Re: (Score:2)
It's a supercomputer perspective (Score:5, Insightful)
I just heard that talk; he gave it at EE380 at Stanford a few weeks ago.
First, this is a supercomputer guy talking. He's talking about number-crunching. His "13 dwarfs" are mostly number-crunching inner loops. Second, what he's really pushing is getting everybody in academia to do research his way - on FPGA-based rackmount emulators.
Basic truth about supercomputers - the commercial market is zilch. You have to go down to #60 on the list of the top 500 supercomputer [top500.org] before you find the first real commercial customer. It's BMW, and the system is a cluster of 1024 Intel x86 1U servers, running Red Hat Linux. Nothing exotic; just a big server farm set up for computation.
More CPUs will help in server farms, but there we're I/O bound to the outside world, not talking much to neighboring CPUs. If you have hundreds of CPUs on a chip, how do you get data in and out? But we know the answer to that - put 100Gb/s Ethernet controllers on the chip. No major software changes needed.
This brings up one of the other major architectural truths: shared memory multiprocessors are useful, and clusters are useful. Everything in between is a huge pain. Supercomputer guys fuss endlessly over elaborate interconnection schemes, but none of them are worth the trouble. The author of this paper thinks that all the programming headaches of supercomputers will have to be brought down to desktop level, but that's probably not going to happen. What problem would it solve?
What we do get from the latest rounds of shrinkage are better mobile devices. The big wins commercially are in phones, not desktops or laptops. Desktops have been mostly empty space inside for years now. In fact, that's true of most non-mobile consumer electronics. We're getting lower cost and smaller size, rather than more power.
Consider cars. For the first half of the 20th century, the big thing was making engines more powerful. By the 1960s, engine power was a solved problem, (the 1967 turbine-powered Indy car finally settled that issue) and cars really haven't become significantly more powerful since then. (Brakes and suspensions, though, are far better.)
It will be very interesting to see what happens with the Cell. That's the first non-shared memory multiprocessor to be produced in volume. If it turns out to be a dead end, like the Itanium, it may kill off interest in that sort of thing for years.
There are some interesting potential applications for massive parallelism for vision and robotics applications. I expect to see interesting work in that direction. The more successful vision algorithms do much computation, most of which is discarded. That's a proper application for many-CPU machines, though not the Cell, unless it gets more memory per CPU. Tomorrow's robots may have a thousand CPUs. Tomorrow's laptops, probably not.
Re: (Score:3, Interesting)
Basic truth about supercomputers - the commercial market is zilch. You have to go down to #60 on the list of the top 500 supercomputer before you find the first real commercial customer.
You may want to adjust your truth as your measure of the market is wrong. The Top500 is not a marketing survey and just because you have HPC hardware does mean you run out and try an get it on the Top500. Many companies are using (HPC) parallel cluster computers, but they choose to be quiet about it for competitive reason
Re: (Score:3, Insightful)
That report is negative on supercomputing. (Score:2)
That report on supercomputing doesn't indicate growth:
"Clusters have proven themselves as capable servers to handle a sizable portion of the HPC workload."
"More than half of the respondents expect their budgets for all HPC tools will decline (43%) or remain the same (17%) over the next two years."
"U.S. industrial users/buyers really want and need faster computers that fit their budgets and that don't require specialized programming skills."
Also, that study doesn't reflect "most companies". It refl
Re:It's a supercomputer perspective (Score:5, Informative)
Re: (Score:2)
It would solve the problem of software actually being able to run faster on computers that will be produced in the near future. If the status quo continues, desktop software simply won't get any faster, even when computers get faster; this seems like a real waste.
Re: (Score:2, Informative)
I also saw Dave Patterson give this talk at Stanford. RecessionCone is correct, and Dave did mention this at the Stanford talk: the whole world is going parallel, not just the supercomputer space, because chip makers can't figure out how to make chips faster sequentially. Chip makers are throwing a hail Mary pass (Dave's metaphor) by putting parallel chips out there and praying that someone can figure out how to exp
Programming 10,000 Cores (Score:3, Interesting)
Those of us that use HPC clusters (i.e. Beowulf) have been thinking about these issues as well. For those interested, I wrote a series of articles on how one might program 10,000 cores (based on my frustrations as programmer and user of parallel computers). Things will change, there is no doubt.
The first in the series is called Cluster Programming: You Can't Always Get What You Want [clustermonkey.net] The next two are Cluster Programming: The Ignorance is Bliss Approach [clustermonkey.net], and Cluster Programming: Explicit Implications of Cluster Computing [clustermonkey.net].
Comments welcome.
Check out co-array fortran.... (Score:2, Informative)
Que : Inherently Parallel Programming (Score:2, Interesting)
Actually, I've been working on a programming language/model that makes programs inherently parallel. Of course, it is quite different from anything currently in existence. Basically, it uses a queue (hence the name "Que") to store data (like the stack in FORTH), but due to the nature of the queue, programs become inherently parallel. Large programs could have hundreds of processes running at the same time, if so inclined.
If you are interested, check out my project [sourcefourge.net] (there's not much there right now), and/or
Re: (Score:2)
As a language, its design is to take interrupts and parallelism and make it part o
Berkeley View Links (Score:2, Informative)
Shared-state concurrency is harder than you think. (Score:5, Insightful)
Implement the Observer [wikipedia.org] (aka Listener) pattern (specifically the thing called "Subject" on the Wikipedia page). Your object should provide two methods, publish and subscribe. Clients can call subscribe to indicate their interest in being notified. When a client calls publish with a value, your object should pass on that value by calling the notify method on everyone who has previously subscribed for updates.
Sounds simple, right? But wait:
- What if one of your subscribers throws an exception? That should not prevent other subscribers from being notified.
- What if notifying a subscriber triggers another value to be published? All the subscribers must be kept up to date on the latest published value.
- What if notifying a subscriber triggers another subscription? Whether or not the newly added subscriber receives this in-progress notification is up to you, but it must be well defined and predictable.
- Oh, and by the way, don't deadlock.
Can you achieve all these things in a multithreaded programming model (e.g. Java)? Try it. Don't feel bad if you can't; it's fiendishly complicated to get right, and i doubt i could do it.Or, download this paper [erights.org] and start reading from section 3, "The Sequential StatusHolder."
Once you see how hard it is to do something this simple, now think about the complexity of what people regularly try to achieve in multithreaded systems, and that pretty much explains why computer programs freeze up so often.
Re:Shared-state concurrency is harder than you thi (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
There is a way to automate shared-state con/cy!!! (Score:4, Interesting)
Here is how it works:
A computation does not return a result, but a tuple of {key, continuation}. The key is used to locate the thread to pass the continuation to. The computation is stored in the thread's queue and the thread is woken up.
The tuple {key, continuation} pair can be an 64-bit value (on 32-bit machines) that consists of a pointer to a memory location (the key) and a pointer to code (the continuation).
The insertion to the thread's queue can be done using lock-free data structures.
Threads can be user-level so there need not be a switch to kernel space.
This design can allow for linear scaling of performance: the more cores you put in, the more performance you get (for algorithms that are not linear, that is). Linear algorithms would execute a little slower than usual, but the trade off is acceptable: for many applications that allow for parallelization due to having lots of (relatively) independent objects, the performance boost be tremendous.
There are many domains of applications that would benefit from such an approach:
-web servers/application servers that must serve thousands of clients simultaneously.
-video games with thousands of objects.
-simulations that have many independent agents that can run in parallel.
-GUI apps that use the observer pattern and each observable has many observers than can be notified in parallel.
Note: The above ideas are taken from libasync-mp and lock-free data structure programming.
Systems won't be so homogenius (Score:2)
What will eventually turn into an AI subsystem, will postcompile and dynamically rewrite programs to take best advantage of the system. By AI I don't mean anything sentient, just something that intelligently recognizes programming structures and patterns and rest
There is no one right answer (Score:3, Insightful)
Part of the problem, as previous posts have observed, is that most people didn't have much incentive to change, since parallel systems were expensive, and bloated, ineffeicient code would inevitably get faster thanks to the rapid improvement in single-thread performance that we enjoyed until recently. So outside of HPC and cluster apps, most parallelism consisted of decoupling obviously aynchronous tasks.
I don't think there ever will be one language to rule them all.... The right programming model is too dependent on the application, and unless you are designing a domain-specific system, you will never get people to agree. Depending on your needs, you want different language features and you make different tradeoffs on performance vs. programmability. For some applications, functional programming languages will be perfect, for others Co-Array Fortran will be, for others an OO derivative like Mentat will be, etc. And as new applications come to the fore, new languages will continue to spawn.
I think the key is to:
If one programming model does triumph, I would predict that it will be APIs that can be used equally well from C, Fortran, Java, etc., thus allowing different application domains to use their preferred APIs. And even that model is probably not compelling enough to bring them all and in the dark bind them....
what about I/O and mosix style clustering? (Score:4, Interesting)
Also, we found that sometimes, what made a deal go through was how well your proposed system could run some prexisting software. For example, vendors would publish how well they could run a standard crash test simulation.
Also, I would like to see more research put into making clustered operating systems like mosix good enough so that developers can stick to what they have learned on traditional SMP systems and have their code just work on large clusters. I don't think that multicore processors eliminate the need for better cluster software.
Use a Database (Score:2, Insightful)
Re:Sure, desktop apps may get diminishing returns. (Score:2)
Never underestimate the virus writers. (Score:2)
Never underestimate the huge quantity of virus/trojans/spywares/sony rootkits/spambots/etc. pollution that joe 6-pack will be running next to his power hungry Microsoft OS and his main office work.
16/32 cores machines could be useful for him too, so his main work (browsing for pr0n ?) won't slowdown for being constantly interrupted by the multitasking scheduler to let the huge pile of crap run
Re: (Score:2)