It seems like this is the summer of multicore panic. I can’t open a technical magazine without some pundit declaring that our current programming paradigms are useless when running on new multicore CPU architectures. Venerable analyst John Dvorak, who generally actually understands what he is writing about, coughed up this mess (with minor excisions for brevity):
Nobody wants to face the fact that Linux, Mac OS X, Microsoft Windows XP, and Vista are based on OS designs that are as old as the hills …
Meanwhile, none of these operating systems has the power to make multicore chips work as advertised. In the end, these chips are little more than novelties. Intel actually has the gall to claim that its extra cores can save power by automatically shutting down when they’re not in use. This just means they’ll be shut down most of the time. If the software could take advantage of these extra cores, there wouldn’t be any need to shut them down….
Why can’t operating systems simply dedicate extra cores to housekeeping chores and cool background tasks? It’s simple enough to work. Here are a few choice uses for core dedication. There are six of them, since we may see a six-core chip on the road ahead.
According to this piece in Wired, things are even more dire than that:
The problem is that many software applications weren’t written for chips with multiple cores, and the hardware is advancing so fast that the software runs the risk of being left behind.
“You can imagine a scenario where people stop buying laptops and PCs because we can’t figure this out,” said David Patterson, a computer-architecture expert and computer science professor at the University of California, Berkeley.
People are going to stop buying computers? Panic indeed!
Faulty Intelligence
This chorus of impending disaster reminds me of the build-up to Operation Iraqi Freedom (OIF). We’re hearing that there is a huge threat out there, and if we don’t do something quick, life is going to get real bad. Companies like Intel and Microsoft are investing in new compiler technology, other people are suggesting we need to completely change our programming paradigms. DDJ has set Herb Sutter loose with a concurrency column. Are the End of Days upon us?
But perhaps predictably, just like with OIF, the hard evidence just isn’t there. My new dual core system seems to run quite a bit faster than the machine it replaced. A similar quad core system runs even faster. Although John Dvorak seems to think those extra cores are doing nothing but enriching the electric utilities, something good must be happening. If there is trouble headed this way, it doesn’t seem to be here yet. Is it as close as some think?
The First Dose of Reality
First let’s look at the short-term predictions of doom. Dvorak says Meanwhile, none of these operating systems has the power to make multicore chips work as advertised. In fact, John is off base here. Linux, OS/X, and Windows have all had good support for Symmetrical Multiprocessing (SMP) for some time, and the new multicore chips are designed to work in this environment. Each core looks like a tightly-coupled CPU, and all of these modern operating systems are adept at using them.
Just as an example, using the spiffy Sysinternals Process Explorer, I see that my Windows XP system has 48 processes with 446 threads. Windows O/S is happily farming those 446 threads out to both cores on my system as time becomes available. If I had four cores, we could still keep all of them busy. If I had eight cores, my threads would still be distributed among all of them.
Modern programs tend to be moderately multithreaded, with individual threads dedicated to the GUI, to user I/O, to socket I/O, and often to computation. Multicore CPUs take advantage of this quite well. And we don’t need any new technology to make sure multi-threaded programs are well-behaved – these techniques are pretty well understood, and in use in most software you use today. Modern languages like Java support threads and various concurrency issues right out of the box. C++ requires non-standard libraries, but all modern C++ environments worth their salt deal with multithreading in a fairly sane way.
What Multicore Does Right
In fact, going from one core to two or four is not only not a disaster, it does a great good job of addressing one big problem with many programs: the CPU-bound thread. Good examples of threads of this variety include:
- Unzipping a 100 MB file
- Performing some complex operation on a 10 Megapixel photo
- The rendering thread in a 3D game engine
- Spreadsheet recalcuation
In the single-core days, a program that was executing a task like this would really knock a system to its knees. The O/S is generally smart enough to make sure that the CPU-bound task doesn’t get all the processor time, but the inordinate load does make it really hard for things like the UI to keep up. You’ve seen it – you have an hourglass cursor, the screen is redrawing at a .1 fps rate, and you can’t pull up a system menu to save your life.
On a multicore system, the situation gets a lot better. The task doing heavy computation might be tying up one core, but the O/S can continue running UI and other tasks on other cores, and this really helps with overall responsiveness. At the same time, the computationally intensive thread is getting fewer context switches, and hopefully getting its job done faster.
The Worst Case Future of Multicore
So two cores are better than one – nobody should be arguing that point, except possibly John Dvorak. Let’s suppose that Moore’s Law continues to apply to transistor size, and that Intel and AMD do nothing with that extra space but lay down new cores. If that’s the case, we should see a core quadrupling every three or four years.
In this future view, by 2010 we should have the first eight-core systems. In 2014, we’re up to 32 cores. By 2017, we’ve reached an incredible 128 core CPU on a desktop machine.
So what are things going to be like in 2010 with my eight-core system? First of all, it seems only natural that I’m going to have more processes with more threads running. Furthermore, with the eye-candy arms race between the three competing operating systems in full swing, you can bet there are going to be more threads that need massive amounts of CPU time. I’ll have more monitor real-estate, more pixels, and will probably have more media access. All of these things are going to tie up those eight cores just fine, using today’s programming paradigms with little or no change.
It’s a little harder to see this system scaling well to 32 cores, and at 128 cores it definitely starts to fall apart. We just aren’t going to have enough active threads on a system – many of those cores will be in Dvorak’s hypothetical idle state. So this may be when we start needing a new paradigm.
Of course, it’s pretty hard to predict the real path of both hardware and software architectures ten years out. Things like the conversion to a worldwide networked infrastructure, the universal adoption of GUI desktops, a fairly quick changeover to true multitasking operating systems were all changes that seem obvious in retrospect but weren’t so obvious a few years ahead of time.
Likewise, we speculate that silicon fabrication technologies will progress at a steady rate, but the overall architecture of desktop PCs are influenced by many unpredictable factors. And remember one thing about Moore’s law: “past performance is no indication of future returns.” Just because it has held up extraordinarily well for virtually the lifetime of IC fabrication, it was an educated guess to begin with, not a Hari Seldon-like map of future technology.
So making big changes to our software development systems based on a 10-year horizon is pretty risky.
It’s Worse Than That
Assuming we have 128-core machines in years, the doomsayers feel that we need a new, massively parallel approach to software. As much work as possible needs to be spread out among multiple CPUs.
Further, our current techniques for communicating between threads are judged to be impractical. We’re told that we need lock-free transaction systems that allow these highly distributed algorithms to communicate freely and efficiently.
Okay, if we concede that, then we have a problem.
Let me take you bake in time to my tender undergraduate days in the late 1970s at the University of Virginia School of Engineering. In a class on computer architectures, we were having a long discussion about parallel algorithms, which back then were being used on the current generation of supercomputers, such as the Cray-1. I speculated to my young and optimistic professor, Alfred Weaver, that perhaps the human mind just wasn’t cut out for designing parallel algorithms – maybe we’re just built linear. Dr. Weaver wasn’t dogmatic about this, but speculated that we didn’t really have much experience with that frame of mind, so it was too early to rule it out. He also pointed out that even if we didn’t have the ability to parallelize linear algorithms, it may well be that advanced compilers could do the job for us.
Thirty years later, I’d say programmers aren’t thinking in terms of parallelism any more than they were back then. We have separate threads of execution, but they might as well be separate tasks – not parallel distributions of one algorithm.
And of course, thirty years ago computer generated parallelism was just one of many technologies that was just around the corner. Another was artificial intelligence. And of course, continuous natural speech recognition. Ah, we were dreamers back then.
Well, artificial intelligence is still just around the corner, and some people think it may be one of those problems that we might have to concede we aren’t going to solve. Could generation of code for a massively multicore environment be just as fanciful?
Microsoft says in recent EE Times article that we’re at least ten years out from having proven compilers and computer architecture to be massively parallel. (This article gives a nice detailed roadmap of what people think we really need to do in order to take advantage of the multicore future. It’s not pretty.)
If Microsoft says something is ten years out, we know that it is either:
-
Never going to happen
Will take at least ten years
Will be done by a competitor next year
I’m inclined to believe something between the first two options. This is just a really hard problem, and if it takes ten years to get the tools ready, it’s going to be thirty years before the application base is converted. I mean, are you ready to start writing all your programs in a functional programming language? Probably not. I just learned to spell Haskell.
What, Me Worry?
So far I’ve said that we’re okay for the near term, but the far term is going to be gloomy if we have huge numbers of cores. But now I’m going to tell you that we shouldn’t be worried about the far term either. Yes, everything is going to be okay.
First and most important, Intel and AMD don’t operate in a vacuum. They are producing dual- and quad-core machines today because they give nice performance gains. Intel knows darned well that if they produced a 128-core machine today (which they could probably do, for a price) they wouldn’t sell any, because we can’t take advantage of that technology.
So Intel, AMD, Microsoft, and the other big players will be engaging in an interesting dance. Some steps will be development of new hardware, but other steps will be investments intended to pay off with new compilers, languages, and paradigms designed to work with that new hardware.
And if those investments don’t work, and the software doesn’t come through, will the world come to an end? No. Instead of jumping from 16 to 32 cores, Intel will accept smaller performance gains by cranking up clock speeds, boosting the instruction set, making bigger caches, or whatever it takes.
Conclusion
Our industry press thrives on a good crisis. The switch to multicore processors has presented the brain trust with the opportunity to drum up a convincing one, and they haven’t let us down. Just try to take it with a grain of salt. The crises we’ve had in the past have mostly been resolved with boring, step-wise evolution, and this one will be no different. Maybe 15 or 20 years from now we’ll be writing code in some new transaction based language that spreads a program effortlessly across hundreds of cores. Or, more likely, we’ll still be writing code in C++, Java, and .Net, and we’ll have clever tools that accomplish the same result.
Either way, the beat will go one.
35 users commented in " The Multicore Kerfuffle and a Dose of Reality "
Follow-up comment rss or Leave a Trackback“[...] John Dvorak, who generally actually understands what he is writing about [...]”
That was a joke, right?
Seriously, though, great article. I’m glad someone is questioning the apparently accepted wisdom that all programs must or even can be massively parallelized.
>That was a joke, right?
Well, my tongue was somewhere in my cheek. But I do have to give John a little credit. For someone who is a journalist with no apparent technical background or training, he gets his facts straight most of the time. His opinions are a different matter, they are all over the map, but it’s almost impossible to tell whether he is just saying something to increase his page rank or whether he seriously believes it.
Thanks for the kind words!
Apparently you are unaware of the Sun T2 CPU which has up to 8 cores and 8 threads per core.
Joseph, I am certainly aware that there a vast variety of multicore machines out there.
My article was pointed towards the current fuss regarding multicore on standard desktop machines.
There have been machines with scads of tightly couple processors running around for a long time, but it doesn’t really change the nature of the article.
In fact, the existence of the Sun T2 kind of proves my point. If people are actually buying and using this thing right now, where is the crisis? Maybe there isn’t one.
Good article. I pretty much feel the same way. I wrote about it here:
http://hippofondue.com/#Parallel-programming
My argument is based on the concept that we aren’t splitting single programs and running them across processors, but that we are running multiple programs, each with its own processor. Think about it, you have your code editor open, you have a database or web server running, you are listening to music and you’re compiling your code all at once. Each of these can use its own processor and you get much better results.
The 100mb file thing is bullshit. That’s all I/O I don’t care what CPU you have you’re going to be waiting on I/O with that one. Maybe if you use a crazy 7zip algorithm for compression sure but you’re talking about zip and deflate.
Also you missed the point, CPU power will increase with concurrency not necessarily with clock speed. The next intel CPU you get might just double the cores than than increase the power of what each core can do. This matters because not every problem is parallelizable and programming language support for tightly coupled parallelism is frankly piss poor.
What is it with you Windows winnies?
Stop thinking about your poor Desktop machine and think outside the box. Any decent Unix developer will fork() to dispatch concurrent load, which will use as many processors as you could give it.
I think the article does a good job of showing the fact that those other cores have something to do today: processing other threads and processes.
It is true that people with little knowledge of computing may believe those claims saying the additional cores will not be useful at all, so this article helps in clearifying that situation a bit.
The real issue here is not if the extra cores help at all but they how much they help? Much of the fuss about Erlang and cheaply parallelizing most of the computing tasks is about running a process N times faster when you drop N cores to the problem.
That’s the very situation current programming technology is definitely not good at handling. In order to at least attempt that the program flow has to allow for decomposing the problem in many tiny calculations and spreading them to many virtual calculation nodes, even with a sense of redundancy.
Doing that is not that trivial. Context switching for OS processes and threads is expensive. That’s when you need another abstraction to help: cheap processes. Erlang is gaining attention because they have incorporated all of this in their design at the language level.
I’m not advocating Erlang as THE solution. I’m mentioning it as some technology that’s showing some interesting patterns and techniques that possibly other more mainstream technologies will start to copy or use for inspiration.
We have Stackless Python and Mahlee, an Erlang-style concurrent variant of Javascript to show the beginning of that trend.
>The 100mb file thing is bullshit.
Profile it! The deflate algorithm is pretty CPU intensive, and if you are lucky enough to have a tarball created with bzip2, the situation will swing even more towards CPU and away from I/O. You can maybe get a seat-of-the-pants notion of how much time ZIP is spending in the CPU by just extracting the files from a zip, timing “cp * /var/tmp”, then unzipping to /var/tmp. Not perfect, but I think you’ll see a big difference. Without a profiler, you could do even better by creating two zip files, one with files just stored, and one with files compressed, and then compare the real-time needed to extract both of them.
But you are correct that a *significant* time is being spent blocked waiting on I/O.
>Also you missed the point, CPU power will increase with concurrency not necessarily with clock speed.
No, I understand that, and this is exactly the point I am making in my article. On a typical system with several hundred processes running at one time, it is my contention that we will see a very nice improvement in overall system performance by simply adding more cores of equal performance. Up to some magic number N.
The big question is: what is N? I think it’s got be > 16 or 32, but I have no doubt we will be there sometime in the next 10 years.
However, something that is 10 years out is probably not cause for panic – and that’s the whole point of the article.
If we want to panic about something, panic about Y2038. 31 years out, but a lot more trouble.
Thanks for reading, thanks for commenting.
Alfie said:
>What is it with you Windows winnies?
Alfie, it would be nice to avoid the ad hominem attacks.
More importantly, the overall system architecture issues between a UNIX box and Windows desktop or server aren’t all that different these days. You say:
“Any decent Unix developer will fork() to dispatch concurrent load, ”
And the response to that, of course, is that any decent Windows developer will create threads to dispatch concurrent load as well. (And I think it more likely that up-to-date UNIX and Linux developers will be using threads rather than forking processes, they gain some efficiency as a result.)
That was the whole point of my article. Modern programs fan out the load using multiple threads, and that system works pretty well. It works well for Windows apps, and it works well for Unix apps.
The panic-stricken are saying that we are going to need massive parallelization, which goes way beyond the scope of just spawning multiple threads to do multiple tasks. Instead, they are suggesting that tasks that you don’t currently think of as being amenable to parallel threads, such as your main GUI loop, need to be running on multiple cores all at once.
I think they are really imagining that even at the scope of a single line of C code we will have compilers that distribute the work in new and unique ways.
And that is so weird and new that even Microsoft says it is 10 years out.
>http://hippofondue.com/#Parallel-programming
Good points Joshua, I think we are thinking along the same lines. Thanks for commenting!
Antonio said:
>Doing that is not that trivial. Context switching for OS processes and threads is expensive.
Very true, and I wish I knew more about the research being done on that. The EE Times article I pointed to claims that all the interprocess communication has to be completely redone, with lockless data structures and communications paths. That makes sense, and will help.
I still have the deep-down feeling that humans aren’t going to do the parallelization. I think we are going to continue mentally writing our code as linear step-wise algorithms, and some clever entity will be responsible for the parallelization. (I guess this is the common view these days.)
I studied Erlang for a few weeks in a course a long time ago, but have to confess that I don’t remember having an “a-ha moment” with it. Of course, back then, the concurrency problem was a little different. Most of discussion of concurrency back in the dark ages was devoted to more loosely coupled CPUs. The exceptions where vector processors designed for heavy duty DSP, not general purpose computing.
I think you’ve neglected the important point that our industry is based heavily on component based software construction. One of the huge problems with explicit locks and threads as a means of making use of many cores is that you can’t have the kind of composable software development we have now. How can you know what, if any, locks a library or plug-in takes, and in what order? Sure you could document it – but that’s asking for trouble since we all know how much documentation gets read. It’s very hard to see how we can achieve the economics of software development we have today if our concurrency primitives are explicit threads and locks. Such low level primitives are as others have pointed out – the “assembly language of concurrency”, and outside of a ever decreasing set of problems no one writes in assembler any more unless they either have no desire to actually ship ;-)
The industry needs things like Software Transactional Memory, Active Objects and other such tools in order to enable the software factories we have today whereby large parts of systems are built by the lowest bidder and bolted together with some confidence that they’re actually going to work.
To paraphrase the comment made about Quantum Mechanics, “If you’re not worried by the issue of composable software using explicit threads and locks then you haven’t understood the problem” ;-)
I was going to write a reply, but after reading what Michael Suess had to say in his article, I figured I wouldn’t be able to produce a better argument with my limited expertise. So go ahead and read it :D
Tom, Bing,
If you read the last section “What Me Worry?”, you’ll see that I don’t disagree with the conclusion that things have to change. I have no doubt that if Intel’s processor line is dominated by 256-core CPUs in 2016, the old ways of doing business are not going to work. I tried to make that point clearly.
What I said is that this fact is not cause for panic. It is certainly a problem for people to be working on with an eye for the long term, and that is obviously happening right now.
And Tom, I agree with you. I hope the long term solution means I can write programs without using explicit threads and locks. They’re what the mainstream is stuck with today, and things work, more or less, but it’s so vulnerable to programmer error that we’re really lucky things work at all.
Is the Multi-Core Revolution a Hype?…
If you’re new here and like what you read, you may want to subscribe to my RSS blog feed or free email updates. Thanks for visiting!Mark Nelson does not believe in the hype about multi-cores. And he is right with several of his arguments. The world is…
> No, I understand that, and this is exactly the point I am making in my article. On a typical system with several hundred processes running at one time, it is my contention that we will see a very nice improvement in overall system performance by simply adding more cores of equal performance. Up to some magic number N. The big question is: what is N? I think it’s got be > 16 or 32, but I have no doubt we will be there sometime in the next 10 years.
Have you even *looked* at quad-core benchmarks? Right now, N is two. TWO!
http://www.codinghorror.com/blog/archives/000655.html
Unless *all* you do on your computer is rendering or video editing, and then N is probably eight.
Jeff,
Yes, I’ve certainly looked at those benchmarks. But if I’m not mistaken, nearly all of those are benchmarks for a single application, correct? They are not measuring overall system response.
A modern app that foolishly doesn’t make use of threading at all, such as the LAME encoder, is going to have an N value of 1. But that doesn’t mean N is 1 for your system. If the system is actively in use, those other cores will be increasing performance. (And an app like LAME has a least a crack at scaling up very well – it can subdivide the process into big independent chunks and not waste much time on synchronization.)
So while single-app benchmarks tell a story, and a good one at that, I think that a system-loading benchmark is needed to see where we really hit the wall on diminishing returns. I won’t contest somebody who argues that it is N=8 – maybe it is. I don’t have hard data, and I admit it’s an open question.
If you ARE in the mood to panic, I think the situation is grim in the short term. As an example, when I look at this stuff from Gordon Morrison, and then dig into his site, and maybe read his paper, I honestly don’t get the warm and fuzzies. As an aged procedural programmer, I get the same feeling from Haskell, F#, Erland, whatever. The change is going to be gut-wrenching.
Of course, Sweden switched their entire national road system from driving on the left to the right in 24 hours. (But if you read the fine print it actually took about a month, just a 30-1 difference.) If only changing from procedural programming, threads, and locks to some unknown parallel universe was going to be as easy!
Thanks for reading, thanks for commenting!
[...] Some of the pundits in the blogosphere have argued that we have plenty of time to get ready for the Multicore Crisis, and that all the hubub today is just hype and hand wringing. They will do projections that say it’s easy with a couple cores to just give one to the OS, save the other for the app, and see an immediate speedup. By the time there’s enough cores on a chip that this quits working, 10 years will have gone by and we’ll have all those great new tools needed to harness the big chips. There are some pretty good rebuttals for this already, BTW. [...]
[...] After spending two consecutive nights going through the implementation of Read Copy Update (RCU), both classic and preemptible, and trying to find a flaw in vain, I am kind of exhausted. And very impressed. RCU is twisted, yet so simple. I read elsewhere, that maybe the human mind wasn’t cut out for designing parallel algorithms. We tend to think in a more sequential fashion. (Probably which is why folks back in college, find linked list algorithms simpler than an RB tree!!) [...]
[...] Thinking Parallel — Mesmo para quem acha que este barulho todo sobre paralelização é só mais uma onda, não custa nada acompanhar o blog do Michael Suess. Apesar dele ser um pós-doutorando, seus textos passam longe do academiquês e costumam ser dos mais digeríveis sobre o assunto. [...]
High core count is really just saying “a whole bunch of transistors”.
Even if we don’t come up with new programming techniques to take advantage of all the cores, imagine what could be integrated into the CPU, and as a result lower the cost of computers:
Floating-Point Math Co-processor (check – done a long time ago)
North Bridge
South Bridge
Audio
2D graphics
Basic 3D graphics
Wireless
Basic amounts of memory
Networking
Directly tie in control of expansion cards to the cpu
HD video decoding/encoding
on and on and on, and more things that haven’t even been invented yet
In other words, by the time we have 128 core procs, we will also have motherboard layouts that make even the most compact laptop motherboard of today look laughably complex. And they’ll use a fraction of the power of todays laptops.
I have no fear of even thousands of cores. If we had them now, we could use them:
Continuous speech recognition
Advanced UI
3D graphics – Can always dedicate extra transistors to this and take full advantage
Home management
on and on
Think of the fluid interface of the most computationally intensive games, and now expand that to your entire computing experience.
Indeed, even in the inconceivable outcome that consumers wont have a use for huge numbers of cores, business always will. Do you really think Google, Microsoft, Yahoo, or any other computationally intensive company would hesitate if commodity 128 core processors were available today?
Indeed, I submit that many of the truly interesting problems in computing can only be addressed when we move to Massively Multi-Core CPUs. Indeed, they could be addressed with our current programming techniques.
@Abtin
Well, you know that I tend to agree with you, so I of course welcome your comment :-) And it’s true, CPU manufacturers would be well-advised when thinking of “all those transistors” to do some interesting things besides just spinning out more cores. Adding an H.264 hardware codec to every CPU would surely be a good thing, right?
Having just read a couple of panic posts to Python lists, this comes as a breath of fresh air.
When a sufficiently large number of cores become common, I would expect some video entertainments to shift from delivering 2d images (rendered from a particular viewpoint) to delivering the motion of photo-realistic 3d models that the viewer can render in super high-def from any chosen viewpoint (much like online games do now, but much better). This could easier require (or benefit from) one core per ‘actor’ or even one per body and another per head.
@T.J.:
One of the nice things about video rendering is that it is one task that already can be scaled across multiple cores to some extent – so tasks like this fit in very well with the multicore future. So our eye candy is not in peril!
[...] The Multicore Kerfuffle and a Dose of Reality [...]
Future Programming—Art or Engineering?…
The emergence of multicore computer systems—ranging from portable and desktop computers to petascale supercomputers—is placing new demands on computer software, and is catalyzing a reexamination of the fundamental methods of computer programming.
W…
Hey,
the panic about multi-core is all about single program performance: before, you knew your program would execute faster in a new processor. Now, that hardly is true.
Even if your point is about desktop users, and how more cores will bring a better experience, the truth is that a 3Ghz single-core play games faster than a newer dual-core. Because game designers didn’t make it to work multi-core? Undoubtedly, but also because it is HARD to parallelize code (in a safe way, at least).
And that’s it. So the panic is not about how to use the cores, is how to speed-up single programs with the cores (within reasonable effort).
@Xupaxupa:
No argument with what you say, my article is trying to distinguish between the words panic and problem. I just think we should be using the latter, not the former.
@Mark:
Ok, I understand your point. Let me just add that my problem with the article was that reading it, the feeling one gets is that instead of panic, we should not worry at all, and that eventually the problem will sort out by itself (when both are untrue). By “we”, I mean the people who work in the software industry.
(as a side-note, I’m running right now a VHDL synthesis that’s already occupied 14 hours of CPU time and I don’t know when will it finish. And I’m still waiting for multi-core support for these tools.)
[...] about the actual non-imminence of the end of the computing world as we know it due to multicore. Written by Mark Nelson, the article makes some relevant and mostly correct claims, as long as we keep to the desktop land that he knows best. So here is a look at these claims in [...]
[...] does not appear that everyone is developing applications that take advantage of multi-core systems. Mark Nelson wrote a great analysis of the current state of the multi-core revolutions. He has some interesting views of Intel and AMDs [...]
[...] a flaw in vain, I am kind of exhausted. And very impressed. RCU is twisted, yet so simple. I read elsewhere, that maybe the human mind wasn’t cut out for designing parallel algorithms. We tend to think [...]
That was an interesting read. My first time reading this thread.
As a man that has worked with C I’m finding my AMD Quad core very nice.
Nice to task and not worry; however, writing C programs that access all that the system can spare isn’t straight forward.
I’ll be giving this topic thought as I see programming for multi-core CPU’s is in my direct future.
I am in favor of Multi-core it’s just that 50 GHZ cores are what I dream of today.
Hey when I was a boy the idea of VHS was a dream. What Movies at home? LOL
SO where are those 10 GHZ cores I read about a while back; some place?
Ernst
The bottleneck of parallel computing is usually IO, including memory access. It cannot be solved by just adding cores.
And for computationally intensive tasks, the massively parallel approach is already there, see GPUs…
Leave A Reply
You can insert source code in your comment without fear of too much mangling by tagging it to use the iG:Syntax Hiliter plugin. A typical usage of this plugin will look like this:[c]
Note that tags are enclosed in square brackets, not angle brackets. Tags currently supported by this plugin are: as (ActionScript), asp, c, cpp, csharp, css, delphi, html, java, js, mysql, perl, python, ruby, smarty, sql, vb, vbnet, xml, code (Generic). If you post your comment and you aren't happy with the way it looks, I will do everything I can to edit it to your satisfaction.int main()
{
printf( "Hello, world!\n" );
return 1;
}
[/c]