• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Single core vs Quad core

 
Ranch Hand
Posts: 231
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What’s the difference between single core and quad core computers. It is like having one arm (one CPU) versus have four arms (four CPUs). With one arm, you can execute multiple tasks and multiple threads at the same time but with four arms you can do the same with increased responsiveness? Is the main difference that a quad core computer is simply more responsive than a single core computer when dealing with large computation-intensive applications?

Also, is there any real difference between programming an application for a single core computer versus programming an application for a quad core computer? This thread says “Java can't scale to multiple processors in a world of 8 core desktops and quad core cell phones”
 
Saloon Keeper
Posts: 12170
258
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Applications may be run using one or more threads. To facilitate responsiveness, the operating system schedules running time on a processor for all threads, and swaps threads very quickly so it seems that threads are running at the same time. In a single-core processor, two threads are never running at the same time. In a quad-core processor, four threads can run at the same time, but of course, since there are multiple applications and each may have multiple threads, swapping still needs to be done.

In Java, it doesn't make a difference whether you're running on a single- or multi-core processor, except that performance may be higher on a multi-core processor. You need to make special precautions when your application runs using multiple threads, but this is unrelated to the amount of processor cores.
 
Stephan van Hulst
Saloon Keeper
Posts: 12170
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Cox wrote:This thread says “Java can't scale to multiple processors in a world of 8 core desktops and quad core cell phones”


I don't see how Java can't scale with multiple processor cores.
 
Ranch Hand
Posts: 165
12
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All I would add to Stephen's answer is to clarify that you won't get the benefit of multiple cores if your application is single threaded because a thread cannot be divided across cores concurrently. So if you want to exploit the benefit of multi-core then you have to write a multi-threaded application (*see below). The corollary is that a multi-threaded application will work fine on single core hardware but the threads are actually time-sliced, not concurrent.

On scaleabilty there isn't anything to worry about in the average application with a modest number of threads. I do recall reading somewhere about lock contention issues when you scale up to thousands of threads but if your application is going to be that big then you would research these issues in depth and factor this into your design.

(* or you could run multiple process instances of your single-threaded application in parallel)

 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Cox wrote:Is the main difference that a quad core computer is simply more responsive than a single core computer when dealing with large computation-intensive applications?


It depends on how the software is written.

Daniel Cox wrote:Also, is there any real difference between programming an application for a single core computer versus programming an application for a quad core computer?


Absolutely; programs don't automatically use multiple cores. They have to be designed and written to use multiple threads. A program doesn't automatically run 4 times as fast on a quad-core computer compared to a single-core computer.

Daniel Cox wrote:This thread says “Java can't scale to multiple processors in a world of 8 core desktops and quad core cell phones”


That's simply not true, Java has had very good support for multi-threading since the beginning, and it's one of the reasons why it is still hugely successful for server-side software.
 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Cox wrote:With one arm, you can execute multiple tasks and multiple threads at the same time but with four arms you can do the same with increased responsiveness?


I think everybody else has pretty much covered it, but one thing that's probably worth mentioning is just how fast modern processors (even single-core ones) are.
They are staggeringly fast: So fast that even with the overhead of a proper time-slicing OS, scads of sophisticated devices, acres of managed memory and networking, they generally spend most of their life idle.

To give you an idea (and this is something I read several years ago now): modern chips can now switch in peko-seconds...or in the time it takes electricity to travel a tenth of an inch.

Cores simply multiply that speed by however many there are, since now the OS (or thread-scheduler) can choose which one to use. Jjust think of a core as a completely independent CPU - although it's probably a bit more involved than that. And oddly enough, they came about (I'm pretty sure) because we're hitting the limits of the speed of solid state technology.

So maybe they're just a final interim step before the first quantum CPUs.

Winston
 
Daniel Cox
Ranch Hand
Posts: 231
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to everyone for your help but I'm still unclear about something.

I read the following in Chapter 14 OCP Certification Guide by S G Ganesh & Tushar Sharma.

From the beginning, Java supported concurrency in the form of low-level threads management, locks, synchronization, and APIs for concurrency.

Since 5.0, Java also supports high-level concurrency APIs in its java.util.concurrent package. In this chapter, we’ll focus on these APIs for concurrent programming. These high-level APIs exploit today’s multi-core hardware, in which a single processor has multiple cores. These APIs are also useful for exploiting concurrency in machines that support multiple processors.


What's the difference between programming a multi-threaded pre-Java 5 application and a multi-threaded post-Java 5 application? The quote from the OCP Certification Guide seems to suggest that a multi-threaded pre-Java 5 application cannot fully exploit concurrency in today’s multi-core hardware.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Cox wrote:What's the difference between programming a multi-threaded pre-Java 5 application and a multi-threaded post-Java 5 application? The quote from the OCP Certification Guide seems to suggest that a multi-threaded pre-Java 5 application cannot fully exploit concurrency in today’s multi-core hardware.


Well, in the old days you basically just had synchronized; which was an exclusion protocol, and a bit of a sledgehammer. Now you have all sorts of "atomic" variable types, and lock types that you manage yourself; not to mention volatile fields, so the whole business of managing concurrency is much richer now.

That doesn't mean to say it's any easier though; and I honestly don't know how it makes use of this new hardware. I just assume I don't have to.

Winston
 
Jesper de Jong
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Daniel Cox wrote:What's the difference between programming a multi-threaded pre-Java 5 application and a multi-threaded post-Java 5 application?


In Java 5, lots of new, useful classes were added in the package java.util.concurrent. See the API documentation.

Daniel Cox wrote:The quote from the OCP Certification Guide seems to suggest that a multi-threaded pre-Java 5 application cannot fully exploit concurrency in today’s multi-core hardware.


No, that's not the case. There were no new features added to the language, just to the standard library. With older versions of Java you could still do anything you needed, it was just a lot harder because you'd have to write more code yourself, for which there are standard classes since Java 5.

I remember writing my own thread pool classes in Java 1.4. It was hard to get all the concurrency bugs out. Since Java 5 you don't need to write your own thread pool anymore because there's java.util.concurrent.ExecutorService and related classes.
 
Daniel Cox
Ranch Hand
Posts: 231
12
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all for your insightful posts

In order to gain further insight, I’ve been browsing through The Well-Grounded Java Developer by Benjamin J. Evans (Manning, 2013) and I have made the following conclusions.

The advantages of Java 5 and post-Java 5 code over pre-Java 5 code are:
  • ease of use
  • greater clarity
  • greater reliability

  • Chapter 4 says:

    Java’s thread- and lock-based concurrency is very low-level, and often hard to work with. To cope with this, a set of concurrency libraries, known as java.util.concurrent, was introduced in Java 5. This provided a set of tools for writing concurrent code that many programmers find easier to use than the classic block-structured concurrency primitives.



    If you have existing multi-threaded code that is still based on the older (pre-Java 5) approaches, you should refactor it to use java.util.concurrent. In our experience, your code will be improved if you make a conscious effort to port it to the newer APIs—the greater clarity and reliability will be well worth the effort expended to migrate in almost all cases.


    The advantage of multi-core processors over single-core processors is better performance (especially with computation-intensive multi-threaded applications).

    Chapter 6 says:

    The future of performance is intimately tied to concurrency—one of the main ways that a system can be made more performant overall is by having more cores. That way, even if one core is waiting for data, the other cores may still be able to progress.

     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Daniel Cox wrote:Chapter 6 says:

    The future of performance is intimately tied to concurrency—one of the main ways that a system can be made more performant overall is by having more cores. That way, even if one core is waiting for data, the other cores may still be able to progress.


    Not sure I agree with that. It assumes that:
    (a) We'll always need to be able to tell computers how to do stuff like concurrency, rather than simply say "this is what I want to do; you go do it".
    (b) CPUs will always look like they do now - ie, gazilions of transistors in linked grids that are good at doing one thing at a time in binary. 100 years from now they may be based on DNA or "chemical soups" or quantum mechanics, and concurrency (and very possibly AI) will be "built in".

    And all us programming types will be packing bags at Tesco or Walmart.

    Winston
     
    Daniel Cox
    Ranch Hand
    Posts: 231
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:Not sure I agree with that.


    If not better performance, why do you think that processors these days have multiple cores?
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Daniel Cox wrote:If not better performance, why do you think that processors these days have multiple cores?


    I thought I'd already explained myself. Because they've already approached the limits of the performance available from current technology, so they merely give you a stack of them that modern systems (and probably the architecture itself) can exploit.

    I'm quite sure that quad-core or even oct-core will be old hat before long; but I doubt you'll be seeing the logarithmic increase in clock speeds we've had for the last fifty years in even the next twenty - unless it's measured by some new "throughput" or "processing" metric, probably created by the manufacturers themselves based on optimal slicing and dicing.

    And even if the statement is true ("The future of performance is intimately tied to concurrency"), I think that CPUs will be able to handle their own concurrency far better (and far more dynamically) than we can very soon.

    And oddly enough, I find it liberating. One less thing to worry about (which is always good at my age ). Java showed me that memory is simply a space that I don't have to manage or worry about any more; why shouldn't new hardware do the same for concurrency?

    Winston
     
    Steffe Wilson
    Ranch Hand
    Posts: 165
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Daniel Cox wrote:Chapter 6 says:

    The future of performance is intimately tied to concurrency—one of the main ways that a system can be made more performant overall is by having more cores. That way, even if one core is waiting for data, the other cores may still be able to progress.


    Actually that quote troubled me too, at least the second part of it, but for a different reason.

    Perhaps I am being pedantic here but its not the cores that allow part of an application to progress whilst another part is waiting for data, its the threads. (Or some other implementation of asynchronous I/O, but lets ignore that for now.)

    So long as your application is multi-threaded then runnable threads can progress whilst blocked threads are waiting regardless of whether you have multiple cores. In a single core system the OS can context switch to a different runnable thread whilst your first thread is waiting on I/O.

    Adding more cores allows more to happen in parallel only if there is more CPU work that can be undertaken.

    Let's say your application has two threads. If you have two cores and one of the two threads is waiting on I/O then there is no advantage over one core because only one thread can do any work and the second core would be idle (from the point of view of the application).

    Multi-core gives the greatest benefit in CPU-intensive applications as indicated earlier, rather than with I/O-constrained applications as suggested by this quote. But in fairness to the original author we are only looking here at a tiny snippet of his chapter.
     
    Ranch Hand
    Posts: 239
    12
    Scala IntelliJ IDE Eclipse IDE Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    In My Humble Opinion...

    ...I'm going to disagree with you all...

    The Java approach to concurrency is outdated now. It's better now with Java 8 but all that Java 5 library stuff is based on imperative programming and mutable objects. Other languages are winning in this space because they are functional and immutable which works better for multi-core. Here is an interesting essay from around the same time period as the referenced thread that started this whole conversation. The Downfall of Imperative Programming

    So yes, it is accurate to say Java can't scale to multiple processors. At least at the time that it was written. Java 8 is an attempt to address that very issue. IMHO
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Scott Shipp wrote:In My Humble Opinion...


    Gets a cow from me.

    Winston
     
    Scott Shipp
    Ranch Hand
    Posts: 239
    12
    Scala IntelliJ IDE Eclipse IDE Java Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:

    Scott Shipp wrote:In My Humble Opinion...


    Gets a cow from me.

    Winston



    Wow thanks Winston!
     
    Daniel Cox
    Ranch Hand
    Posts: 231
    12
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think that the Chapter 6 statement is supported by this Wikipedia statement which sheds more light on the motives that have driven the development of multi-core architectures.

    As the rate of clock speed improvements slowed, increased use of parallel computing in the form of multi-core processors has been pursued to improve overall processing performance.

      Bookmark Topic Watch Topic
    • New Topic