java.util.concurrent.ScheduledExecutorService performance on different computers - java

I have 2 Java programs. Each has a memory region, and programs pass messages to each other's memory regions. Java program checks its memory region with ScheduledExecutorService at a certain period of time, i.e. 5 miliseconds. Then it does some conversion and prints the message to screen. Two programs run succesfully and they print messages to screen ( I have implemented all JNI related things and programs run succesfully). The problem is that when I start these programs on my computer (windows 8, 64 bits, 8gb ram, 2.67 Ghz i5 processor) they run really fast. However, when I run these exactly same programs with exactly same native c++ library where I handle shared memory related works, on a different computer they run slower. The more interesting is that I tried to run them on a both better computer with 32 gb ram, i7 processor and worse computer with 6 gb ram and 64 bits core duo cpu and still they run slower. So another computer with either better or worse features than my computer did not matter on the speed of programs. All I see they run slower on other computers.
Any help is appreciated. Thanks.

Related

Why is multithreaded Java Program not faster on 'super' Linux server vs laptop Win7?

Intro
So far, I have been working on a piece of software which I am now testing to see the benefit of concurrency. I am testing the same software using two different systems:
System 1: 2 x Intel(R) Xeon(R) CPU E5-2665 # 2.40GHz with a
total of 16 cores , 64GB of RAM running on
Scientific LINUX 6.1 and JAVA SE Runtime Enviroment (build
1.7.0_11-b21).
System 2 Lenovo Thinkpad T410 with Intel i5
processor # 2.67GHz with 4 cores, 4GB of ram running windows 7 64-bit
and JAVA SE Runtime Enviroment (build 1.7.0_11-b21).
Details: The program simulates patients with type 1 diabetes. It does some import (read from csv), some numerical computations(Dopri54 + newton) and some export (Write to csv).
I have exclusive rights to the server, so there should be no noise at all.
Results
These are my results:
Now as you can see system 1 is just as fast as system 2 despite it is a pretty powerfull machine. I have no idea why this is the case - and I am confident that the system is the same. The number of threads goes from 10-100.
Question:
Why would does the two runs have similar execution time despite system 1 being significantly more powerfull than system 2?
UPDATE!
Now, I just thought a bit about what you guys said about it being an I/O memory issue. So, I thought that if I could reduce the file size it would speed up the program, right? I managed to reduce the import file size with a factor of 5, however, no performance improvement at all. Do you guys still think it is the same problem?
As you write .csv files, it is possible that the bottleneck is not your camputation power, but the writing rate on your hard disk.
Almost certainly this means that either CPU time is not the bottleneck for this application, or that something about it is making it resistant to effective parallelization, or both.
For example if reading the data from disk is actually the limiting factor then faster disks are what matters, not faster processors.
If it's running out of memory then that will be a bigger bottlneck.
If it takes more time to spawn each thread than the actual processing inside the thread.
etc.
In this sort of optimization work metrics are king. You need real hard solid numbers for how long things are taking, and where in your program you are losing that time. Only then can you see where to focus your efforts and see if they are effective.

Running multiple instances of the same program slows down all of them

I have a single-threaded program that utilizes nearly 100% CPU when run alone. If I instantiate multiple instances of it on separate prompts, they all slow down considerably (about 8 fold). I am running jre version 1.7.0_25 on Ubuntu 12.04 with a Intel® Core™ i7-3930K CPU # 3.20GHz × 12 and 64 GB RAM. What could be causing the slow down? Surely, the programs can not be competing for the same CPU. And, I have always made sure that I run lesser instances than there are cores. I appreciate any insight.
Thanks,
Suresh
Each instance creates a separate JVM with a distinct initial heap (defined by -Xms JVM argument) and program resources. If you have too many instances, there is no surprise the OS will be swapping memory to disk and CPU's context will switch continuously between the java processes.

Why does my program run at drastically different speeds on different computers?

So I sent a friend a copy of my implementation of Conway's Game of Life. When he received it, he complained that my application [on the super-sampled grid size, with 0 delay] was barely getting 1 generation/second. I responded that on my computer, with approximately the same amount of filled grid spaces, I was getting around 38 generations/second. I couldn't attribute this disparity to different monitor sizes, as mine was more or less the same size, and the grids were therefore similarly sized. I ran my program from the jar as well, for consistency's sake.
Here's the kicker: His computer is running an AMD Phenom II X6 1090T processor # 3.2 Ghz (6-cores), with eight GB of RAM. My computer is running i7-4700MQ # 2.4 Ghz (quad-core), and 8 GB of RAM. He also has an Nvidia Ge-Force GT 440, vs. my intel integrated graphics.
It is beyond me how my computer can so profoundly outperform his, despite being inferior in every statistic. Does anyone know what could cause this? I am guessing it's something to do with the differences in processor architecture, but I'm no expert. Below is a link to the GitHub page for my project, in case you want to compile and test it yourself.
https://github.com/JoeAzar/CGOL-v1.3.2/tree/master
Does anyone know what could cause this? I am guessing it's something to do with the differences in processor architecture, but I'm no expert.
Well I'm only guessing too, but it could be things like:
Different operating systems
Different versions / releases of Java
32 bit versus 64 bit issues, at the JVM or OS level.
Different JVM parameters; e.g. those that affect heap size.
Differences in paging disk speed / latency (if the application is paging).
Other stuff running on the machine (e.g. resource hogging AV software)
It could also be processor architecture related ... as you postulated ... though I'd put that well down the list of possible reasons.

Running JAVA on Windows Intel vs Solaris Sparc (T1000)

Hi I'm trying to test my JAVA app on Solaris Sparc and I'm getting some weird behavior. I'm not looking for flame wars. I just curious to know what is is happening or what is wrong...
I'm running the same JAR on Intel and on the T1000 and while on the Windows machine I'm able to get 100% (Performance monitor) cpu utilisation on the Solaris machine I can only get 25% (prstat)
The application is a custom server app I wrote that uses netty as the network framework.
On the Windows machine I'm able to reach just above 200 requests/responses a second including full business logic and access to outside 3rd parties while on the Solaris machine I get about 150 requests/responses at only 25% CPU
One could only imagine how many more requests/responses I could get out of the Sparc if I can make it uses full power.
The servers are...
Windows 2003 SP2 x64bit, 8GB, 2.39Ghz Intel 4 core
Solaris 10.5 64bit, 8GB, 1Ghz 6 core
Both using jdk 1.6u21 respectively.
Any ideas?
The T1000 uses a multi-core CPU, which means that the CPU can run multiple threads simultaneously. If the CPU is at 100% utilization, it means that all cores are running at 100%. If your application uses less threads than the number of cores, then your application cannot use all the cores, and therefore cannot use 100% of the CPU.
Without any code, it's hard to help out. Some ideas:
Profile the Java app on both systems, and see where the difference is. You might be surprised. Because the T1 CPU lacks out-of-order execution, you might see performance lacking in strange areas.
As Erick Robertson says, try bumping up the number of threads to the number of virtual cores reported via prstat, NOT the number of regular cores. The T1000 uses UltraSparc T1 processors, which make heavy use of thread-level parallelism.
Also, note that you're using the latest-gen Intel processors and old Sun ones. I highly recommend reading Developing and Tuning Applications on UltraSPARC T1 Chip Multithreading Systems and Maximizing Application Performance on Chip Multithreading (CMT) Architectures, both by Sun.
This is quite an old question now, but we ran across similar issues.
An important fact to notice is that SUN T1000 is based on UltraSpac T1 processor which only have 1 single FPU for 8 cores.
So if you application does a lot or even some Float-Point calculation, then this might become an issue, as the FPU will become the bottleneck.

Why is my java application faster on an AMD processor?

I made the observation that my java application is running much faster when executed on an AMD processor in contrast to an Intel CPU.
For example my JBoss starts in about 30 seconds on a 3 GHz AMD processor and needs about 60 seconds on a 3 GHz Intel processor with identical disc, RAM and OS?
Has anyone else made this observation? Why is this so?
It depends on the CPU generation as well - clock speed is not everything.
If you set up e.g. an Intel Pentium 4 and an AMD Phenom with the same clock speed, you'll see a large difference in favour of the Phenom.
Update: If you're really curious, use a profiler and post the results.
Other considerations:
Size of processor on-board cache
Bus speed of your motherboard
Cache size of your hard drive
Hard drive RPM and read speed
Bottom line: Unless your configurations are identical besides the chips, and you are trying to asses the performance of a particular technology, you're really comparing apples to oranges.
Are they both running the same architecture? Or is the AMD running a 64-bit OS?
Remember that startup time isn't everything; a 60s startup time probably isn't that bad if the application runs as fast AFTER it's started up.
I've seen 64-bit JDK work much faster than 32-bit one on the same processor. So maybe that's the case.
EDIT: http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_performance. Sorry, I guess I'm wrong.

Categories