Summary
Java's write-once-run-anywhere promise has insulated developers from most changes in processor architecture. The popularity of multi-core processors, however, will bring to the fore the intricacies of writing concurrent applications, according to UK-based TechWorld.
Advertisement
Multi-core processors are becoming the norm both on personal computers and servers, with significant challenges to developers, according to UK-based TechWorld magazine. TechWorld recently featured the impact of multi-core CPUs on developers, Multi-core chips provide power but make development tough, pointing out that 85 percent of servers and 70 percent of desktops using Intel processors will be multi-core by the end of this year.
While dual-core processors are currently shipping in new Intel-based Macs and in PCs, many more cores will soon become available on both server and desktop machines. The article quotes Microprocessor Report analyst Tom Halfhill,
In five years, microprocessor chips in servers will have eight to 16 cores, and desktop machines will have half that number. And ... each core will be able to process at least four software threads simultaneously, a technique Intel calls hyperthreading.
Advances in compiler design have insulated most developers from changes in CPU architectures, and Java developers enjoyed the additional benefit of a fairly homogeneous execution environment offered by the JVM. Multi-core CPUs, however, will make parallelism explicit, presenting three challenges that few developers have experience with, according to James Reinders, a director with Intel's software development program:
The first is scalability—how to keep each additional processor busy. A threefold performance boost on a four-processor system is "darn good" ... anything more is "exceptional."
The second challenge is "correctness"—how to avoid race conditions, deadlocks and other bugs characteristic of multi-processor applications. Intel's Thread Checker can find threads that share memory but do not synchronise, which ... "almost always [indicates] a bug."
The third challenge is "ease of programming" ... modern compilers can help by finding and exploiting opportunities for parallel processing in source code. The programmer can help the compiler by including "a few little hints" in the code...
The Java concurrency utilities in JDK 1.5 have already added programming constructs that provide such "hints," and modern JVMs should be able to leverage those hints in order to let Java code take advantage of on-the-chip concurrency. However, the extent to which JVMs can mask the intricacies of ubiquitous concurrency may be limited in at least following ways highlighted in the article:
Testing for race conditions. The article quotes Jim Larus, manager of programming languages and tools at Microsoft Research:
A lot of the techniques we have used with sequential code don't work as well, or at all, with parallel programs... In testing, you typically run your program with a lot of data, but with parallel programs, you could run your program 1,000 times with the same data and get the right answer, but on the 1,001st time, an error manifests itself.... This ugly trait results from race conditions in parallel code, in which one process is expected to finish in time to supply a result to another process—and usually does. But because of some anomaly such as an operating system interrupt, occasionally it does not. Such bugs can be extremely hard to find because they are not readily reproducible.
New architectures that combine both distributed parallelism, in the form of clusters, and on-chip parallelism, where the bandwidth and latency between processing components will be non-uniform:
Rice University's [computer science professor Ken] Kennedy predicts ...hybrid systems consisting of clusters of computers running multi-core processors. "Then you have two kinds of parallelism: cross-chip parallelism, perhaps with message passing and a shared memory, and on-chip parallelism," he says. Functions that require very high inter-processor bandwidth can be put on a CMP, and those that don't can be distributed across the cluster.
Rising user expectations. As multi-core CPUs become the norm, innovative applications will be able to harvest those available computing cycles to a user's benefit. For instance, an application might perform monitoring in background threads, perhaps fetching new data from the server to aid the user in a given context of the application:
Single-processor-core PCs today can take advantage of multi-tasking, in which one thread, for example, deals with display while another does a long-running computation and another goes out to a server. But what to do with eight processor cores all running at 3.6GHz? Microsoft's Larus says he knows people are probably having trouble imagining how a single user might take advantage of that kind of system. "To be honest, so are we," he says. "This is a subject of very active discussion here."
While the trend is for developer tools to mask concurrency as much as possible, to what extent do you think multi-core CPUs will impact a developer's work?
Multiple cores may raise attention to multi-threaded development. Still a lot of developers tend to avoid dealing too much with multi-threading in their code. Increasing processor performance helped us as developers being lazy. What would have been an unacceptable result on older hardware is fast enough to work with on current iron.
Still most desktop applications spend most of the time waiting for events to occur. What we recognize as speed is the peak performance our machines a capable of. I think of the notebook I'm working on. It mostly operates at 600-800 MHz while I am typing or reading or something similar - on a single core. No need for 3.8 Ghz dual core all the time.
Multiple cores are good for multiple applications. All those stuff that works in the background. Virus scanner (a lot of them really tend to suck much performance), firewall, download manager, new reader ... Most people will recognize their second core only because heavy application load does not grind down the whole system anymore - it remains responsive and 'snappy'.
Most applications will not directly benefit from multiple cores, because they won't have to care. But using a language/platform, that makes it easy to use threads in your 'everday code' may help as soon as we get used to all our cores and give them some more load.
If you ain't coding some very demanding stuff, it should be made easy to you to take advantage of threads, without having to dive too deep into all the multi.threading issues. Make your developers feel at home with their platform. And write mor example code, that also addresses threading. People will resist to learn what they seldom happen to see with their own eyes.
I think this article is behind the times. Java has found its niche in the server environment. Mulicore server machines are the norm and have been for a long time.
The basic design decisions around threading are language independent so this is mostly not even a Java issue. Where Java does enter the picture is the new concurrency package. Abstracting concurrency into high-level classes is good because it helps prevent developers from writing incorrect code or re-inventing the wheel on algorithms that have been studied exhaustively in academia.
Java does have some gotchas. Some techniques that are popular in other languages will not work correctly in Java due to subtle issues in the JVM spec.
In response to another poster's comment about threads not being needed---You are probably running quite a bit of multithreaded code even though you didn't create the thread in your own code. For instance, your web code is executed by a pool of thread workers that process incoming HTTP requests. Just because you didn't explicitly create a thread does not excuse you from ensuring the correctness of your code.
The problem is that cpu clock frequencies are not scaling with time as they used to (at least that is what the current trend indicates). Short time ago intel was talking about 10ghz or so on their netburst architecture if I remember correctly. Well..that didn't work and it's probably not gonna happen (netburst is dead). So if your software complexity/throughput requirements or something the like increases you cannot rely on the next hardware generation to automatically fix the problem for you. Currently there is nothing I'm aware of that exploits parallelisation automatically and is any good at it for probelms that are not inherently parallel. I guess for the moment we will have to put up with atomic synchronization and a lot of hard to debug non reproduceable bugs and all that fun until we find a better way to describe the temporal data dependancies.
Yes it's inevitable that developers will increasingly need to write concurrrent code. My experience I see much more excessive/ill-informed use of threading than avoidance of threading. I think that the mental model of a CPU executing code that each developer builds is often a single-threaded one. Designing and implementing concurrent algorithms is hard, too hard for many, and this is often underestimated. In java this has been exacerbated by the poor quality of many concurrency books. Brian Goetz recent book is a superb exception to this rule. Ten years of experience writing single-threaded code doesn't help one grasp how race conditions, instruction reordering, application deadlocks or excessive synchronization occur.
In some cases the "right thing" may be to deploy multiple identical processes to each multiCPU hosts and to run these as "shared nothing" apps that scale out w/o the need to deal with the subtleties of state replication.
I wonder if this is going to turn out to be more of a problem for processor vendors like Intel.
If "poorly" written multithreaded applications start failing on these new systems when they apparently worked fine on the old ones, will consumers just assume that the new processor technology is flawed and demand a return to single-core processors?
> If "poorly" written multithreaded applications start > failing on these new systems when they apparently worked > fine on the old ones, will consumers just assume that the > new processor technology is flawed and demand a return to > single-core processors?
Blaming Intel for others' bad software? Is that how the US law system works? Can you hear the laughter from over here (Germany)? ;)
Software vendors are the only ones to take responsibility for their products' quality. I'd like to be able to blame others for my faults, but it just won't work that way...
It's not a matter of blame, it's a matter of perception. You buy a new computer and suddenly your applications stop working. What do you think most consumers would conclude from that?
But to be fair to developers, I think the responsibility is shared. Look at the situation with Java:
Sun made the rather risky decision to make a cross-platform threading library. The makes multithreading more complex and error-prone.
Historically Java threading hasn't always worked correctly.
Java threading has changed significantly over time.
There are few good resources to learn to do Java threading well.
In addition, in the real world software development is always a compromise. It's not always feasible to design and test for a future that is not well understood or is too far off to justify the investment.
If there's any blame one can legitimately assign to Intel, it's that they are promoting multiple-core processors as a significant performance improvement when it's not clear that they will be.
> If there's any blame one can legitimately assign to Intel, > it's that they are promoting multiple-core processors as a > significant performance improvement when it's not clear > that they will be.
Then we had to blame all major CPU vendors (Intel, AMD, Sun/Hitachi, IBM, ...). They're all going the multiple core way, just because there is no other one available right now to boost performance. And they have to boost it, because they have to sell new products to survive and these have to be superior to prior products.
In most cases you don't have to worry too much about issues. As a client developer I rely on what Sun provides with Java and its JVM. The really bright people have to work on those fundamentals and do the magic in the JVM sources, the OS kernel sources, the compiler sources, the driver sources and so on.
Java (and .NET) helps us to stay focused to what we can do to make our applications work via abstraction of issues others have to deal with coming closer to the hardware. It's been building on top of the work of others since the invention of higher level languages. It's our job to implement good multi-threading in Java, the best way we know how and it's other peoples' job to squeeze their brains over issues dealing with multi-threadin on a lower level. I'm pretty confident that all those people do their jobs well and that even the CPU makers have some bright people who know the softer side of IT.
I don't know what it will be like in 10 years. Will everyone have a 64 core machine? What will every single core be capable of? I tend to think that software will be less monolithic. It will be more like many agents running at once. All of them gathering or claculating information and waiting for messages, transforming them, passing them further. It will be more about a lot of simpler applications running, everyone serving a simple specific purpose and not one huge dinosaur, that is hardly developable and controllable. They will rely on some (open) standards and frameworks, developed by people hopefully brighter than me. I'm confident we'll leave this valley of confusion by complexity and be able to let complex systemes build and manage themselves, only having to add and alter little pieces of software, clever ideas easily braught to source.
Before getting even more pathetic, I should quit and drive home <== good example of a clever idea, btw ;)
<p>A big issue for me is: How many (percentage wise) current applications, and specially Java ones, once they're running on multi-core chips, will show defects that did not show on single core chips? For examples, is it <1%, <10% or >10%?
<p>The second big issue is: What is the best course of action for minimizing this risk, e.g., what are the best testing techniques, specially for Java SE and Java EE apps?
<p>Do you agree that the maligned EJB components will show a much reduced risk of such defects and will cost much less than non-EJB components to port to multi-core chips?
Multi-cores are common these days. I have not heard of any related problems by now. Think about Sun's current UltraSparc T1 processor with up to 8 cores...
Single threaded code won't fail on multi core hardware unless it uses some sort of resources that is shared over process boundaries AND several instances of it are running at the same time (or something else very extraordinary and insane..you never know with ppl :)). Code that was written to be multi threaded but has so far run on singe core only (so you forgot to test your code on multi core) might very well crash/misbehave even if it was running totally bug free on single core. But who'd not test his code?? The os task switches all the time anyways (on both single and multi core)..for your single threaded code it makes no difference if it is running on core x or y. That's why nothing bad has happened to your old applications so far. Also those ppl writing services won't get into much trouble either..the services are called asynchronously anyways and have a defined protocol to handle all the timing issues. The problem with large scale applications that need more processing power is that you have to minimize synchronization to get the most out of your cores running parallel. Micromanaging a lot of local application "services" with nice protocols is too much overhead in most cases. So you end up synchronizing application/code sections . Stupidly the area your application spends most time in is normally the one that is highly connected with a lot of other modules so you are forced to insert a really complex synchronization inbetween a LOT of code..add one synchronization too much at the wrong spot and you have wasted allwork cause the app is back running in sequence even slower than before. Miss one and you get your random crashes/misbehaviour. IHMO this is something we will all have to deal with sooner or later but it hasn't hit most of us yet..that's why I think the article is pretty much on spot.
While most servers have been multi-way for a while, I think this article could be pointing more at the traditional desktop programming environment, which has been predominantly single CPU its whole x86 life. How many desktop developers do you know that use the volatile keyword (outside of training courses)? As multiple cores with multiple L1/L2/etc caches become the norm on your average desktop PC, developers on those platforms are going to have to hone an additional set of skills to take advantage of the hardware, and not get caught by race conditions and deadlocks.
> While most servers have been multi-way for a while, I > think this article could be pointing more at the > traditional desktop programming environment, which has > been predominantly single CPU its whole x86 life. How many > desktop developers do you know that use the volatile > keyword (outside of training courses)?
I agree and that's why I said earlier that Intel make take some heat if a lot of legacy code doesn't work on the new processors. David Wheeler said "Compatibility means deliberately repeating other people's mistakes." In that spriit the case could be made that these multi-core processors aren't fully compatible with legacy desktop machines.
I don't think developers are completely ignoring issues like "volatile". I just think that multithreading explanations have been a bit "muddy" particularly in Java where "perfect" threaded code would theoretically work correctly on all systems but "imperfect" code may work fine on one but not on another. It's not really a java implementation issue, it's really the problem that multithreading can't really be abstracted properly in a platform-independent fashion (at least not in my opinion).
The other issue is testing. If a company doesn't even own any multi-core desktop machines, are they likely to think about testing on one?
Flat View: This topic has 16 replies
on 2 pages
[
12
|
»
]
Previous Topic
