|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 45
Messages: 45
Messages: 45
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
The Multi-Core Dilemma
Hardware Evolution
Throughout the history of modern computing, enterprise application developers have been able to rely on new hardware to deliver significant performance improvements while actually reducing costs at the same time. Unfortunately, increasing difficulty with heat and power consumption along with the limits imposed by quantum physics has made this progression increasingly less feasible.
There is good news. Hardware vendors recognized this several years ago, and have introduced multi-core hardware architectures as a strategy for continuing to increase computing power without having to make ever smaller circuits.
Sounds Good, So What’s the Dilemma?
The "dilemma" is this: a large percentage of mission-critical enterprise applications will not "automagically" run faster on multi-core servers. In fact, many will actually run slower.
There are two main reasons for this:
The clock speed for each "core" in the processor is slower than previous generations. This is done primarily to manage power consumption and heat dissipation. For example, a processor with a single core from a few years ago that ran at 3.0 Ghz is being replaced with a dual or quad-core processor with each core running in the neighborhood of 2.6 Ghz. More total processing power, but each one is a bit slower.
Most enterprise applications are not programmed to be multi-threaded. A single-threaded application cannot take advantage of the additional cores in the multi-core processor without sacrificing ordered processing. The result is idle processing time on the additional cores. Multi-threaded software should do better, but many people are finding that their multi-threaded code behaves differently in a multi-core environment than it did on a single core, so even these should be tested.
Won’t my application server or operating system take care of this for me?
One of the key considerations here is the order of processing. A single threaded application that needs to ensure that A happens before B cannot run multiple instances concurrently on multiple cores and still ensure a particular order.
Application servers and operating systems are generally multi-threaded themselves, but unfortunately their multi-threaded nature does not necessarily extend to the applications that run on them. The app server and OS don’t know what the proper order is for your particular business logic unless you write code to tell them. In fact, they are designed to simply process any thread as soon as possible, potentially disastrous in a business application. SMP (symmetric multiprocessing) has similar limitations.
So we are back to the same problem – how to run multiple instances concurrently on multiple cores and still ensure a particular order.
Intel’s 45nm announcement
Intel recently announced that they will have chips in the near future with 45nm features, a significant advance from the 60-65nm that is prevalent today. The company has also made it clear that this is not reducing the need for multi-core.
Around the same time as this announcement, Intel announced that they have an 80 core processor in the works. Power and heat will have to be addressed for a processor with 80 cores to come to market. So 45nm may mean some increase in clock speeds for future processors, but its primary use will be enablement of a higher number of cores.
Concurrent Computing
There is no easy solution, but there are several options, and they all involve bringing concurrency to your software. Concurrent computing (or parallel programming, as many refer to it) is likely to be a very hot topic in the coming years, so it’s a good idea to start preparing now.
Since multi-core servers already make up most of the new servers shipments, concurrent computing in the enterprise will quickly become a way of life. So we need to put some thought into two things: how to make existing applications run concurrently, and how to build new systems for concurrency.
More people are talking now than any time in recent memory about how to do multi-threaded software development as the primary answer to concurrency. However, instead of writing our application code to be multi-threaded, we should consider how to abstract threading out of application code. Multi-threaded code is difficult to write and difficult to test, which is why many people have avoided it in the first place.
At Rogue Wave Software we have been working for several years in the area of "Software Pipelines." Software Pipelines* is an approach that can be used to abstract the threading model out of the application code. As software developers, you would not mix your UI code with your business logic, and for good reasons. A similar principle should apply for programming for concurrency – the threading model should not be driven from within the application logic.
There are several important benefits to this approach. Removing threading from application code means:- The application developer doesn’t have to own the threading model
- Existing applications can move into a concurrent environment with much less effort
- Makes it easier to scale to additional computing resources without modifying the application
- If done right, the application can continually be tuned for performance without modifying application code
This approach does not allow the application developer to wash their hands entirely of concurrency. Application code needs to be written to be thread-aware, but does not need to have threads written into it. For more information on Software Pipelines, you can read Software Pipelines - An Overview (free registration to webservices.org required.)
An extract from the article:SOFTWARE PIPELINES DEFINED
The fundamental concept of parallel processing is simply stated:
Given a series of tasks to perform, divide those tasks into discrete elements, some or all of which can be processed at the same time on a set of computing resources As applied to the business environment, the ideal implementation would allow any business application process or portion of a process to be divided into discrete tasks or services, to be performed anywhere in a given network (local or remote), in parallel with other tasks whenever possible. These tasks can be of fine or course granularity, ranging from a Web service to individual class/method calls, depending on the specific needs of the application. The arrangement would be dynamic, allowing available computing resources to shift with demand, thereby optimizing the utilization of all available facilities. While the idea is simple, the details are often complex with a multitude of potential variations and design patterns.
Software pipelines represent an architectural approach that supports virtually unlimited peer-to-peer scalability, supporting the decomposition of business processes into specific tasks which are then executed in parallel. Software pipelines also provide an easy method for the developer to control the exact distribution and parallel execution of various tasks, or components of a business process, within a single server or across a multitude of servers. It is specifically designed for business applications, particularly those that use, or can use, a service-oriented architecture. The software pipelines architecture is designed to handle a high volume stream of transactions, both large and small, and, thus, is ideal for mixed-workload business application processing. Consider how to abstract your threading model from your application logic, and you may find a smoother (concurrent) path ahead.
* Software Pipelines is a general term, not owned or trademarked by Rogue Wave or anyone as far as I’m aware. It also does not require the use of any of our technology. Software Pipelines borrows conceptually from hardware pipelines and also from fluid dynamics, which has interesting parallels to software systems.
[Editor's note: this is largely a repost from Patrick Leonard's blog on WebServices.org, The Multi-Core Dilemma. It's been included here with some edits based on its submission by a Rogue Wave employee.]
|
|
|
Message #229414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
I think that the problem is exagarated a bit. In a typical application business logic is never CPU bound and it's not a problem if you'r code is not multi-core aware. Furthermore almost all app servers use things like thread pools which should make them quite scalable.
Once I had to write a NIO based server and to make it vertically scalable I used standard Java 5 thread pool and it worked quite well as far as I can tell. I am not sure if it would be able to use, let's say, 8 cores effectively, but why not ? I wonder why good old thread pool is not good enough.
|
|
|
Message #229415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
In the enterprise world the multi-core may be or not a problem. As the previous poster noted, multithreading is already pervasive in this world. The point is that the typical J2EE parallelism map a single thread per user - so applications can experience a worse latency (due to the lower clock speed), even though they will be able to deal with a larger number of users at a time. If you can't live with that, you are forced to re-design the application and exploit parallelism within the single user request.
But in my opinion, the desktop is the segment where the problem will be stronger - consider e.g. people having a desktop with 8 or 16 cores and multimedia applications that must take advantage of all these cores - as multithreading is marginally used in this segment today.
|
|
|
Message #229417
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
I think that the problem is exagarated a bit. In a typical application business logic is never CPU bound and it's not a problem if you'r code is not multi-core aware. Furthermore almost all app servers use things like thread pools which should make them quite scalable.
Once I had to write a NIO based server and to make it vertically scalable I used standard Java 5 thread pool and it worked quite well as far as I can tell. I am not sure if it would be able to use, let's say, 8 cores effectively, but why not ? I wonder why good old thread pool is not good enough.
There might be applications which are not inherently parallel as practically any application which serve multiple users concurrently are inherently parallel.
There are several deployments of applications which do nothing but process massive amounts of data on a single thread and this processing might be parallelizable but it would need to change the code.
So if under a typical application you mean a typical web application or the server side of a typical multiuser application, then you are right, but a typical application in general might well be single-threaded, and as such it will not benefit from multiple cores.
Best regards,
Robert
|
|
|
Message #229418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
I think your comment misses the point. You're quite right that you will still be able to use thread pools as you always have done. The problem comes when you need to write code that accesses shared memory from multiple threads at the same time.
At the moment this is ridiculously hard to get right in Java... see Brian Goetz's book "Java Concurrency in Practice" for all the horror stories about what can go wrong if you don't synchronize properly. Then, once it has gone wrong, it is incredibly difficult to debug.
Until recently this hasn't been such a problem because only a limited set of developers, i.e. the guys who build high performance network servers or application servers, needed to do very much multi-threaded programming. Therefore the solution was just to hire the smartest 1% of developers to do these jobs.
In the multi-core future, _everybody_ will have to write multi-threaded code, and Java just doesn't provide enough of a safety net for that to happen.
|
|
|
Message #229421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
Good article. After all, the pipeline pattern is extremely effective at the hardware level and it seems only natural that it would manifest itself at the software level. I found this article informative on the
Pipeline Pattern
I spent some time researching this same issue in my spare time a while back. My goals were similar, to create a XML schema leveraging Java annotations (_insert mandatory disparaging annotation comment here_) for defining a software pipeline. I wanted to use it for a JOGL OpenGL programming which lends itself to multithreaded programming. As the article stated, embedding a bunch of multithreaded code inside application logic quickly turns into maintenance and troubleshooting nightmare. By defining a set of annotations (Processor, Input, Output) and adding them to the Java code, I could externally define a conceptual pipeline with stages, buffers, variables (global memory), and primitive conditions that succinctly expressed the intent of the application I was building. A Java annotation processor was used to reading in the pipeline definition file and Java source file and would then generate Java artifacts that implemented the behavior dictated in the pipeline definition file.
Alas, as with most research projects conducted in ones spare time, I ran out of spare time and interest and discontinued my work. Referring back to the article, with the advent of the GPU and ( and AMD’s interest in Coprocessors) will only increase the demand for multithread applications and task decomposition.
|
|
|
Message #229420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
there are already 8 core CPU's..
i think intel and AMD is pretty behind in the multi-core-threading game (especially considering intels 80 core future CPU is not x86) . Sun's niagara1 already has 8 cores and 32 independent threads. it is working (with Java applications), and it consumes less then 100Watt AFAIK. seems like it works like a champ in web apps, but sucks in single threaded or FPU intensive app.
Niagara 2 will have 8 cores and a total of 64 threads , two 10 gbit Ethernet + FPU per core + hardware encryption + memory controller embedded with similar power consumption. So seems like their approach is working well.
http://www.sun.com/processors/niagara/
http://en.wikipedia.org/wiki/UltraSPARC_T2
but i agree, there are still problems in the software side, i believe java will not be the one effected most from it.
|
|
|
Message #229424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
I think your comment misses the point. You're quite right that you will still be able to use thread pools as you always have done. The problem comes when you need to write code that accesses shared memory from multiple threads at the same time.
At the moment this is ridiculously hard to get right in Java... see Brian Goetz's book "Java Concurrency in Practice" for all the horror stories about what can go wrong if you don't synchronize properly. Then, once it has gone wrong, it is incredibly difficult to debug.
Until recently this hasn't been such a problem because only a limited set of developers, i.e. the guys who build high performance network servers or application servers, needed to do very much multi-threaded programming. Therefore the solution was just to hire the smartest 1% of developers to do these jobs.
In the multi-core future, _everybody_ will have to write multi-threaded code, and Java just doesn't provide enough of a safety net for that to happen.
Yep, this is getting closer to the issue.
See, much of what we do now boils down to:
(1) By design, create an environment that is thread ignorant
(2) Rely on Moore's Law
The CPU guys are saying "you can't go faster, go wider" which means the rules are about to change. Thus far people have got away with pretending this stuff doesn't exist. In order to get the best out of these chips, things are going to have to change and that will include app servers etc because the only way to scale will be with explicit support from the programmer. i.e. You'll have to know about parallelism and know how to exploit it.
As to Java not providing the right kind of support, frankly I think it goes way wider than Java. OpenMP for example, is really still in it's infancy having been deemed irrelevant to most.
|
|
|
Message #229422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
3Ghz vs 2.6GHz
As long as "enterprise" software is concerned, I have yet to see any single user needing the full power of 3GHz and cannot live with 2GHz.
Probably 99.9% of performance issues have to do with excessive I/O (DB accesses, stupid I/O) or deadlocking on something -- the results of. And have absolutely nothing to do with clock speed or number of cores, even though they are easiest target for blaming.
|
|
|
Message #229425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
People are still talking about this? SMP has been around for quite some time. If you _still_ don't know how to properly use threads, design properly, write thread-safe code, and use synchronization when necessary, you're ignorant, lazy, stupid, or very, very new to this world of programming.
Any app server or web server is multithreaded, as stated. Typically, you shouldn't run into any threading problems if you follow the basic recommendations and rules that have been stated for years. If your core processing logic could be multithreaded, great. You should know how to do it, and it's not that difficult. Typically you can't just magically say "go, now you have threads," but the redesign should be easy enough to make it happen. There have been countless books and articles about this for years. We don't need more that say the same thing.
Almost all of the way through the article, I was thinking to myself, "Wow. This sounds like an Intel SMP/SMT/dual-core article trying to sell a compiler or a conference." "Ooh, dual-core is SUPER-different than SMP to the non-kernel, non-HPC, non-abstracted-threads developer! It's maaaaagic!" Then, to my dismay, Rogue Wave reared its ugly head. I was hoping I had seen the last of it in the late 90s. Oh well...
|
|
|
Message #229435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
So if under a typical application you mean a typical web application or the server side of a typical multiuser application
Yes, it's exactly what I meant.
|
|
|
Message #229437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
I also don't get the difference between multi core and SMP from the Java view... What I get is that there is a problem with app performance due to the reduced clock speed. We tested Sun's Niagara (low clock speed) and were quite disappointed. As long as you haven't more than 32 threads, it's ok. But if you have more or if you need power (not FPU, just high throughput per thread), it sucks.
The Pipeline pattern is a way to go but nothing new. Same thing as SEDA, basically.
-- Andreas
|
|
|
Message #229439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
+1 I don't get it either. What is the difference from an application software perspective? Is this "news" on par with "ingesting too much <name your poison> can be bad for you"?
|
|
|
Message #229443
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: 3Ghz vs 2.6GHz
As long as "enterprise" software is concerned, I have yet to see any single user needing the full power of 3GHz and cannot live with 2GHz.
"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981
Hmm... sounding familiar
|
|
|
Message #229447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: 3Ghz vs 2.6GHz
Throughout the history of modern computing, enterprise application developers have been able to rely on new hardware to deliver significant performance improvements while actually reducing costs at the same time.
Throughout the history of modern computing, hardware developers have been able to rely on new software to require significantly more resources .... :)
|
|
|
Message #229448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thread Pools are not the answer!
Those who say it's not a problem because 'our web app uses a thread pool' or 'my application is DB bound anyway' are missing the point.
As time marches on, computers get more powerful and the demands placed on our hardware increases:
- the software has to provide more and more functionality to keep up with business demands, competitive demands, compliance demands, interoperability demands etc
- ever increasing levels of abstraction to help us get the job done faster and more reliably - this translates directly into decreased efficiency and therefore reduces performance for a given bit of functionality - Java replacing C++ and Web Services replacing CORBA or RMI are just 2 examples.
Today's apps works fine on a 3ghz cpu, but in 10 years' time today's app will be legacy code. Languages, frameworks and tools will have increased in abstraction (even now, witness the inceasing use of scripting languages where Java was previsouly used).
You're going to be stuck with the same clockspeed, but the amount of raw computation requried to service a user request will have increased. All the servlet pools in the world aren't going to help meet your reponse time SLAs!
|
|
|
Message #229453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
3GHz vs 2.6GHz
As long as "enterprise" software is concerned, I have yet to see any single user needing the full power of 3GHz and cannot live with 2GHz.
You've nailed it, Bear. Request latency has so little to do with the CPU clock speed, it's not even funny.
A really good ecommerce application can generate a page in about 200 ms, around 600,000,000 instruction cycles for a 3 GHz CPU. Most of them are up around 800 ms - 1600 ms. 1600 ms would be about 5,150,000,000 instruction cycles.
I guarantee damn near all that time is spent waiting. Waiting for a thread, a database connection, a disk read, data from the database, whatever. Running a slower CPU won't affect that at all.
Michael T. Nygard
www.michaelnygard.com
Release It! Design and Deploy Production Ready Software
http://pragmaticprogrammer.com/titles/mnee/index.html
|
|
|
Message #229454
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
> What is the difference from an application
> software perspective?
Stalling performance with shared locks and excessive locking on multiple cores is much easier than multithreading and single core.
They should just start an app server per core and use message passing. That removes the possibility of code having very silly locking patterns.
|
|
|
Message #229458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Its I/O Stupid!
Only thing good about multi-core is now I can have dual processor on my laptop. Other than that, its all marketing hype.
The real problem in enterprise computing is the I/O bottleneck. The only thing that's gonna start a whole new revolution in computing is if we had some real, super-fast, solid-state RAM so we could get rid of the hard-drive.
Bill
|
|
|
Message #229464
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Old hat
Whitepaper, direct from their site (no registration):
http://www.roguewave.com/hydra/software-pipelines/pipelines-overview.pdf
This isn't innovative and certainly isn't new. I work on a SOA environment and wrote much of our APIs to handle everything they state in their paper. The domain-level code doesn't have to deal with threads, has a very simply API to work with, and it scales quite nicely. I recently took advantage of our move to Java-5 and Goetz's excellent book to further simplify it.
This is just PR. Its nice to have something out of the box, but everyone whose ever needed it wrote there own.
|
|
|
Message #229473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Only thing good about multi-core is now I can have dual processor on my laptop. Other than that, its all marketing hype.
The real problem in enterprise computing is the I/O bottleneck. The only thing that's gonna start a whole new revolution in computing is if we had some real, super-fast, solid-state RAM so we could get rid of the hard-drive.
Bill
This will start this year. I heard that Apple will come with a laptop and SSD instead of a hard drive. I started to buy Apple shares ... ;-)
-- Andreas
|
|
|
Message #229474
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
Software pipelines represent an architectural approach that supports virtually unlimited peer-to-peer scalability
That is interesting. Pipelines are borrowed from hardware designs, and my hardware design books say nothing of the kind. There is a very hard limit to what a pipeline can achieve in terms of latency reduction.
The argument is something like what you do when you introduce a cache. You are betting that your cache has a hit rate and a response time that is so good that your cache misses don't matter.
A pipeline introduces overhead. It is very easy to calculate the speedup resulting from the introduction of a pipeline, and I can assure you that the speedup is nowhere near infinity.
"Computer architecture - a quantitative approach" by Hennessy/Patterson has all the gory details.
|
|
|
Message #229478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Only thing good about multi-core is now I can have dual processor on my laptop. Other than that, its all marketing hype.
The real problem in enterprise computing is the I/O bottleneck. The only thing that's gonna start a whole new revolution in computing is if we had some real, super-fast, solid-state RAM so we could get rid of the hard-drive.
Bill
And the reason you have an I/O bottleneck is oftentimes because you keep all the state in a database. Why? Because then a lot of your beans are stateless which makes threading a no-brainer.
So then the question is does your I/O bottleneck exist because it's a fact of enterprise life of because your architecture makes it that way?
|
|
|
Message #229499
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Only thing good about multi-core is now I can have dual processor on my laptop. Other than that, its all marketing hype.
In reality, for the same money (e.g. $10k), the same space (e.g. 1U) and the same power consumption level (i.e. heat output), it allows companies to buy a server that supports 8 concurrent threads instead of a server that supports 2 concurrent threads.
In other words, it's a very good thing in the data center.
The real problem in enterprise computing is the I/O bottleneck. The only thing that's gonna start a whole new revolution in computing is if we had some real, super-fast, solid-state RAM so we could get rid of the hard-drive.
True - I/O is where most applications spend most of their time.
Regarding solid state:
For your notebook, you can now get flash drives up to 64GB, and 128GB by the end of the year. More expensive of course.
For data centers, solid state hard drives have been available for years. I remember that eTrade was using them several years ago, for example. More expensive of course.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #229500
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
And the reason you have an I/O bottleneck is oftentimes because you keep all the state in a database. Why? Because then a lot of your beans are stateless which makes threading a no-brainer. So then the question is does your I/O bottleneck exist because it's a fact of enterprise life of because your architecture makes it that way?
Stateless EJBs came from the same company (Sun) selling the large 32-way and 64-way database servers. What else would you expect? ;-)
I have a presentation slide titled "When to use stateless" with the following bullets:
* You are writing an HTTP server
* Your application has no security requirements
* The only data that your application needs for its operation will be passed to it
* Scalability is not a requirement
* Your budget is infinite
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #229511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
Software pipelines represent an architectural approach that supports virtually unlimited peer-to-peer scalability
That is interesting. Pipelines are borrowed from hardware designs, and my hardware design books say nothing of the kind. There is a very hard limit to what a pipeline can achieve in terms of latency reduction.
...
A pipeline introduces overhead. It is very easy to calculate the speedup resulting from the introduction of a pipeline, and I can assure you that the speedup is nowhere near infinity.
Software pipelines would have the same, or very similar, hard limit on what can be done concurrently. This fact is known for about 40 years as Amdahl's law.
|
|
|
Message #229512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Naive theserversidevertisement at its worst
For example, a processor with a single core from a few years ago that ran at 3.0 Ghz is being replaced with a dual or quad-core processor with each core running in the neighborhood of 2.6 Ghz.
I am surprised noone caught this. Did the writer not even realize that the new 2.6 Ghz chips are actually faster than the old netburst based 3.0 ghz ones? Clock rates are continuing to advance, and at least for server side applications, more cores can be helpful without a major change in development method.
This whole article is just shilling for roguewave.
|
|
|
Message #229548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Only thing good about multi-core is now I can have dual processor on my laptop. Other than that, its all marketing hype.
In reality, for the same money (e.g. $10k), the same space (e.g. 1U) and the same power consumption level (i.e. heat output), it allows companies to buy a server that supports 8 concurrent threads instead of a server that supports 2 concurrent threads.
In other words, it's a very good thing in the data center.
Sure, saves you money, but multi-core doesn't really change how you develop and deploy applications, which was my point.
Bill
|
|
|
Message #229569
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Sure, saves you money, but multi-core doesn't really change how you develop and deploy applications, which was my point.
Bill
Sorry don't you mean that moving to multi-core will significantly change the way you develop and deploy applications.
Simply moving an existing application to multi-core can have a significant negative impact on performance.
For example, Microsoft found that Excel 11 actually ran slower on dual core processors (reference: http://www.serverwatch.com/trends/article.php/3657451). In fact, Microsoft was so spooked by this and other multi-core performance problems that it has formed a group to look at the problem.
As as for writing business applications that can actually take advantage of multi-core processors ..... almost nobody is ready for that yet.
|
|
|
Message #229577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Sure, saves you money, but multi-core doesn't really change how you develop and deploy applications, which was my point.
Sorry don't you mean that moving to multi-core will significantly change the way you develop and deploy applications.
Simply moving an existing application to multi-core can have a significant negative impact on performance.
For example, Microsoft found that Excel 11 actually ran slower on dual core processors (reference: http://www.serverwatch.com/trends/article.php/3657451).
No, based on the title of the site ("TheServerSide.COM"), Bill was correct. The article you reference is comparing a desktop machine with a single socket / single core configuration against a desktop machine with a single socket / multi-core configuration.
For the past 10+ years, the overwhelming majority of commodity data center servers have had at least two sockets, meaning that we have already had to [successfully] deal with this problem for over a decade, which was Bill's original point.
As as for writing business applications that can actually take advantage of multi-core processors ..... almost nobody is ready for that yet.
J2EE was explicitly intended (at an architectural level) to simplify the building of business applications for servers with more than one concurrent thread (multi-socket and/or multi-core and/or concurrently-multi-threaded), so your claim has been entirely incorrect for server-side Java applications for at least seven years.
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid
|
|
|
Message #229589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
single vs. multi core
One thing the author doesn't see:
Ghz is not equal performance. There are many other design issues in processor design that are relevant for the "performance" of a processor.
So one cannot say that a "3.0Ghz" cpu is slower than a "2.6Ghz" cpu, as long as they don't have the exactly same design.
Take a look how the "slower" (in clock speed) Athlon Designs from AMD performed against the "faster" (in clock speed) Pentium 4 Designs from Intel.
So as long as you cannot proof your assumptions in terms of single thread benchmarks, I would doubt that "multi core" is slower than "single core".
|
|
|
Message #229593
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: single vs. multi core
One thing the author doesn't see:
Ghz is not equal performance. There are many other design issues in processor design that are relevant for the "performance" of a processor.
Another thing that I haven't noticed anyone mention is that it's extremely rare for any server or desktop machine to be dedicated to a single process. Even if an app doesn't make use of multi-threading, it will probably get some significant benefit from not having to share a CPU with other processes.
If we are talking about Java apps, you can get a immediate benefit without using any threads in your code at all by turning on concurrent collections.
|
|
|
Message #229608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: single vs. multi core
One thing the author doesn't see:
Ghz is not equal performance. There are many other design issues in processor design that are relevant for the "performance" of a processor.
Another thing that I haven't noticed anyone mention is that it's extremely rare for any server or desktop machine to be dedicated to a single process. Even if an app doesn't make use of multi-threading, it will probably get some significant benefit from not having to share a CPU with other processes.
If we are talking about Java apps, you can get a immediate benefit without using any threads in your code at all by turning on concurrent collections.
Are you talking about java.util.concurrent collecions or the oswego stuff? They are great for insert-only or read-mostly caches, but you still have to be aware how you use them.
|
|
|
Message #229615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
J2EE was explicitly intended (at an architectural level) to simplify the building of business applications for servers with more than one concurrent thread (multi-socket and/or multi-core and/or concurrently-multi-threaded), so your claim has been entirely incorrect for server-side Java applications for at least seven years.
Not really. Current technologies are designed to handle lots of relatively simple concurrent requests, and do an effective job of parallelizing them across multiple CPUs or even multiple servers. I won't say it's easy, but it's not uncommon. Each individual request is processed serially, but many requests can be processed in paralle.
This works as long as you are not making the requests more complex.
So if you happened to have a situation where computationally-bound requests are your bottleneck, then you need parallizeable application code in order to alleviate that bottleneck by throwing more processors at it.
|
|
|
Message #229620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Top hardward manufactures are right on the track
I think author has overlook historical development. Top hardware manufactures in Enterprise computing long knew that it is highly inefficient to design systems aiming to run one thread at full throttle. And that is for two reasons. One as extensively discussed here and elsewhere - IO latency and second that is business logic made of a sequece of operations each asking current process or thread to wait for some other activity to finish. Top manufactures like Sun and HP (and AMD too but they were not directly into server market and then being in the same desktop segment as Intel, they have to follow their competetor but they did made effort to quell clock speed myth) had made a concious choice long back on RISC based processor with focus on high performance throughput. When Intel was chasing thier own clock speed mark, these companies were more than ever confident on their offering of multi processor based server albaith each running at slow speed and yet delivering excellent performance. Now they have have taken the same game forward lead by Sun in offering multi core systems to deliver even high performance per Watt.
In one line, there is nothing new in multi core (and SMP) but it's a natural extension to multi processor based system which is around for a decade. Multi core tried to just get better in terms of space and energy utilization per amount of computing and in turn lesser heat generation. Problem or say opportunies of employing concurrancy are around for a long time.
|
|
|
Message #229644
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Regarding solid state:
For your notebook, you can now get flash drives up to 64GB, and 128GB by the end of the year. More expensive of course.
For data centers, solid state hard drives have been available for years. But these are still drives, logically. It would be much better to hot-plug a "drive" that would map right into main memory space. Kind of like memory-mapped files, but extended to a whole drive. All memory including "storage" would be a unified space.
|
|
|
Message #229664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Regarding solid state:
For your notebook, you can now get flash drives up to 64GB, and 128GB by the end of the year. More expensive of course.
For data centers, solid state hard drives have been available for years. But these are still drives, logically. It would be much better to hot-plug a "drive" that would map right into main memory space. Kind of like memory-mapped files, but extended to a whole drive. All memory including "storage" would be a unified space.
Yes, that will come. You won't need to 'boot' your machine anymore; it would be like a VM in VMWare.
-- Andreas
|
|
|
Message #229677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Its I/O Stupid!
Yes, that will come. You won't need to 'boot' your machine anymore; it would be like a VM in VMWare.
-- Andreas And when your software will bug out and put garbage into this unified memory, you'll just throw away the machine and buy a new one.
|
|
|
Message #229686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
An enterprise application needs to care much more about being thread-safe than being multi-threaded.
That is because almost all business logic in an enterprise application is exposed to the possibility of being simultaneously invoked by multiple clients. Many constructs typically used by J2EE developers are already implicitly multi-threaded - e.g. Servlets, Struts Actions, EJB public APIs, JMX APIs etc. The underlying J2EE app server already offers business services implemented via these contructs in a multi-threaded way. The implementation itself however needs to be thread-safe.
And this is something the implementor needs to be aware of.
As long as your business logic is thread-safe when exposed by an inherently multi-threaded construct, your components will scale across multiple cores and higher performance hardware.
|
|
|
Message #229687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: single vs. multi core
One thing the author doesn't see:
Ghz is not equal performance. There are many other design issues in processor design that are relevant for the "performance" of a processor.
Another thing that I haven't noticed anyone mention is that it's extremely rare for any server or desktop machine to be dedicated to a single process. Even if an app doesn't make use of multi-threading, it will probably get some significant benefit from not having to share a CPU with other processes.
If we are talking about Java apps, you can get a immediate benefit without using any threads in your code at all by turning on concurrent collections.
Are you talking about java.util.concurrent collecions or the oswego stuff? They are great for insert-only or read-mostly caches, but you still have to be aware how you use them.
No, I actually meant concurrent garbage collectors. Sorry, I see now how unclear that was. You'd definitely have to change the code (or at least some sort of configuration) to use the concurrent collections package.
|
|
|
Message #229732
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: The Multi-Core Dilemma
It was not clear from the posting, but I am the author of this post. Sorry for the confusion.
Several people pointed out application scenarios where this does not apply, and I completely agree. This is not a problem for all applications. Most web apps, for example, don't have to worry about the order in which they serve requests. These applications should scale fine on multi-core without modification (although you may want to test them to ensure that they behave as expected).
There is a class of enterprise applications, however, that will have this issue. I have seen it in customer environments and in my team's testing. Applications that have scalability requirements and have to ensure ordered processing (FIFO, for example) have the challenge of combining concurrency with order. If we go by the 80/20 rule, this would be the 20% or so. This can be done using threads in Java, but I think most people would agree that it adds significant complexity to the design and testing efforts for these applications.
Patrick Leonard
|
|
|
Message #229907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: 3Ghz vs 2.6GHz
As long as "enterprise" software is concerned, I have yet to see any single user needing the full power of 3GHz and cannot live with 2GHz.
"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981
Hmm... sounding familiar
Yes, we may as well include the other famous quotes on this issue:
"Computers in the future may weigh no more than 1.5 tons."
- Popular Mechanics, 1949
"I think there is a world market for maybe five computers."
- Thomas Watson, chairman of IBM, 1943
Not only are clock speeds going to increase, but we're very soon going to have widespread use of 4 core processors. Before we know it, we're going to be using 16 and 32 core processors.
PJ Murray
CodeFutures Software
Data Access Objects and Service Data Objects
|
|
|
Message #230062
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Single level storage
Regarding solid state:
For your notebook, you can now get flash drives up to 64GB, and 128GB by the end of the year. More expensive of course.
For data centers, solid state hard drives have been available for years. But these are still drives, logically. It would be much better to hot-plug a "drive" that would map right into main memory space. Kind of like memory-mapped files, but extended to a whole drive. All memory including "storage" would be a unified space.
I believe the iSeries has employed this model ("single level storage") for many years.
|
|
|
Message #230147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: single vs. multi core
Another thing that I haven't noticed anyone mention is that it's extremely rare for any server or desktop machine to be dedicated to a single process. Even if an app doesn't make use of multi-threading, it will probably get some significant benefit from not having to share a CPU with other processes.
If we are talking about Java apps, you can get a immediate benefit without using any threads in your code at all by turning on concurrent collections.
Are you talking about java.util.concurrent collecions or the oswego stuff? They are great for insert-only or read-mostly caches, but you still have to be aware how you use them.
No, I actually meant concurrent garbage collectors. Sorry, I see now how unclear that was. You'd definitely have to change the code (or at least some sort of configuration) to use the concurrent collections package.
An app that does not use multi-threading will get some benefit from additional cores, but it's generally not significant as compared to the number of additional cores. For example, in one test that we did, moving a business transaction app from single to 4 cores increased throughput by 50-75%. But this was from shared overhead, not from sharing across cores.
Servers with 16 or 32 cores will be common soon, and in the hundreds in the next few years. So the benefit of the shared overhead will be minor. Using pipelines to share across cores in this test took it to almost 4x - close to linear - and this will scale up to higher numbers of cores.
Patrick Leonard
Rogue Wave Software
|
|
|
Message #230817
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: single vs. multi core
theserverside.com will always accept dual cores dont about theclientside.com :(
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
