Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Windows and Linux Not Well Prepared For Multicore Chips

timothy posted more than 5 years ago | from the until-that-invisible-hand-flexes dept.

Operating Systems 626

Mike Chapman points out this InfoWorld article, according to which you shouldn't immediately expect much in the way of performance gains from Windows 7 (or Linux) from eight-core chips that come out from Intel this year. "For systems going beyond quad-core chips, the performance may actually drop beyond quad-core chips. Why? Windows and Linux aren't designed for PCs beyond quad-core chips, and programmers are to blame for that. Developers still write programs for single-core chips and need the tools necessary to break up tasks over multiple cores. Problem? The development tools aren't available and research is only starting."

cancel ×

626 comments

Sorry! There are no comments related to the filter you selected.

The Core? (0)

Anonymous Coward | more than 5 years ago | (#27290059)

With Linux "My Kung-Fu is Strong!"

Re:The Core? (2, Interesting)

palegray.net (1195047) | more than 5 years ago | (#27290441)

Hey, at least we aren't dealing with the lovely world of Cyrix [wikipedia.org] anymore... those were truly fun times with respect to compiler optimizations (or lack thereof, as it turned out). That and the, um, heat "issues."

Re:The Core? (0)

Anonymous Coward | more than 5 years ago | (#27290879)

True, but the grandchild of the Cyrix cpu (the Nano) exonerates them, in my mind.

Adapt (3, Funny)

Dyinobal (1427207) | more than 5 years ago | (#27290067)

Give us a year maybe two.

Re:Adapt (5, Interesting)

Dolda2000 (759023) | more than 5 years ago | (#27290487)

No, it's not about adaptation. The whole approach currently taken is completely, outright on-its-head wrong.

To begin with, I don't believe the article about the systems being badly prepared. I can't speak for Windows, but I know for sure that Linux is capable of far heavier SMP operation than 4 CPUs.

But more importantly, many programming tasks simply aren't meaningful to break up into such units of granularity is OS-level threads. Many programs would benefit from being able to run just some small operations (like iterations of a loop) in parallel, but just the synchronization work required to wake up even a thread from a pool to do such a thing would greatly exceed the benefit of it.

People just think about this the wrong way. Let me re-present the problem for you: CPU manufacturers have been finding it harder to scale the clock frequencies of CPUs higher, and therefore they start adding more functional units to CPUs to do more work per cycle instead. Since the normal OoO parallelization mechanisms don't scale well enough (probably for the same reasons people couldn't get data-flow architectures working at large scales back in the 80's), they add more cores instead.

The problem this gives rise to, as I stated above, is that the unit of parallelism gained by more CPUs is to large to divide the very small units of work that exist among. What is needed, I would argue, is a way to parallelize instructions in the instruction set itself. HP's/Intel's EPIC idea (which is now Itanium) wasn't stupid, but it has a hard limitation on how far it scales (currently four instructions simultaneously).

I don't have a final solution quite yet (though I am working on it as a thought project), but the problem we need to solve is getting a new instruction set which is inherently capable of parallel operation, not on adding more cores and pushing the responsibility onto the programmers for multi-threading their programs. This is the kind of the the compiler could do just fine (even the compilers that exist currently -- GCC's SSA representation of programs, for example, is excellent for these kinds of things), by isolating parts of the code in which there are no dependencies in the data-flow, and which could therefore run in parallel, but they need the support in the instruction set to be able to specify such things.

Re:Adapt (5, Informative)

Dolda2000 (759023) | more than 5 years ago | (#27290731)

Since the normal OoO parallelization mechanisms don't scale well enough

It hit me that this probably wasn't obvious to everyone, so just to clarify: "OoO", here, stands not for Object-Oriented Something, but for Out-of-Order [wikipedia.org] , as in how current, superscalar CPUs work. See also Dataflow architecture [wikipedia.org] .

Re:Adapt (4, Interesting)

Yaa 101 (664725) | more than 5 years ago | (#27290817)

The final solution is that the processor measures and decides which part of which program must be run parallel and which are better off left alone.
What else do we have computers for?

Re:Adapt (4, Interesting)

Dolda2000 (759023) | more than 5 years ago | (#27290889)

As I mentioned briefly in my post, there was research into dataflow architecures [wikipedia.org] in the 70's and 80's, and it turned out to be exceedingly difficult to do such things efficiently in hardware. It may very well be that they still are the final solution, but until such time as they become viable, I think doing the same thing in the compiler, as I proposed, is more than enough. That's still the computer doing it for you.

Re:Adapt (5, Insightful)

tftp (111690) | more than 5 years ago | (#27290875)

To dumb your message down, CPU manufacturers act like book publishers who want you to read one book in two different places at the same time just because you happen to have two eyes. But a story can't be read this way, and for the same reason most programs don't benefit from several CPU cores. Books are read page by page because each little bit of story depends on previous story; buildings are constructed one floor at a time because each new floor of a building sits on top of lower floors; a game renders one map at a time because it's pointless to render other maps until the player made his gameplay decisions and arrived there.

In this particular case CPU manufacturers do what they do simply because that's the only thing they know how to do. We, as users, for most tasks would rather prefer a single 1 THz CPU core, but we can't have that yet.

There are engineering and scientific tasks that can be easily subdivided - this [wikipedia.org] comes to mind - and these are very CPU-intensive tasks. They will benefit from as many cores as you can scare up. But most computing in the world is done using single-threaded processes which start somewhere and go ahead step by step, without much gain from multiple cores.

Re:Adapt (5, Insightful)

Sentry21 (8183) | more than 5 years ago | (#27290883)

This is the sort of thing I like about Apple's 'Grand Central'. The idea behind is that instead of assigning a task to a processor, it breaks up a task into discrete compute units that can be assigned wherever. When doing processing in a loop, for example, if each iteration is independent, you could make each iteration a separate 'unit', like a packet of computation.

The end result is that the system can then more efficiently dole out these 'packets' without the programmer having to know about the target machine or vice-versa. For some computation, you could use all manner of different hardware - two dual-core CPUs and your programmable GPU, for example - because again, you don't need to know what it's running on. The system routes computation packets to wherever they can go, and then receives the results.

Instead of looking at a program as a series of discrete threads, each representing a concurrent task, it breaks up a program's computation into discrete chunks, and manages them accordingly. Some might have a higher priority and thus get processed first (think QoS in networking), without having to prioritize or deprioritize an entire process. If a specific packet needs to wait on I/O, then it can be put on hold until the I/O is done, and the CPU can be put back to work on another packet in the meantime.

What you get in the end is a far more granular, more practical way of thinking about computation that would scale far better as the number of processing units and tasks increases.

Fortran anticiapted out-of-order back in 1990 (1)

goombah99 (560566) | more than 5 years ago | (#27290895)

In the 80's Fortran, which stayed alive and healthy by working in the vector processor communit, got all sorts of instructions that are naturally out-of-order block processes. For example, for-loop and where-loop declarations that say the loop counter or loop array can be interated in any order. It has matrix parallel operation declarations.

Sun's fortran variant Fortress (sort of Java meets fortran) is designed from the start for thread safety so operations don't explicitly have to lock and unlock before expression.

And the new PGI fortran compiler has all sorts of compiler directives for automatic parallelization.

It's already there (3, Insightful)

wurp (51446) | more than 5 years ago | (#27290575)

Seriously, no one has brought up functional programming, LISP, Scala or Erlang? When you use functional programming, no data changes and so each call can happen on another thread, with the main thread blocking when (& not before) it needs the return value. In particular, Erlang and Scala are specifically designed to make the most of multiple cores/processors/machines.

See also map-reduce and multiprocessor database techniques like BSD and CouchDB (http://books.couchdb.org/relax/eventual-consistency).

Functional programming style is not enough (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27290749)

You need to establish/prove purity to the compiler so it can actually make use of it.

Lisp, Scala and Erlang don't have that property.

Haskell does.

Haskell and other pure languages are where the future of parallelism might lie.

Re:It's already there (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27290861)

Lisp... has a few problems "Let's take function argument evaluation, as a simple example. Because a function call in Lisp must evaluate all arguments, in order, function calls cannot be parallelized. Even if the arguments could have been computed in parallel, there's no way to know for sure that the evaluation of one argument doesn't cause a side-effect which might interfere with another argument's evaluation. It forces Lisp's hand into doing everything in the exact sequence laid down by the programmer. This isn't to say that things couldn't happen on multiple threads, just that Lisp itself can't decide when it's appropriate to do so. Parallelizing code in Lisp requires that the programmer explicitly demarcate boundaries between threads, and that he use global locks to avoid out-of-order side-effects. " - John Wiegley But yeah, functional languages can sidestep these things. Erlang, Haskell, Scalia, etc.

Re:Adapt (5, Insightful)

Cassini2 (956052) | more than 5 years ago | (#27290637)

Give us a year maybe two.

I think this problem will take longer than a year or two to solve. Modern computers are really fast. They solve simple problems, almost instantly. A side-effect of this, is that if you underestimate the computational power required for the problem at hand, then you are likely to be off by large amounts.

If you implement an order n-squared algorithm, O(n^2), on a 6502 (Apple II), if n was larger than a few hundred, you were dead. Many programmers wouldn't even try implementing hard algorithms on the early Apple II computers. On the other hand, a modern processor might tolerate O(n^2) algorithms with n larger than 1000. Programmers can try solving much harder problems. However, the programmers ability to estimate and deal with computational complexity has not changed since the early days of computers. Programmers use generalities. They use ranges: like n will be between 5 and 100, or n will be between 1000 and 100,000. With modern problems, n=1000 might mean the problem can be solved on a netbook, and n=100,000 might require a small multi-core cluster.

There aren't many programming platforms out there that scale smoothly between applications deployed on a desktop, to applications deployed on a multi-core desktop, and then to clusters of multi-core desktops. Perhaps most worrying, is that the new programming languages that are coming out, are not particularly useful for intense data analysis. The big examples of this for me are: .NET and Functional Languages. .NET deployed at about the same time multi-core chips showed up, and has minimal support for it. Functional languages may eventually be the solution, but for any numerically intensive application, tight loops of C code are much faster.

The other issue with multi-core chips, is that as a programmer, I have two solutions to making my code go faster:
1. Get out the assembly print outs and the profiler, and figure out why the processor is running slow. Doing this, helps every user of the application, and works well with almost any of the serious compiled languages (C, C++). Sometimes, I can get a 10:1 speed improvement.(*) It doesn't work so well with Java, .NET, or many functional languages, because they use run-time compilers/interpreters and don't generate assembly code.
2. I recode for a cluster. Why stop at a multi-core computer? If I can get a 2:1 to 10:1 speed up by writing better code, then why stop at a dual or quad core? The application might require a 100:1 speed up, and that means more computers. If I have a really nasty problem, chances are that 100 cores are required, not just 2 or 8. Multi-core processors are nice, because they reduce cluster size and cost, but a cluster will likely be required.

The problem with both of the above approaches, is that from a tools perspective, they are the worst choice for multi-core optimizations. Approach 1 will force me into using C and C++, which doesn't even handle threads really well. In particular, C and C++ lacks an easy implementation of Software Transactional Memory, NUMA, and clusters. This means that approach 2 may require a complete software redesign, and possibly either a language change or a major change in the compilation environment. Either way, my days of fun loving Java and .NET code are coming to a sudden end.

I just don't think there is any easy way around it. The tools aren't yet available for easy implementation of fast code that scales between the single-core assumption and the multi-core assumption in a smooth manner.

Note: * - By default, many programmers don't take advantage of many features that may increase the speed of an algorithm. Built-in special purpose libraries, like MMX, can dramatically speed up certain loops. Sometimes loops contain a great deal of code that can be eliminated. Maybe a function call is present in a tight loop. Anti-virus software can dramatically affect system speed. Many little things can sometimes make big differences.

Re:Adapt (1)

MCSEBear (907831) | more than 5 years ago | (#27290747)

One of the nice things about Apple is that they follow the philosophy of Wayne Gretzky. Gretzky says: "A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be."

With the LLVM Compiler and GrandCentral [appleinsider.com] , Apple has been working for years now on a way to better take advantage of machines with many cores. Once again, they are making a leap that Microsoft will not be able to match for many years.

Of course, with the way multicore architecture has come to the forefront, I kind of wish Be OS [wikipedia.org] had survived since it was designed to be multicore from day one. I have a feeling it's pervasively multithreaded nature would kick Apple and Microsoft's ass on modern hardware.

print page for less ads (2, Informative)

A little Frenchie (715758) | more than 5 years ago | (#27290097)

Adblock for less ads... (-1, Offtopic)

dafrazzman (1246706) | more than 5 years ago | (#27290153)

anywhere.

https://addons.mozilla.org/en-US/firefox/addon/1865

Nothing new to see here... (5, Insightful)

Microlith (54737) | more than 5 years ago | (#27290099)

So basically yet another tech writer finds out that a huge number of applications are still single threaded, and that it will be a while before we have applications that can take advantage of the cores that the OS isn't actively using at the moment. Well, assuming you're running a desktop and not a server.

This isn't a performance issue with regards to Windows or Linux, they're quite adept at handling multiple cores. They just don't need that much themselves and the applications run these days, individually, don't need much more than that either.

So yes, applications need parallelization. The tools for it are rudimentary at best. We know this. Nothing to see here.

Re:Nothing new to see here... (2, Interesting)

thrillseeker (518224) | more than 5 years ago | (#27290209)

Did you ever follow the Occam language? It seemed to have parallelization intrinsic, but it never went anywhere.

Re:Nothing new to see here... (2, Informative)

0123456 (636235) | more than 5 years ago | (#27290467)

Did you ever follow the Occam language? It seemed to have parallelization intrinsic, but it never went anywhere.

Occam was heavily tied into the Transputer, and without the transputer's hardware support for message-passing, it's a bit of a non-starter.

It also wasn't easy to write if you couldn't break your application down into a series of simple processes passing messages to each other. I suspect it would go down better today now people are used to writing object-oriented code, which is a much better match to the message-passing idea than the C code that was more common at the time.

Re:Nothing new to see here... (5, Interesting)

phantomfive (622387) | more than 5 years ago | (#27290423)

From the article:

The onus may ultimately lie with developers to bridge the gap between hardware and software to write better parallel programs......They should open up data sheets and study chip architectures to understand how their code can perform better, he said.

Here's the problem, most programs spend 99% of its time waiting. MOST of that is waiting for user input. Part of it is waiting for disk access (as mentioned in the AnandTech story [slashdot.org] , the best thing you can do to speed up your computer is get a faster hard drive/SSD). A miniscule part of it is spent in the processor. If you don't believe me, pull out a profiler and run it on one of your programs, it will show you where things can be easily sped up.

Now, given that the performance of most programs is not processor bound, what is there to gain by parallelizing your program? If the performance gain were really that significant, I would already be writing my program with threads, even with the tools we have now. The fact of the matter is in most cases, there is really no point to writing your program in a parallel manner. This is something a lot of the proponents of Haskell don't seem to understand, that even if their program is easily paralellizable, the performance gain is not likely to be noticeable. Speeding up hard drives will make more of a difference to performance in most cases than adding cores.

I for one am certainly not going to be reading chip data sheets unless there's some real performance benefit to be found. If there's enough benefit, I may even write parts in assembly, I can handle any ugliness. But only if there's a benefit from doing so.

That's a big leap (3, Insightful)

SuperKendall (25149) | more than 5 years ago | (#27290641)

If you don't believe me, pull out a profiler and run it on one of your programs, it will show you where things can be easily sped up.

Now, given that the performance of most programs is not processor bound

That's a pretty big leap, I think.

Yes a lot of todays apps are more user bound than anything. But there are plenty of real-world apps that people use that are still pretty processor bound - Photoshop, and image processing in general is a big one. So can be video, which starts out disk bound but is heavily processor bound as you apply effects.

Even Javascript apps are processor bound, hence Chrome...

So there's still a big need for understanding how to take advantage of more cores - because chips aren't really getting faster these days so much as more cores are being added.

Re:That's a big leap (0)

Anonymous Coward | more than 5 years ago | (#27290899)

Most of those problems (3d, image, video, audio) are already easy to make paraller with normal things like threads and processes. In fact my LightWave 5.6 from year 1997 is able to use up to 8 threads.

The hard thing to understand is that we do not need more processor power. There are few times when you need that full 100% oomph, but most of the time the processors hum idly in 20% or less.

Now, imagine if you could fetch that 100% oomph when needed from a server farm instead of your own computer...

Re:Nothing new to see here... (2, Insightful)

caerwyn (38056) | more than 5 years ago | (#27290761)

This is true to a point. The problem is that, in modern applications, when the user *does* do something there's generally a whole cascade of computation that happens in response- and the biggest concern for most applications is that app appear to have short latency. That is, all of that computation happens as quickly as possible so the app can go back to waiting for user input.

There's a lot of gain that can be gotten by threading user input responses in many scenarios. Who cares if the user often waits 5 minutes before input? When he *does* do something, he wants it done *immediately*. The fact that it's a tiny percentage by wall time doesn't change the fact that responsiveness here is a massive percentage of user perception.

Re:Nothing new to see here... (5, Funny)

ari wins (1016630) | more than 5 years ago | (#27290653)

I almost modded you Redundant to help get your point across.

Re:Nothing new to see here... (1)

jelle (14827) | more than 5 years ago | (#27290775)

As is tradition, I post before reading the article, but...

IMHO, It's not just that programs should be multithreaded, it's that the model of processes and threads may be too primitive, too coarse, to make full use of the available sea of cores. The concept of threads and processes that each run on one core at a time may be perfect if you're mostly core-limited, but I can think of other OS and compiler-supported paralelism that I would like to see. What if you have 64 cores/threads and only a couple of programs to run. You'll quickly have 40+ idle cores... So why not add a scheduling paradigm where you can dedicate clusters of cores to a program for a timeslice?

For example, if I would be able to tell the OS that my app would like N cores reserved and ready for me for every timeslice, then the compiler would probably be able to use parallelism at a much finer grain than threads (Perhaps with some hardware-support later on).

Nowadays, a compiler can do all sorts of optimizations, unroll loops, eliminate unnecessary calculations, etc. The core then takes the instructions and tries to run as many of them as possible, re-ordering and executing in parallel where possible.

What if my compiler would detect that I have two independent function calls, the results of which are combined after they finish. Why would the compiler then not be able to make a binary that would request 2 cores per timeslice and where core 0 would run the first function in parallel with core 1 running the other function?

Sure, the two cores won't be 100% utilized, but that second core would sit idle in the system otherwise too, and this way my program will run faster. Most likely my system will be memory-bandwidth limited before it becomes core limited.

When I try to do that with threads, I need to manually add my synchronization, plus I have to contend with scheduling latency because the OS might not allocate that second core for me on time (it has to learn about the un(b)lock/cond_signal of the thread, find an available core, switch the context, activate the thread, and the core has to load it's L1 cache, etc etc... By assigning more than one core to the process, fully dedicated to it, guaranteed to be available at a single clock cycle latency, I can make much better use of parallelism otherwise lost.

In the time of GigaHerz processors, it's not unthinkable that I would have a million of such possible parallelisms per second in a program that, with threads, would be extremely hard to parallelize.

Torvalds et al, and gcc team-members, please be inspired and take us all to the next level ;-)

Re:Nothing new to see here... (1)

palegray.net (1195047) | more than 5 years ago | (#27290833)

So yes, applications need parallelization. The tools for it are rudimentary at best. We know this. Nothing to see here.

You're right hat we've known this for quite some time now. The issue is the simple fact that this problem remains a hard one to solve, with very little real progress in the last few years, while CPU technology is continuing to pull ahead of effective tools to utilize that power. The problem is getting worse, and getting worse at an increasing rate. That's the story here, and I do consider that something worth drawing more attention to.

Just windows and linux? (0)

Anonymous Coward | more than 5 years ago | (#27290113)

get a mac..

Grand Central (3, Informative)

tepples (727027) | more than 5 years ago | (#27290197)

Anonymous Coward wrote:

get a mac..

I assume you're talking about Mac OS X 10.6 (Snow Leopard), whose Grand Central framework [wikipedia.org] is supposed to add some tools to make Mac-exclusive multithreaded apps easier to program.

Re:Grand Central (1, Flamebait)

heffrey (229704) | more than 5 years ago | (#27290499)

Vapourware

Re:Grand Central (0)

Anonymous Coward | more than 5 years ago | (#27290563)

Explain to me how the release of Snow Leopard which will include "Grand Central" is vaporware?

Re:Grand Central (1)

tepples (727027) | more than 5 years ago | (#27290651)

Mac OS X 10.6 is due in about three months, roughly a year after WWDC 2008, but I think heffrey's trying to say it's vapor until it's published.

Dolphins still missing! (1)

pm_rat_poison (1295589) | more than 5 years ago | (#27290117)

Is this just me, or is this a classic piece of non-news on a par with the one the post subject is in reference to?
I mean, isn't it a typical and completely rational technological modus operandi that hardware developments come first and software implementations take some time to emerge (with the possible exception of specialized applications)
I mean, imagine software being developed for imaginary or speculatory hardware. Sounds like a big waste of time to me...

Don't imagine. Its name was Java. (4, Informative)

tepples (727027) | more than 5 years ago | (#27290237)

imagine software being developed for imaginary or speculatory hardware.

I think Sun called it "Java". It was run on emulators [wikipedia.org] long before ARM and others came out with hardware-assisted JVMs such as Jazelle [wikipedia.org] .

Re:Don't imagine. Its name was Java. (1)

pm_rat_poison (1295589) | more than 5 years ago | (#27290339)

Yeah, there are also imaginary languages for imaginary processors like mic1 and stuff. But TFA is talking about operationg systems

Clarification please (1)

cjalmeida (1148679) | more than 5 years ago | (#27290129)

Is TFA talking about the Linux or Windows thread and scheduling not good enough for 4+ cores (so your programs no matter how good designed will not benefit from more cores), about being damn hard to split, thread and join tasks, or both?

Re:Clarification please (2)

bucky0 (229117) | more than 5 years ago | (#27290169)

I guess you could read it and find out...

seriously?

Re:Clarification please (1)

cjalmeida (1148679) | more than 5 years ago | (#27290215)

I did. And it messes things up. That's why I asked.

Re:Clarification please (0)

Anonymous Coward | more than 5 years ago | (#27290619)

You're the victim of a bait and switch. TFA doesn't even use the words "Linux" or "Windows".

Re:Clarification please (2, Insightful)

tepples (727027) | more than 5 years ago | (#27290311)

Is TFA talking about the Linux or Windows thread and scheduling not good enough for 4+ cores (so your programs no matter how good designed will not benefit from more cores), about being damn hard to split, thread and join tasks, or both?

I understood the article to refer to the latter. The programming languages that are popular for desktop applications as of the 2000s don't have the proper tools (such as an unordered for-each loop or a rigorous actor model [wikipedia.org] ) to make parallel programming easy.

Re:Clarification please (1)

godrik (1287354) | more than 5 years ago | (#27290667)

No, the article just state that most application are still single threaded.

There is no low level consideration in the article. However, there is so much things to say. I believe that the actual threading model in operating systems does not allow to reach good performances. We need a system scheduler to be aware of the computation that are done per each thread so that it optimizes the thread allocation on computational units.

The article is quite misleading. It tends to make the reader believe that almost no tools exists. However, there are a tremendous number of algorithmic techniques and software stack to deal with massively parallel environment. For most of the problems, openMP is efficient enough and it is a quite known tool. Dedicated language such as Cilk or Cilk++ were developped and they proved to be efficient and easy to use.

For most parallel part of classical applications, they can lead to good speedups. But everyone should be aware that parallelization is not only a software problem. All programs can not gain a linear speedup and parallel algorithmic is much more complicated than sequential one.

The problem is not (only) a software one.

There's a simple paradigm here (5, Interesting)

mysidia (191772) | more than 5 years ago | (#27290139)

Multiple virtual machines on the same piece of metal, with a workstation hypervisor, and intelligent balancing of apps between backends.

Multiple OSes sharing the same cores. Multiple apps running on the different OSes, and working together.

Which can also be used to provide fault tolerance... if one of the worker apps fails, or even one of the OSes fails, your processor capability is reduced, a worker app in a different OS takes over, use checkpointing procedures, and shared state, so the apps don't even lose data.

You should even be able to shutdown a virtual OS for windows updates without impact, if the apps that arise get designed properly...

How many apps per user? (1)

tepples (727027) | more than 5 years ago | (#27290371)

Multiple virtual machines on the same piece of metal, with a workstation hypervisor, and intelligent balancing of apps between backends.

But with how many apps can one user interact? I understood the article to be referring to desktop applications, not server applications. In a desktop environment, most applications spend much of their time waiting for an event. For example, a virus scanner blocks until a file is modified or a removable medium is mounted. Or are you envisioning connecting four terminals to one desktop PC and binding one virtual machine to each terminal?

Huh? (5, Funny)

Samschnooks (1415697) | more than 5 years ago | (#27290141)

...programmers are to blame for that

The development tools aren't available and research is only starting."

Stupid programmers! Not able to develop software without the tools! In my day we wrote our own tools - in the snow, uphill, both ways! We didn't need no stink'n vendor to do it for us - and we liked it that way!

Re:Huh? (1)

Jurily (900488) | more than 5 years ago | (#27290553)

Stupid programmers! Not able to develop software without the tools! In my day we wrote our own tools - in the snow, uphill, both ways! We didn't need no stink'n vendor to do it for us - and we liked it that way!

Yeah, and we've been crippled with them ever since. Also, their correctness and bug-freeness were the stuff of legends [wikipedia.org] .

P.S. I did get the joke, thank you.

The article's turning a real problem into FUD. (5, Informative)

davecb (6526) | more than 5 years ago | (#27290145)

Firstly, it's false on the face of it: Ubuntu is certified on Sun T2000, a 32-thread and Canonical is supporting it.

Secondly. it's the same FUD as we heard from uniprocessor manufacturers when multiprocessors first came out: this new "symmetrical multiprocessing" stuff will never work, it'll bottleneck on locks.

The real problem is that some programs are indeed badly written. In most cases, you just run lots of individual instances of them. Others, for grid, are well-written, and scale wonderfully.

The ones in the middle are the problem, as they need to coordinate to some degree, and don't do that well. It's a research area in computer science, and one of the interesting areas is in transactional memory.

That's what the folks at the Multicore Expo are worried about: Linux itself is fine, and has been for a while.

--dave

Re:The article's turning a real problem into FUD. (1)

m1ss1ontomars2k4 (1302833) | more than 5 years ago | (#27290187)

I dunno, I'm not feeling particularly fearful or doubtful after reading the article.

Re:The article's turning a real problem into FUD. (4, Funny)

cowbutt (21077) | more than 5 years ago | (#27290291)

I dunno, I'm not feeling particularly fearful or doubtful after reading the article.

The articles has, apparently, sown Uncertainty in you, however, so it was 33.3% successful.

Re:The article's turning a real problem into FUD. (1)

Samschnooks (1415697) | more than 5 years ago | (#27290297)

The real problem is that some programs are indeed badly written. In most cases, you just run lots of individual instances of them. Others, for grid, are well-written, and scale wonderfully.

The article refers to applications programmers so I am assuming you mean applications when referring to "programs".

Dealing with multiple cores is the operating system's problem - not the application's. If the programmer uses multiple threads or processes, then it should be the OS that worries about allocating resources among the cores.

Re:The article's turning a real problem into FUD. (2)

tepples (727027) | more than 5 years ago | (#27290629)

Dealing with multiple cores is the operating system's problem - not the application's. If the programmer uses multiple threads or processes, then it should be the OS that worries about allocating resources among the cores.

But the problem of TFA is that desktop applications don't use enough threads or processes. If the programmer hasn't split an application into multiple threads or processes, then there usually isn't more than one thread of one process that wants to run at any given time, and there is nothing for the operating system to schedule.

Re:The article's turning a real problem into FUD. (1)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#27290401)

Firstly, it's false on the face of it: Ubuntu is certified on Sun T2000, a 32-thread and Canonical is supporting it.

Actually, the article talks about application development tools for various OS's and their poor support for creating good, multithreaded applications for Linux or Windows. I didn't see much in the way of complains about the OS using the CPUs, just about the ability of applications to do so given the current toolset.

I think OS's can do more to make multi-cores work better with existing software. For example, OS X can take any OpenGL program and spawn a thread for feeding data to the GPU, without the software having been rewritten to accommodate that change. In this way some existing applications can theoretically be twice as fast when running on a multi-core system. That sort of innovation at the OS level is as important as changes to developer tools for the transition to larger numbers of cores.

Article not as bad as summary (1)

Protoslo (752870) | more than 5 years ago | (#27290151)

The article doesn't really say that Windows and Linux aren't "designed" for quad+ core chips; it just says that most software is still single threaded. No kidding.

Example: Scripting Languages (3, Interesting)

mcrbids (148650) | more than 5 years ago | (#27290175)

Languages like PHP/Perl, as a rule, are not designed for threading - at ALL. This makes multi-core performance a non-starter. Sure, you can run more INSTANCES of the language with multiple cores, but you can't get any single instance of a script to run any faster than what a single core can do.

I have, so, so, SOOOO many times wished I could split a PHP script into threads, but it's just not there. The closest you can get is with (heavy, slow, painful) forking and multiprocess communication through sockets or (worse) shared memory.

Truth be told, there's a whole rash of security issues through race conditions that we'll soon have crawling out of nearly every pore as the development community slowly digests multi-threaded applications (for real!) in the newly commoditized multi-CPU environment.

Re:Example: Scripting Languages (1)

mcrbids (148650) | more than 5 years ago | (#27290223)

PS: Strikes me that this is a good time for us to truly develop cross-core, cross-system, and cross-cluster application development by unifying cross-thread, cross-core, and cross-system communications under a common API.

Really, as a clustered application developer, why should I have to worry about where a process runs, on what server? The POSIX process scheduler should be extended to run applications on the cluster with the SAME API as launching a thread.

It's stupid that I have to think about all the details when all I want is:

A) X done.
B) In another process/thread.

Somebody who "gets" this could make a pretty serious dent ini the marketplace!

Re:Example: Scripting Languages (1)

DrSkwid (118965) | more than 5 years ago | (#27290335)

Forking is only expensive in your environment because of shared libraries.
Static compilation ftw.

Re:Example: Scripting Languages (1)

profplump (309017) | more than 5 years ago | (#27290901)

What exactly makes forking so expensive with shared libraries? The code segment shouldn't be duplicated for shared or static libraries, and shared libraries have the benefit of only be loaded once per system, rather than once per program. Is there some important step I'm missing?

Re:Example: Scripting Languages (5, Interesting)

dansmith01 (1128937) | more than 5 years ago | (#27290695)

Perl has excellent support for building threaded applications. See http://perldoc.perl.org/threads.html [perl.org] . I code multi-threaded apps in perl all the time and they utilize my quad-code very efficiently - in fact, my biggest hassle with multithreading is keeping the CPU cooled! There's also a threads::shared module (http://perldoc.perl.org/threads/shared.html) for handling locks, etc. I'd be hard pressed to imagine better language support for threading. Hardware, operating systems, and a lot of languages support threading. Granted, it isn't always easy/possible/worth it, but as things currently stand, the only bottleneck is programmers who are too lazy to design their algorithms for parallel execution.

Re:Example: Scripting Languages (1)

godrik (1287354) | more than 5 years ago | (#27290737)

well, you could rely on parallel libraries that do the job in parallel, or even using asynchronous function call as in cilk, or athapascan. However, I am not sure applications written in scripting languages are the one looking for using multi core architectures...

How many tools do you need? (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27290185)

"The development tools aren't available and research is only starting"

Hardly. Erlang's been around 20 years. Newer languages like Scala, Clojure, and F# all have strong concurrency. Haskell has had a lot of recent effort in concurrency (www.haskell.org/~simonmar/papers/multicore-ghc.pdf).

If you prefer books there's: Patterns for Parallel Programming, the Art of Multiprocessor Programming, and Java Concurrency in Practice, to name a few.

All of these are available now, and some have been available for years.

The problem isn't that tools aren't available, it's that the programmers aren't preparing themselves and haven't embraced the right tools.

Re:How many tools do you need? (0)

Anonymous Coward | more than 5 years ago | (#27290541)

Instead(in the server side front) we see all this hype for Ruby on Rails which for my understanding doesn't even support native threads.

Scala actors pwnz.

Re:How many tools do you need? (1)

julesh (229690) | more than 5 years ago | (#27290831)

"The development tools aren't available and research is only starting"

Hardly

Exactly what I was here to post. I mean, it's not like parallel computation is anything new. The concurrent programming lab at my university was the most important research division when I was back there in the early 90s. And they'd spent real cash on it, too... they had a transputer [wikipedia.org] and everything.

BeOS (5, Interesting)

Snowblindeye (1085701) | more than 5 years ago | (#27290191)

Too bad BeOS died. One of the axioms the developers had was 'the machine is a multi processor machine', and everything was built to support that.

Seems like they were 15 years ahead of their time. But, on the other hand, too late to establish an other OS in a saturated market. Pity, really.

Re:BeOS (2, Informative)

yakumo.unr (833476) | more than 5 years ago | (#27290515)

So you missed Zeta then ? http://www.zeta-os.com/cms/news.php [zeta-os.com] (change to English via the dropdown on the left)

Re:BeOS (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27290805)

Haiku and Syllable are pretty much trying to continue the model that BeOS used, where threading is heavily used and threads communicate via. high level message passing.

Multicore not designed for the real world (1)

stox (131684) | more than 5 years ago | (#27290211)

Yes, some problems lend themselves very well to multicore designs. Many others do not. Just because they are building multicore ships does not mean that multicore is the right answer. Current multicore designs have too small cache, and too slow memory bandwidth. If my problem is CPU bound, multicore can be a solution. If my problem is memory access bound, multicore is only going to make it worse.

Not all programmers need threading (1)

js3 (319268) | more than 5 years ago | (#27290213)

The idea that every program needs to support threading is kinda stupid. Most programs barely use any computational power, in fact there are very few programs that require all that computing power to operation and those are certainly well designed.

Some tasks are embarrassingly parallel (4, Informative)

tepples (727027) | more than 5 years ago | (#27290439)

Most programs barely use any computational power, in fact there are very few programs that require all that computing power to operation and those are certainly well designed.

Home users do use some apps that could benefit from multiple cores. Video encoding is one of them, but that one is embarrassingly parallel because the encoder could just split the video into quadrants and have each of four cores work on one quadrant.

Re:Not all programmers need threading (0)

Anonymous Coward | more than 5 years ago | (#27290481)

I think that you are right, with some exceptions such as web browsers and games.

Web browsers need to run a s-load of applications inside itself, sort of like an operating system.

Impressive games need all the resources they can get (otherwise they would probably not be impressive) but it is fairly difficult to analyze the program before it is made to find the optimal parallelization strategy and to realize that strategy in code.

Re:Not all programmers need threading (1)

tepples (727027) | more than 5 years ago | (#27290715)

Impressive games need all the resources they can get (otherwise they would probably not be impressive) but it is fairly difficult to analyze the program before it is made to find the optimal parallelization strategy and to realize that strategy in code.

The critical path as I understand it is input => physics => graphics and sound. Are modern impressive games bottlenecked in physics or in the CPU side of graphics?

Re:Not all programmers need threading (1)

0123456 (636235) | more than 5 years ago | (#27290835)

Are modern impressive games bottlenecked in physics or in the CPU side of graphics?

Do you really think that game developers wouldn't like to include a vastly more sophisticated physics or AI engine if the CPU could handle it?

Well, maybe... (1)

windsurfer619 (958212) | more than 5 years ago | (#27290247)

Maybe I'm just not a multicore user. Ever thought of that?

Another flamebait story by timothy (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27290259)

The quote presented in the summary is nowhere to be found in the linked article. To make matters worse, the summary claims that linux and windows aren't designed for multicore computers but the linked article only claims that some applications are not designed to be multi-threaded or running multiple processes. Well, who said that every application under the sun must be heavily multi-threaded or spawning multiple processes? Where's the need for a email client to spawn 8 or 16 threads? Will my address book be any better if it spans a bunch of processes?

The article is bad and timothy should feel bad. Why is he still responsible for any news being posted on slashdot?

Message classification (1)

tepples (727027) | more than 5 years ago | (#27290459)

Where's the need for a email client to spawn 8 or 16 threads?

Message classification. An e-mail client could open a process for each message, and the process would analyze the message to see what labels (spam, work, personal, etc.) belong on the message. If you get a lot of mail, I imagine that classifying several hundred downloaded messages might take a while.

Re:Another flamebait story by timothy (1)

godrik (1287354) | more than 5 years ago | (#27290813)

Where's the need for a email client to spawn 8 or 16 threads?

well, one of the goal of multi core architecture is to reduce the energy consumption. 2 cores at 2Ghz cost less energy than 1 core at 2Ghz.

The question is not how many thread should an application launch. Threads are just here to exploit the parallelism of the machine. There will be more thread to transform 2 cores at 2Ghz into 4Ghz of computational power. If you don't need such power (who needs a 4Ghz computer to write some mail), then the multi-core architecture can be downclocked to reduce the energy consumption. Same performance but better efficiency.

BS (0)

Anonymous Coward | more than 5 years ago | (#27290289)

What good are multiple cores and threads when you are running event driven GUI application? Some applications, especially Java applications, already use too many unnecessary threads. Inciting threads use where it is unnecessary is stupid. There is only a limited space for parallelism in any algorithm.

Also, "...research is only starting." What BS is this? Multiprocessing and multithreading issues are being researched and solved several decades now.

Why a web browser needs threads (4, Insightful)

tepples (727027) | more than 5 years ago | (#27290531)

What good are multiple cores and threads when you are running event driven GUI application?

Mozilla Firefox is an event-driven GUI application. But if I open a page in a new tab, a big reflow or JavaScript run in that page can freeze the page I'm looking at. You can see this yourself: open this page [slashdot.org] in multiple tabs, and then try to scroll the foreground page. If Firefox used a thread or process per page like Google Chrome does, the operating system would take care of this. Other applications need to spawn threads when calling an API that blocks, such as gethostbyname() or getaddrinfo(); otherwise, the part of the program that interacts with the user will freeze. But these are the kind of threads that are useful even on a single core, not multicore-specific optimizations.

Re:Why a web browser needs threads (-1, Troll)

noamsml (868075) | more than 5 years ago | (#27290873)

Chrome.

Really? (1)

Darkness404 (1287218) | more than 5 years ago | (#27290303)

Who would have ever guessed that most software is single-threaded rather then multi-threaded, and the programmers of Linux and Windows don't really feel like optimizing everything for 8-core CPUs that won't be released for quite some time and won't end up in the average user's box for 3 or more years.

Parallel programming is hard, film at 11. (5, Informative)

Troy Baer (1395) | more than 5 years ago | (#27290411)

The /. summary of TFA is almost exquisitely bad. It's not Window or Linux that's not ready for multicore (as both have supported multi-processor machines for on the order of a decade or more), but rather the userspace applications that aren't ready. The reason is simple: Parallel programming is rather hard, and historically most ISVs have haven't wanted to invest in it because they could rely on the processors getting faster every year or two... but no longer.

One area where I disagree with TFA is the claimed paucity of programming models and tools. Virtually every OS out there supports some kind of concurrent programming model, and often more than one depending on what language is used -- pthreads [wikipedia.org] , Win32 threads, Java threads, OpenMP [openmp.org] , MPI [mpi-forum.org] or Global Arrays [pnl.gov] on the high end, etc. Most debuggers (even gdb) also support debugging threaded programs, and if those don't have enough heft, there's always Totalview [totalview.com] . The problem is that most ISVs have studiously avoided using any of these except when given no other choice.

--t

Re:Parallel programming is hard, film at 11. (4, Insightful)

klossner (733867) | more than 5 years ago | (#27290443)

In fact, TFA doesn't even use the words "Linux" or "Windows."

There may be a reason for that too (1)

G3ckoG33k (647276) | more than 5 years ago | (#27290631)

'In fact, TFA doesn't even use the words "Linux" or "Windows."'

Yup. There may be a reason for that too.

The initial SMP support was added to Linux 1.3.42 on 15 Nov 1995. Linux is clearly well adapted to multicore CPUs. That is one of the reasons why Linux dominates over Windows on www.top500.org. The other argument is cost.

Multithreaded applications not always needed (2, Insightful)

Pascal Sartoretti (454385) | more than 5 years ago | (#27290431)

Developers still write programs for single-core chips and need the tools necessary to break up tasks over multiple cores.

So what? If I had a 32 core system, at least each running process (even if single-threaded) could have a core just for itself. Only a few basic applications (such as a browser) really need to be designed for multiples threads.

Most undergrad programs focus on single-threaded (1)

mrflash818 (226638) | more than 5 years ago | (#27290453)

When I was studying Comp Sci, I recall that most assignments were to 'understand the concept' and program a solution.

Usually the programs were single-threaded. Maybe a section of a course was on concurrency (mutexes, threading), but not an entire course or courses.

As multi-core becomes more the norm, then perhaps there can be an entire course on concurrency and how to design/program with this thinking in mind.

Anonymous Coward (0)

Anonymous Coward | more than 5 years ago | (#27290455)

This canard will not fly! In the 1980's we and many others were profitably using shared-memory processors (discrete versions of multi-core chips), 20 CPUs in a Sequent Balance, in my case. We used high-level languages and sophisticated library support.

The success then was because processor and memory speeds were "balanced," now wildly imbalanced. It's an architectural problem that has not been solved by huge, multi-level caches. For a simple explanation of why, try the classic "Htting the Memory Wall: Implications of the Obvious" (www.cs.virginia.edu/papers/Hitting_Memory_Wall-wulf94.pdf).

Split-phase memory operations have been shown to help, but that innovation must be tied to hardware-supported multithreading.

Would be great, but only for a few things. (1)

Nakor BlueRider (1504491) | more than 5 years ago | (#27290495)

This is a problem, but one specific only to certain programs. Pull up task manager, and take a look at the processes list. Odds are unless you're running something big in the back ground, you won't see any process taking up more than 50% CPU on your dual-core, or 25% CPU on your quad core. In fact, odds are none will be even close to that.

Multi-threading can offer little speed increase there (there is theoretically some as code is executed simultaneously, but it's negligible and probably unnoticeable); its value is only truly seen is when a program can actually make use of more processor power than any single core has. Video conversion is a good example -- on my dual core at home, most of my video conversion tools hit 50% CPU and run at that until done. It's programs like this that can take advantage of multi-threading and therefore having access to more raw processing power at once (double, in fact).

I agree that it would be nice to see more tools out there to add ease to coding for multi-core processors, and to see those few, CPU intense programs suddenly see double the processing power. But given that only a very specific selection of software requires it, and moreover a lot of the time that is not software the "average joe" would be using, it's probably just not vital enough to hit the priority lists yet (especially given that there are a few programs out there that do successfully implement multi-threading, and others that mimic it to a lesser extent).

blah (0)

Anonymous Coward | more than 5 years ago | (#27290557)

Wait, what? Sorry, the windows kernel might indeed not be prepared for large multicore systems (IIRC a 64-proc limit), but linux ALREADY RUNS most of the world's large HPC systems - some of which are clusters, but some of which are enormous SMP machines - linux runs 1024-proc SGI machines, for example. Linux has O(1) scheduling, good NUMA support, and can handle many, many cores already very well.

Of course the article has nothing to do with that, but rather userspace.

But even there, while multicore is new to the bulk of developers and there's a lot of wheel-reinvention going on, the HPC world has been doing parallel programming for DECADES. It's not new, the techniques are well known.

And just look at a typical linux (or windows) box - it's running quite a few concurrent processes already. Individual applications might not be parallelised, but having multicore sure helps when I want to leave amarok playing in the background while I play sauerbraten while I have bittorrent going.

multithreading not even in C or C++ (0)

Lord Lode (1290856) | more than 5 years ago | (#27290569)

There's not even a way in the C or C++ core language to start a new thread. And with many different third party libraries, there'll never be a reliable standard way to do it. Multithreading is great and everything, but if even such a popular programming language doesn't allow it, how am I supposed to produce programs for 8-core CPU's?

Re:multithreading not even in C or C++ (1)

julesh (229690) | more than 5 years ago | (#27290891)

I believe Boost supports multithreading, and is considered a semi-standard for C++ development these days; in fact, I understand that the next version of the C++ standard will incorporate a number of libraries from Boost. Not sure if the threading library is one of them, though.

Research starting? (1)

iliketrash (624051) | more than 5 years ago | (#27290587)

"... and research is only starting."

Hmmm... I remember people doing research on this subject at the University of Illinois when I was a graduate student there in the 1980s.

Article = -1 Flamebait (3, Insightful)

tyler_larson (558763) | more than 5 years ago | (#27290597)

If you spend more time assigning blame than you do describing the problem, then clearly you don't have anything insightful to say.

Virtualization (1)

fermion (181285) | more than 5 years ago | (#27290605)

I have tried to do some stuff for cray, so i know how hard it is to write these types of applications. But someone correct me if i am wrong, but i thought the solution was virtualization. We know most applications can run on a modest chip. The issue is that if one is running several processes, the chip has to save state, run the new process, save state, restore state, and the run the old process. This happens many times a second, and everything is so fast, we most of the time don't notice. I am watching a movie, writing this, and running a GUI all on the same machine. I don't notice any delays.

However, there is an issue of overhead with switching, and it seems like running specific processes on specific cores would do enough to help here. I don't see why the average application needs run on more thane one core. It seems like the OS can assign a core a process, and there would no issue beyond the current multithreading.

Now, like the stuff written for the cray, there is some applications could take advantage of the parallel processing, but I don't see a general need for this. It would be like the original Mac where certain processes weree shifted to the graphics processor by the OS. Not that programs are not going to written differently, but this will happen over time. DOS applications did not become full fledged window applications over night.

Rub belly and pat head. Now do what else? (1)

tepples (727027) | more than 5 years ago | (#27290825)

So you're watching a movie and writing a Slashdot comment. How many other things can you do at once that would require a core? Even if you have 30 other processes open, most of them would just be waiting for input. There's a limit on the tasks that a single human being can care about at once, and Microsoft doesn't appear ready to bring terminal servers to the home market.

Not many apps are made for multicore! (1)

Vexorian (959249) | more than 5 years ago | (#27290663)

However, it is not like they need to. I think the most benefit multi core can give is the ability to run much more applications in paralel, and not that much the optimization for a single application. Both windows 7 and Linux (for a longer time) have supported multicore quite well, and there ARE tools/languages that make multi threading more friendly. However, we don't use them, perhaps because besides of the logical uses for threads, it is rarer to focus on multi-cores optimize stuff unless you are doing some really speed-critical task which is not something that home apps do that often... However at home multicore can still be alot of help even without apps using it.

Being able to burn a DVD while encoding a video and playing some game all at the same time, is something that benefits from extra cores and does not require the apps themselves to know about the cores. Of course, this is not the most common situation - Perhaps the IT world is starting to realize home/office don't really need as much power? Even since 5 years ago MS was the only force driving us to require more power upgrades, but now with even them focusing for performance in windows 7, perhaps it is going to be the "year of Moore's law no longer relevant in the desktop"

Re:Not many apps are made for multicore! (1)

tepples (727027) | more than 5 years ago | (#27290857)

Being able to burn a DVD while encoding a video and playing some game all at the same time, is something that benefits from extra cores

Burning a DVD is I/O bound. Playing a game is user input bound. Encoding a video is the one task of the three that looks CPU bound, but that benefits from multiple cores only because each core can work on 1/4 of the video.

Here we go again (1)

Seth Kriticos (1227934) | more than 5 years ago | (#27290679)

So here we are at the multiprocessing dilemma again. The summary gets it all wrong. It is referring to operating systems, which are fine with this kind of stuff. UNIX and derivate (Linux) systems were fine with multiprocessing for decades. Most of the big irons in the top 500 are running multi-core just fine. Even Windows got the hang out of it lately (I guess).

The problem is, that most application developers did not learn to wrap their minds around the multiprocessing paradigm. No tool can magically design your single threaded application to work multi-threaded. The developer needs to analyze the program flow, export computationally expensive operations to separate threads and manage to get a good junction control (locks, balanced threading). It's a design paradigm that has to be learned.

Problem is, that you can't get developers that are not used to the idea of multiprocessing paradigms to switch. Another problem is, that exactly this group of people is also teaching the new generation, so it is not going to change that fast either.

It's a bit like a chicken and egg problem: until there is no large distribution of multi-core systems, no one will have the urge to switch. So that's why it is a good thing that this new CPU's get out. Once they are there, developers will derive the need to utilize them to stay competitive. Kind of like natural selection and adoption of new environments.

Isn't exactly rocket science (well, except if you are writing a rocket guidance system).

what kind of fanboy wrote that article? (1)

DragonTHC (208439) | more than 5 years ago | (#27290725)

He says Windows and Linux but spuriously leaves out Mac?

mac suffers from the same damn problem. The OS and most apps weren't written for multi-core processors.

that's why any true multi-core app is distributed. hence rendering farms, not rendering server.

Should I feel shame? (1)

blake182 (619410) | more than 5 years ago | (#27290757)

I've been programming for 30 years or so, and I've been feeling ashamed. I've been feeling like I've done something wrong and that I haven't structured my programs right. That if only I was smart enough I would be able to take advantage of these multicore systems.

But I think I'm feeling better about myself. If I write rational multithreaded programs and use scalable patterns like producer / consumer, then I'll be pretty much ready to go.

And it seems like a lot of this isn't really relevant for desktop applications. I mean, there's some amount of keeping the main event thread moving so that your application is responsive, and you do time consuming operations on separate threads. But the only time I've really used a whole lot of threading is in server apps where you have a whole bunch of incoming connections that you're processing concurrently.

I understand that there is a branch of computer science that surrounds parallel computing, and there are some applications that might benefit from this (image processing being the canonical example). But I think it's another tool in the toolbox. Another way to approach a problem like map / reduce or whatever is in vogue. Some problems will benefit from being solved this way. Some won't. Use the right tool.

And I don't understand why we need to beat the drum for more efficient use of multicore. It's cool, we'll figure out what to do with all these cores. And then we'll put that in our toolbox and use it when appropriate.

No, you shouldn't feel ashamed? (1)

G3ckoG33k (647276) | more than 5 years ago | (#27290849)

"And I don't understand why we need to beat the drum for more efficient use of multicore."

Huh? It is really simple. Because the industry wish to perpetuate a need for new products, whether we need them for the moment or not.

In the meantime, maybe some dude may discover the next killer-application which could actually harness the power at hand.

Very few pc programs can make the latest quad cores crawl. They typically handle anything you throw at them. Even most 3D games are swallowed.

So, accept it. The progress is there. If not for the need, so at least because of marketing and market shares.

Who in their right mind would by an inferior product, e.g. a CPU, if the competitor was cheaper and faster and consumed less power?

.

Not tools, developers (3, Insightful)

Todd Knarr (15451) | more than 5 years ago | (#27290827)

Part of the problem is that tools do very little to help break programs down into parallelizable tasks. That has to be done by the programmer, they have to take a completely different view of the problem and the methods to be used to solve it. Tools can't help them select algorithms and data structures. One good book related to this was one called something like "Zen of Assembly-Language Optimization". One exercise in it went through a long, detailed process of optimizing a program, going all the way down to hand-coding highly-bummed inner loops in assembly. And it then proceeded to show how a simple program written in interpreted BASIC(!) could completely blow away that hand-optimized assembly-language just by using a more efficient algorithm. Something similar applies to multi-threaded programming: all the tools in the world can't help you much if you've selected an essentially single-threaded approach to the problem. They can help you squeeze out fractional improvements, but to really gain anything you need to put the tools down, step back and select a different approach, one that's inherently parallelizable. And by doing that, without using any tools at all, you'll make more gains than any tool could have given you. Then you can start applying the tools to squeeze even more out, but you have to do the hard skull-sweat first.

And the basic problem is that schools don't teach how to parallelize problems. It's hard, and not everybody can wrap their brain around the concept, so teachers leave it as a 1-week "Oh, and you can theoretically do this, now let's move on to the next subject." thing.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?