 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007How to use power of Dual/ Quad core Processors in Applet?
I have a large Applet I wish to use Dual/ Quad core Computers to take advantage of all the 4/ 2 processors they have. Will the JVM automatically gives each thread devoted to one core or have to write something to assign different cores to different cores? Bye Sanny Sanny a écrit : > I have a large Applet I wish to use Dual/ Quad core Computers to take > advantage of all the 4/ 2 processors they have. > > Will the JVM automatically gives each thread devoted to one core or > have to write something to assign different cores to different cores? If you write carefully your program with multiple threads, the JVM should assign them to different cores. But it may also depend of the operating system.  SignaturePatrick > Sanny a ?crit : > [quoted text clipped - 10 lines] > -- > Patrick Actually, The threads themselves may not be "assigned" to specific cores, but when a core becomes free, the OS will choose which thread to schedule on that core. Although the actual algorithm is somewhat complicated, its fair to say that using multiple threads will give you a fairly even distribution among the cores, assuming you're using a modern OS and modern JVM. > Actually, The threads themselves may not be "assigned" to specific > cores, but when a core becomes free, the OS will choose which thread > to schedule on that core. Although the actual algorithm is somewhat > complicated, its fair to say that using multiple threads will give you > a fairly even distribution among the cores, assuming you're using a > modern OS and modern JVM. Does Unix, Windows 98, Windows XP, Windows Vista, OS/2, Linux etc support Dual & Quad Processors. My Applet is for everyone. So I want it to work on every Operating System. One more Question does an Applet gets only those resources which Browser provides? Will it depend also on which browser the user is using. Is there a Chart where I can see which Browsers and Operating Systems support Dual Core/ Quad core Processoors. And Maximum how many threads can be created for an Applet. Can I create 100 or 1000 threads running Simultaniously without crashing the Browser? JAVA was once a very modern language but I feel it is loosing it's importance because of Microsoft Monopoly. Why do Microsoft not give enough support for Java. We see Flash works better than Applets and faster, While even little Applet takes lot of time to download. Why Browsers do not support Applet as par as Flash. Bye Sanny >Is there a Chart where I can see which Browsers and Operating Systems >support Dual Core/ Quad core Processoors. You can find out with a simple benchmark than starts N threads to complete N chunks of compute intensive work. Compare that with the time to run 1 thread to do N chunks of compute intensive work. see http://mindprod.com/jgloss/benchmark.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > Does Unix, Windows 98, Windows XP, Windows Vista, OS/2, Linux etc > support Dual & Quad Processors. I know Solaris has supported multiple processors for a long time, same with Linux. I'm pretty sure Vista and XP do because I remember having support for dual processors even with NT. - Kurt >I'm pretty sure Vista and XP do because I remember >having support for dual processors even with NT. Duals have been supported since NT days, but I don't know about Quads. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> I'm pretty sure Vista and XP do because I remember >> having support for dual processors even with NT. > > Duals have been supported since NT days, but I don't know about Quads. Workstation is limited to 2. Server is limited to 4 and 8 depending on version (it is claimed that version with 32 exist, but ...). Arne > Duals have been supported since NT days, but I don't know about Quads. One thing I could never figure out on that machine is, when I would run a process that sucked down a lot of CPU, and took a long time, it would hit both of the processors at 50%. I'd think a single process would hit the one processor at 100% (this was not a multi-threaded app). I'm wondering if the process manager would just indicate that both were being used to make me feel like I was getting my money's worth out of the machine. Around the same time, on our Solaris server, one process would max out one processor. We would fire up another process, and see the other processor fire up. - Kurt > > Duals have been supported since NT days, but I don't know about Quads. > [quoted text clipped - 4 lines] > wondering if the process manager would just indicate that both were being > used to make me feel like I was getting my money's worth out of the machine. The Windows scheduler will sometimes move threads from one processor to another, so you can indeed have a single-threaded app using 50% of each of two cores. Set a processor affinity for this process using Task Manager and confine it to one core, and you'll see it run that core at 100% and leave the other idle. > each of two cores. Set a processor affinity for this process using > Task Manager and confine it to one core, and you'll see it run that > core at 100% and leave the other idle. Ah. Although, I generally try not to mess with these things. My assumption is the people who design the kernel know a lot more about how to split up resources than I do.... - Kurt > > each of two cores. Set a processor affinity for this process using > > Task Manager and confine it to one core, and you'll see it run that [quoted text clipped - 3 lines] > is the people who design the kernel know a lot more about how to split up > resources than I do.... I'm not sure that's a safe assumption in the one special case that the people in question work in Redmond. I've had some fairly wacko behavior happen on dual core Windoze boxen. One XP SP2 system running a compute-intensive mathematical visualization tool caused temporary system freezes and stuttering when running on a dual-core machine until forced to only use one core via Task Manager. In another case, 1 high priority task and 2 low priority tasks were running, the latter having equal proprities. The high priority task hogged the whole CPU until confined to one core, whereupon the low priority tasks should have divvied up the other core but didn't -- one hogged it and the other was starved. OTOH I know that actually programming a scheduler to work ideally is non-trivial. Weird glitches like "priority inversion" will happen with some (and just about all na?ve) implementations in some situations with particular combinations of relative priorities, processes sleeping or blocked on I/O or lock acquisition, and processes awake. I wouldn't be surprised if even non-Redmond developers don't always get it right even on serial hardware. >One XP SP2 system running >a compute-intensive mathematical visualization tool caused temporary >system freezes and stuttering when running on a dual-core machine >until forced to only use one core via Task Manager. From Microsoft's point of view, they worry first about making good programs work properly on dual core. After that is working they can think about how to stop a defective program from freezing the machine. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Jul 24, 3:19 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >One XP SP2 system running > >a compute-intensive mathematical visualization tool caused temporary [quoted text clipped - 4 lines] > programs work properly on dual core. After that is working they can > think about how to stop a defective program from freezing the machine. Microsoft now sometimes worries about making programs work properly? When did this happen? There was no news announcement or fanfare... >> Actually, The threads themselves may not be "assigned" to specific >> cores, but when a core becomes free, the OS will choose which thread [quoted text clipped - 5 lines] > Does Unix, Windows 98, Windows XP, Windows Vista, OS/2, Linux etc > support Dual & Quad Processors. Windows 98 does not. I am not sure of OS/2. The rest should. > My Applet is for everyone. So I want it to work on every Operating > System. Java shoudl enable you to do that. > One more Question does an Applet gets only those resources which > Browser provides? Will it depend also on which browser the user is > using. It should depend on th JVM used. > Is there a Chart where I can see which Browsers and Operating Systems > support Dual Core/ Quad core Processoors. You should read documentation for the OS's. > And Maximum how many threads can be created for an Applet. Can I > create 100 or 1000 threads running Simultaniously without crashing the > Browser? In theory yes. But all JVM's are not bug free. Note that 1000 threads will be painfully slow (unless it is a very huge system). > JAVA was once a very modern language but I feel it is loosing it's > importance because of Microsoft Monopoly. Why do Microsoft not give > enough support for Java. We see Flash works better than Applets and > faster, While even little Applet takes lot of time to download. Why > Browsers do not support Applet as par as Flash. Why did you expect MS to help the competition ?? Arne > I have a large Applet I wish to use Dual/ Quad core Computers to take > advantage of all the 4/ 2 processors they have. > > Will the JVM automatically gives each thread devoted to one core or > have to write something to assign different cores to different cores? Just use threads to divide up the computational work in your application. >Will the JVM automatically gives each thread devoted to one core or >have to write something to assign different cores to different cores? So long as you have multiple threads, the multiple processors will be automatically exploited. The JVM does not assign a thread to a processor. On each slice the OS just gives the highest priority waiting thread to the first available processor. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > >Will the JVM automatically gives each thread devoted to one core or > >have to write something to assign different cores to different cores? [quoted text clipped - 6 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com Are you sure about this? Due to the problems with multi-core memory models I would expect a lot of Java code to fail due to lack of proper synchronization (which also handles memory synchronization between CPUs). I think some OSs have an affinity for a single CPU, at least I would not assign an application to multiple cores at the same time unless I was told the application could live in a multi-core world. Kind regards, Peter Kriens > On Jul 20, 10:17 am, Roedy Green <see_webs...@mindprod.com.invalid> > wrote:> >Will the JVM automatically gives each thread devoted to one core or [quoted text clipped - 12 lines] > synchronization (which also handles memory synchronization between > CPUs). Threaded code that doesn't synchronize properly will experience buggy behavior even on single-CPU systems. Threaded Java code that does synchronize properly should not experience buggy behavior on multi-CPU systems (at least, none that it can't also exhibit on single-CPU systems, i.e. buggy behavior that it can exhibit due to having bugs unrelated to race conditions, deadlocks, and other concurrency issues) and should naturally use the available cores subject to OS multiprocessing support and any OS affinity configuration. (Windows users can use task manager to force a running javaw.exe onto a single core or more generally a specific subset of the available cores, for example, but by default it will spread out to use them all, at least under the ubiquitous XP SP2.) Bug-free compute-intensive threaded Java code appears to function correctly and attain full CPU utilization on a dual-core Athlon with XP SP2 and Java 1.6.0_0something, in actual practise, also. Roedy Green wrote: >>> So long as you have multiple threads, the multiple processors will be >>> automatically exploited. The JVM does not assign a thread to a >>> processor. On each slice the OS just gives the highest priority >>> waiting thread to the first available processor. pkriens wrote: >> Are you sure about this? Due to the problems with multi-core memory >> models I would expect a lot of Java code to fail due to lack of proper >> synchronization (which also handles memory synchronization between >> CPUs). Of what "multi-core memory models" do you speak? Java has a well-defined memory model that the JVM on any system must follow. How is its memory model subject to "the problems with multi-core memory models"? (Be specific and precise.) Why would you expect "a lot of Java code to fail due to lack of proper synchronization" in greater proportion on multi-core systems than on single-core systems, given that both have to follow the Java Memory Model? Do you blame Java? > Threaded code that doesn't synchronize properly will experience buggy > behavior even on single-CPU systems. Threaded Java code that does > synchronize properly should not experience buggy behavior on multi-CPU > systems ... [more accurate and cogent information followed] Exactly. The memory model is the same. Concurrent programming is tricky. If pkriens were to actually study it, they might find that the Java Memory Model exists specifically to address issues that come up on multi-CPU systems but not on single-core systems. So whether Roedy is sure about his assertion or not, I sure am. SignatureLew >Are you sure about this? Due to the problems with multi-core memory >models I would expect a lot of Java code to fail due to lack of proper >synchronization (which also handles memory synchronization between >CPUs). I think some OSs have an affinity for a single CPU, at least I >would not assign an application to multiple cores at the same time >unless I was told the application could live in a multi-core world. You are saying the hardware is at fault -- it does not share memory between multi CPU caches as advertised? I know nothing about this. I am merely repeating a response given when someone a long time ago asked about how you lock a thread onto a CPU. A single CPU program will mask threading bugs longer than a dual CPU, so you should test multithreading code on a dual CPU. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Jul 22, 1:17 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >Are you sure about this? Due to the problems with multi-core memory > >models I would expect a lot of Java code to fail due to lack of proper [quoted text clipped - 14 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com The Java memory model allows the caches of the processors to differ for variables that are not synchronized or volatile. So on processor A you can read a different value for variable x than on processor B until they are synchronized. Code that works well on a single processor because there is only one memory can fail subtly on multiple processors. Obviously the code is wrong, but I think it makes sense to schedule Java programs on a single CPU unless specifically allowed. Kind regards, Peter Kriens > The Java memory model allows the caches of the processors to differ > for variables that are not synchronized or volatile. So on processor A Not accurate. It also allows them to differ for variables that are volatile or accessed in a synchronized way, at times. It also requires that non-volatile variables and those accessed outside synchronized blocks follow certain visibility rules. > you can read a different value for variable x than on processor B > until they are synchronized. Code that works well on a single > processor because there is only one memory can fail subtly on multiple > processors. Obviously the code is wrong, but I think it makes sense to > schedule Java programs on a single CPU unless specifically allowed. So you are suggesting that one not fix broken code, instead just try to get your customers not to run it on multi-processor machines? I cannot imagine any responsible developer advocating such a practice. And it isn't "code hat works well o0n a single processor"; it's code that is equally broken on a single processor. What an irresponsible suggestion. SignatureLew >> The Java memory model allows the caches of the processors to differ >> for variables that are not synchronized or volatile. So on processor A [quoted text clipped - 17 lines] > that is equally broken on a single processor. What an irresponsible > suggestion. You are aware that single-processor machines also reschedule instructions and data, and that broken thread code on even single-processor machines can manifest its bugs, aren't you? In other words, that your short-sighted and irresponsibly lazy idea won't even work reliably anyway? SignatureLew >You are aware that single-processor machines also reschedule instructions and >data, and that broken thread code on even single-processor machines can >manifest its bugs, aren't you? In other words, that your short-sighted and >irresponsibly lazy idea won't even work reliably anyway? Please. Can the ad hominems. It is enough to attack the idea. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> You are aware that single-processor machines also reschedule instructions and >> data, and that broken thread code on even single-processor machines can >> manifest its bugs, aren't you? In other words, that your short-sighted and >> irresponsibly lazy idea won't even work reliably anyway? > Please. Can the ad hominems. It is enough to attack the idea. What ad hominem? I said the /idea/ was irresponsibly lazy, nothing about any individual. In other words, I was already following your advice. SignatureLew >What ad hominem? I said the /idea/ was irresponsibly lazy, nothing about any >individual. In other words, I was already following your advice. Ideas are not lazy. People are. You characterised him as lazy for his error. That was uncalled for. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> What ad hominem? I said the /idea/ was irresponsibly lazy, nothing about any >> individual. In other words, I was already following your advice. > > Ideas are not lazy. People are. You characterised him as lazy for his > error. That was uncalled for. I swear it's the idea I was talking about. Feel free to misinterpret my words, but I called the idea lazy, not the person. I have no reason to lie about it. I happen not to agree with your statement "ideas are not lazy". Therefore it is possible for me to call an idea lazy, as I did. You will notice that I was careful in my post to use the word "idea" as the target of the adjective. Please do not distort my words or change their intent. I am telling you that I intended to describe the idea as lazy, not the person. You can tell me that I mean something different, but I think I am the authority on my own intent. SignatureLew >> The Java memory model allows the caches of the processors to differ >> for variables that are not synchronized or volatile. So on processor A [quoted text clipped - 17 lines] > that is equally broken on a single processor. What an irresponsible > suggestion. I think two issues are getting confused here: 1. Should all code be written, reviewed, and tested, to be correct assuming only the memory model rules in the JLS. My answer is *YES*. 2. Should multi-threaded code be assumed safe to run on multiple cores, given only experience of its reliability on a single processor? This is a much more difficult question. There are bugs that will show up only under high stress with relatively low probabilities on a single core, but that are more likely to be visible on multiple cores. I am especially concerned about Java because it makes shared memory multi-threading look much easier than it is. Patricia >>> Will the JVM automatically gives each thread devoted to one core or >>> have to write something to assign different cores to different cores? [quoted text clipped - 8 lines] > would not assign an application to multiple cores at the same time > unless I was told the application could live in a multi-core world. Assuming that: - the Java program is written correctly according to Java memory model - the JVM is implemented correctly then it will work. Multi CPU or core context is just more likely to see buggy code actual fail. But the code is not less buggy on a single CPU and core system and it could also fail there - it may just be one out of a million instead of one out of two chance. Arne Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.