Possible to force my java app to use more CPU utilization?

[grecinos]

Hey folks,

I've been developing a Java applet that requires significant CPU utilization. For the moment, I'm only able to run it from the IDE, Java NetBeans. I've been having issues getting it to work on a web browser due to security issues. Nevertheless, when I run the app, I noticed that the Task Manager shows about 20% CPU utilization. Is this a limitation of the OS (Windows 10, 64-bit)? I'd like for it to utilize at least 70% of the CPU'S capability, if not more. Is there a way to force my app to utilize the CPU to that extent?

The laptop PC's I've been running the app on have Intel CPU's (i7-4720HQ, 3610QM) with 24GB and 32 GB of RAM respectively. They both have the latest Java JDK/JRE installed.

Any and all advice is greatly appreciated.

Cheers.

 

[R-T-B]

You are probably using all of one core of a quad core. You'll need to multithread your app to get more performance. This is not necessarily easy.

 

[Capitan Harlock]

Hi , you can try to set the cpu priorities to real time and set the affinity too and lower the ones of other applications.

Edit: inside taskmanager.

 

[newtekie1]

I don't even thinkg Java apps can be multi-threaded. If they could, I'd think programs like Minecraft would have done it long ago, but they haven't.

 

[FordGT90Concept]

http://www.tutorialspoint.com/java/java_multithreading.htm

 

[grecinos]

Thanks for the quick responses.

Captain Harlock: I was able to modify the CPU priorities and affinity. But there wasn't any change in the CPU utilization.

Ford: Thanks for the link, there's a lot of information in that article, but at first glance, I don't think it said anything with respect to CPU utilization across all cores.

I was hoping that there would be a compiler directive that enables the use of all cores on the CPU. I've already enabled the directive to compile the code to 64-bit mode (for lack of better terminology).

Any other ideas?

 

[LFaWolf]

There is no single compiler directive or library that can instantly turn your app into multi-threaded, because that would be too easy

Are you making a Java application (jar)? To make any multi-threaded application, you really need to think carefully and structure your code so that the compiler/runtime knows certain sections of code or method calls can be done asynchronously, in C# such as Task or async. Otherwise, the runtime will not know where to hand off computation to a different thread. Of course, with modern compilers there will be built in improvement to speed up certain tasks using multiple threads, but to make your code a multi-threaded app, you will need to do it yourself.

Most applications are fine running single thread, such as Word or Powerpoint. Multi-threaded apps are suited for computation intensive apps such as scientific or gaming. Few apps need that hence developers general don't spend time doing it, as the task is not easy. That is also why you see some games are poorly optimized to run on multi-core processors. What app are you making require so much computation?

 

[Aquinus]

Java doesn't just automatically make your code run concurrently. You need to tell Java that and you need to do extra work to make sure that it remains thread safe and a lot of times, people who don't know what they're doing, won't see any performance benefit because you can't just throw more threads and more cores at a problem and expect everything to work out. I personally don't really write Java very often anymore but, I do write a lot of Clojure which runs on top of the JVM and I can say that it's very capable of utilizing a quad-core CPU.

Whenever you decide to make an application multi-threaded, there are a lot of questions you need to be asking yourself because there is always a trade-off with using additional threads.

So, if you want us to help you think through what parts of your application can be made to be concurrent and yield the most likely case of improving performance, then you need to tell us a bit about the problem you're trying to solve, otherwise this thread ends right here because as someone who writes multi-threaded code that runs on the JVM, I can't help if I don't know what the task is.

 

[grecinos]

I've been away from Java for a while, so my code is not the most efficient. Nevertheless, like I stated in my first post, It's a Java Applet. The purpose is to make interesting linear designs through animating individual points. I put it in an infinite update/repaint loop, as per the conventional method to make applets animate and execute code to handle updates with each iteration. I suppose you could say that is the primary thread. Every loop, it recalculates the new position of the individual points, and draws them to an image buffer. I use double buffering to make the animation appear smooth. The other half of the app is the UI. I used Netbeans to create the UI (a JFrame) that the applet instantiates. The applet has a timer that executes code every 10 ms. Every 10 ms, the applet checks the UI for state changes in the UI controls and performs the appropriate action. It has a bunch of Jbuttons, Jsliders, Jlist boxes, etc.

That chunk of code looks like this:

Timer timer = new Timer(10, new ActionListener()
{
@Override
public void actionPerformed(ActionEvent e)
{
//User input handling goes here...
}
});
timer.setRepeats(true);
timer.start();

I used a Timer because it was the simplest to implement. There's likely a better way to do this, but it works just as I had envisioned. Lastly, the meat of the code is in calculating the position and colors of the individual pixels. I'm using a lot of mathematical functions like sin, cos, etc. This is where most of the CPU spends it's time calculating. That's pretty much it. Simple in design. My objective, for the moment, is to get this app to utilize the CPU to the extent of it's capability. I don't care if that means multi-threading or code optimization. I guess you can say, whatever works without mangling the code...

 

[Aquinus]

I guess you can say, whatever works without mangling the code.

Then stop right now because you'll need to mangle that calculation of pixel colors and positions to multi-thread it in a useful way, assuming it's not a calculation that also has some sort of effect. There is no switch to use the rest of your CPU.

In all seriousness, you should use a queue in front of and after the calculations with sin, cos, etc. so you can scale the number of workers doing strict math to the resources available on the machine being used. Since these workers are merely processing data (which means, no side-effects,) then the threads can merely stick around and you just feed a queue and pull from the queue (you could even use a thread pool.) Just keep in mind there is coordination overhead that needs to be factored in and you can't do this by not changing your code, probably significantly.

Java Applet

No one uses applets anymore.

 

[grecinos]

Then stop right now because you'll need to mangle that calculation of pixel colors and positions to multi-thread it in a useful way, assuming it's not a calculation that also has some sort of effect. There is no switch to use the rest of your CPU.

Yea, I think the added complexity isn't worth improvement in performance.

No one uses applets anymore.

I'm considering porting the applet code to a standard Java app. As I've mentioned in the first post, the primary reason I wanted to create an applet was to be able to have it run in a web browser. Unfortunately, I'm finding it more and more difficult to get it to work due to security issues. Does animation work just as well with a JFrame? If so, what combination of Swing Containers/Controls/Windows works best?

 

[FordGT90Concept]

Since your focus is web, perhaps you should look into HTML5 animation instead:
http://www.html5canvastutorials.com/advanced/html5-canvas-animation-stage/

Pretty sure browsers run animations in the GPU so you're killing two birds with one stone (no more security issues and should vastly improve draw performance).


If you demand to stick to Java, is each frame static? Do you know the inputs and outputs of frame 2 and 3 while working on frame 1? If yes and yes, you could create a function which draws each frame given the frame number and have the number of processors minus one (for main thread) drawing a frame. Have the main thread pull from the queue of finished frames at a regular interval and order the thread that it took the frame from to work on the next frame in the queue. In a quad core processor (three workers), for example, it would wait for frame 1 from worker 1 then worker would start on frame 4 while the main thread draws frame 2 from worker 2 (so on and so fourth).

 

[Aquinus]

Since your focus is web, perhaps you should look into HTML5 animation instead:
http://www.html5canvastutorials.com/advanced/html5-canvas-animation-stage/

Pretty sure browsers run animations in the GPU so you're killing two birds with one stone (no more security issues and should vastly improve draw performance).

I was just about to suggest this. Good advice.

 

[R-T-B]

I don't even thinkg Java apps can be multi-threaded. If they could, I'd think programs like Minecraft would have done it long ago, but they haven't.

Ironically, Java is one of the most multithreading friendly languages around. Minecraft is just a coders nightmare.

 

[Aquinus]

Ironically, Java is one of the most multithreading friendly languages around. Minecraft is just a coders nightmare.

This in the sense that it has some of the best facilities for doing it but, I wouldn't call it easy in the sense that locking is the only way to handle controlled mutation of a thread-safe reference. Clojure, being a functional lisp on that runs on the JVM makes multi-threading a piece of cake and it uses the JVM for that reason. A dynamic language that runs on the JVM and can run almost as fast as native java, is freaking awesome. I use it and evangelize it for a reason.

https://benchmarksgame.alioth.debian.org/u64q/clojure.html
Disclaimer: The benchmark game is both a benchmark and a game.

I'm not fanatical about many things but, Clojure is one of them.

 

[grecinos]

Since your focus is web, perhaps you should look into HTML5 animation instead:
http://www.html5canvastutorials.com/advanced/html5-canvas-animation-stage/

Pretty sure browsers run animations in the GPU so you're killing two birds with one stone (no more security issues and should vastly improve draw performance).

This looks interesting. How does this compare to Java in terms of speed?

If you demand to stick to Java, is each frame static? Do you know the inputs and outputs of frame 2 and 3 while working on frame 1? If yes and yes, you could create a function which draws each frame given the frame number and have the number of processors minus one (for main thread) drawing a frame. Have the main thread pull from the queue of finished frames at a regular interval and order the thread that it took the frame from to work on the next frame in the queue. In a quad core processor (three workers), for example, it would wait for frame 1 from worker 1 then worker would start on frame 4 while the main thread draws frame 2 from worker 2 (so on and so fourth).

My main class is a stand-alone applet that instantiates a Jframe for user controls. I can access the properties and controls this way. Ideally, I'd like to create another Jframe as a "drawing canvas" where the animation will take place. I've yet to figure this out. I'm assuming the drawing canvas will require a Swing JPanel and perhaps a JLabel. My best guess is that I will need to update the JLabel with the graphics I wish to display/animate.

 

[grecinos]

Well... I decided to port My applet to a Java App. I took the 1% inspiration, 99% perspiration approach. After a significant amount of research, I was able to do it. No mangling of the code, just well thought out adjustments. So now, I can run the app from the command-line, whereas before, I was bound to the IDE. Cool stuff. In terms of speed improvement, initial tests show about the same. Perhaps 1 or 2 fps better, but not much more.

Here are some other observations. When I run my app, it uses about 20% CPU utilization. When I spawn a second or third instance of the app, each instance also uses about 20% CPU utilization. Since java is multi platform compatible, I'm wondering how it will perform on Linux. Will it use the CPU to its full extent? Or will it perform exactly the same as in Windows 10? Do any of you guys have experience with this regard?

 

[R-T-B]

Well... I decided to port My applet to a Java App. I took the 1% inspiration, 99% perspiration approach. After a significant amount of research, I was able to do it. No mangling of the code, just well thought out adjustments. So now, I can run the app from the command-line, whereas before, I was bound to the IDE. Cool stuff. In terms of speed improvement, initial tests show about the same. Perhaps 1 or 2 fps better, but not much more.

Here are some other observations. When I run my app, it uses about 20% CPU utilization. When I spawn a second or third instance of the app, each instance also uses about 20% CPU utilization. Since java is multi platform compatible, I'm wondering how it will perform on Linux. Will it use the CPU to its full extent? Or will it perform exactly the same as in Windows 10? Do any of you guys have experience with this regard?

No OS is going to change your single-threaded workload limit.

 

[Aquinus]

Do any of you guys have experience with this regard?

I'm a software engineer that has written multi-threaded code in production systems. I can tell you right now that nothing will use more of your CPU unless you modify it to take advantage of multiple cores and this isn't a task for the inexperienced if you want to do it right because doing it wrong can harm performance. AS @R-T-B said:

No OS is going to change your single-threaded workload limit.

...and that it's on you as the dev to implement these changes if the time is worth the potential improvement. There are also trade-offs to altering a program to be multi-threaded. Usually the best way to achieve this is to decouple the "what" from the "when" by putting queues between each stage of your computation. That allows you to essentially parallize serial workloads. The problem here though is that while bandwidth will increase, latency will increase as well due to conveying values from one part of the application running on one thread to another part running on another. The other way is to take the most parallel part of your application and merely have more threads work on it which is basically the first suggestion plus some extra work to allow a single stage to have more than one worker.

All of these things incur overhead and require dev from a skilled dev with good understanding of computer science concepts to analyze if the cost of implementation is worth the speed up or if it would even result in any speed up at all. If you haven't profiled your application first, then you might want to start there. That would at least indentify which parts of your application are going slow relative to the rest of the application and multi-threading means nothing until you've done that. The world is a very different place when you start having to consider shared memory and multiple concurrent processes which is part of the reason why I use Clojure for most of my day-to-day dev needs that don't need to run somewhere where Clojure (the JVM; Java,) is available. Immutable data is a beautiful thing when it comes to concurrency.

tl;dr: Profile your app first before even considering multi-threading and multi-threading isn't for the faint of heart.

 

[grecinos]

Thanks for the input Aquinus. I think I'm going to leave my app the way it is. If I implemented multi-threading, I might get a marginal improvement. I don't think it's worth the effort. From what I can tell, debugging an app of this sort would be a good recipe for a migraine .

 

[Steevo]

Short answer? No.

Long answer, not without modifying application code for a multithreaded and slower in some scenarios approach.

If performance is really the issue, send if it can be written in something other than Java, as it's dying.

Or get a faster single threaded CPU or overclock.

 

[grecinos]

I had to resurrect this thread because I have taken upon myself to learn multi-threading in Java. I created a double buffered animating app that uses a thread for drawing the images to a JFrame while another thread performs the logic (update calculations). To make a long story short, I was able to increase the CPU usage from 18% to over 33%. This a substantial improvement. Something worth mentioning. The app was designed with Array Lists of objects. The Logic thread updates the objects while the primary thread draws them. The inherent problem with this is that it generates Concurrent Execution errors. So, I had to write clever coding to avoid this. The best solution I was able to devise, was to make clones of the array lists before drawing them. This way the primary thread has a copy of the data that won't be modified until the drawing phase has completed. In the meantime, the logic thread calculates the next iteration. It's not the most efficient technique, but it is certainly effective. The other obstacle was to learn how to terminate the thread. Without properly terminating the threads, your PC can lockup. Essentially I made use of the "interrupt" and "join" methods inherited from the Thread class. I'm not 100% sure why this works, but I did create a destructor to confirm its functionality.

So, in short, multi-threading, without a doubt can improve the performance of your Java App. But you need to do the research as there are many pitfalls. If anyone has questions or comments, feel free to respond.

Cheers,

grecinos

 

[eidairaman1]

You could always peruse oracle or whoever owns java and their forums. @FordGT90Concept, know anything about OOP?

 

[FordGT90Concept]

This is still better done on GPU via HTML5:
https://www.html5canvastutorials.com/advanced/html5-canvas-animation-stage/

In Java, you should be creating a OpenGL render context and do your drawing in there (via GPU). CPU should spend its time figuring out what to draw, not actually draw it.


If you're not looking for that major of a change, you could consider changing your array lists to arrays. Array lists have a huge performance penalty when they have to expand their internal arrays.

 

[OneMoar]

expecting efficient cpu usage from java is sorta like expecting a 300lb man not to use the handicap electric carts at the store
its possible but extremely unlikely and generally a inconvenience for all