I just read this (one) study in which Tomcat under Linux outperformed Windows.
From your experience, is this generally true? Any deep reason that could explain the performance difference?
I don't thing such benchmarks can be so informative, then this one is 4 years old.
By the way these differences usually reside in certain choices related to how the operating system manages memory, cache and threads..
I take any benchmark with a grain of salt. It's possible to game any comparison.
I find that one key is to try and spot any bias that the person doing the comparison might have. There was an infamous comparison of the Java EE Pet Store done with .NET several years back. The group doing the study had been paid by Microsoft. They didn't do all they could to optimize the Java EE solution, putting it in a bad light. The results were discredited as a result.
Does WebPerformance.com have any Linux bias?
If not, there are a lot of factors that enter into such a result. I'd compare all of them carefully, and try to see if I could spot anything important that might have been left out.
Few points (mostly speculation):
Tomcat developed by FOSS on FOSS software, so it is reasonable that it would perform better on FOSS software.
Linux is better operating system ;-)
Generally. It depends on fine tuning experience... If you know windows well you'll tune it better for windows and if you know Linux better then...
Related
I'm java developer and my goal is to understand which computer is best suited for some statistical evaluation. I have 3 different desktops with different os(Windows 7, MacOS, Ubuntu).
JVM based program seems best suited for this benchmark.
Is there some maven besed package which I can put to dependency and run on all these desktops to get HDD/CPU/Memory benchmark?
The question is about java libraries which provides CPU/IO/memory benchmarks...
Not in any meaningful way, AFAIK. The purpose you have proposed "some statistical evaluation" is too broad for meaningful benchmarking.
In fact, the only meaningful approach would be to:
Select the statistical application that you are going to use.
Select a bunch of representative problems; i.e. problems that are typically of what you are going to be doing ... in both quality and "size".
Code the solutions using your selected application.
Run the solutions, and measure the times taken.
Tune the solutions / application and repeat the previous step until you are satisfied that you are getting the best performance out of the application.
Run the application on the candidate machines.
Compare the times, across all of your problems on all machines.
I would posit that unless you are trying to run really large analyses on an underpowered machine, it is not going to make much difference which OS you use. The critical issues are likely to be using a fast enough machine with enough memory (if the analysis requires lots of memory), picking the right application, coding the solutions correctly, and tuning the application. The choice of OS probably won't matter ... unless you push the memory envelope too hard.
I will disagree. If what you are saying is correct there were no such think as SUperPI, 3DMark etc. Only problem with that stuff it is OS specific so I can compare 2 windows laptops only. Performance can be easly measured with elemntal operations such as write/read disk/memmory. Arithmetical operations. Thats is actaully universe of possible computer operations.
Well fine.
If you think you can find a meaningful benchmark that compares application-level performance across different OSes ... go find one.
And if you think such a benchmark is going to give you numbers that are applicable to running Java statistical analysis tools, feel free to use it. (Hint: the OS-specific benchmarks like SUperPI, 3DMark, etc are not great predictors of performance running applications.)
And if you think that Java application performance is only about how fast disk read/write, memory read/write and basic arithmetic instructions ... feel free to continue believing that.
Unfortunately, reality is very different.
But my guess is that doesn't make a lot of difference what OS you choose, provided that the hardware is up to it.
I was wondering if anyone have gotten Java up and running on a BeagleBoard or Cubox? I'm thinking about buying one for a project I'm working on on my spare time, but as parts of this project is written in Java I first wanted to know if these tiny computers can run a JVM at all?
From what I read on http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html there are editions for ARM, and Solid-Run (the manufacturer behind Cubox) have also written some info on their wiki: http://www.solid-run.com/mw/index.php/Oracle_Java_on_CuBox.
However, what I would need to know is:
Can I consider ARM JVM == x86/x64 JVM in terms of functionality (a.k.a. "will my code run without changes") (my code is pretty non-graphical, mainly a HTTP API)?
Are there any license "problems" with JVM on ARM (compared to JVM on x86/x64)? That is, if I suddenly want to mass-produce my little spare-time hobby project and sell Cuboxes, will Oracle sue me?
Anyone have any experience with Hibernate/HSQLDB on ARM?
Perhaps too many questions in one, but I think they're all related enough to be put in the same thread. In general, I want to know more about JVM on ARM and how developed and mature it is.
Thanks!
Answers to 1 and 2 are on the Oracle page. "development is free, but royalties are required upon deployment on anything other than general purpose systems. In all cases, these products are fully Java SE compliant"
As for 3, I don't know about Hibernate (which shouldn't be a problem), but HSQLDB has been used on ARM by Symbian and others at least since 5 years ago.
I've been designing a card game in Java on Windows. It runs really well on my laptop and a few others, but on a lot of other systems (even a few newer ones both Mac and Windows) the animation is incredibly slow.
I've found User Interface Toolkits for Java to be the best resource so far, but haven't been able to make a significant improvement. I'm using the AWT/Swing libraries.
Question:
Looking at my game, (<1.5Mb), how could it be that on some computers (of similar spec) the performance seems to be significantly less that what it is on my laptop? The entire app is event-driven and I've done most of the optimization that I reckon could be done given the implementation.
I have a feeling it is memory-related. I create (compatible) and then store all my images into an array at the start, and then reference them there.
Note: I decided to make this game so that I can learn and practice some new ideas, so I'm not just trying to share it - I'm really interested to find out what's going on here.
On not all operating systems, the Java 2D rendering pipeline supports hardware acceleration by the GPU. It depends on the Java implementation that you're using.
One of the new features for Oracle's Java SE 7 implementation (which is coming out at the end of the month) is this: XRender pipeline for Java 2D which means that it will have much better performing 2D graphics on Linux.
For Windows, in Java SE 6 update 10 there were some improvements to make Java 2D perform better by using Direct3D hardware acceleration (source).
For the Mac, you should try the system propeties and rendering hints described in this document, particularly the one that tells Java to use the native Quartz renderer rather than the Sun renderer.
..why could it be that on some computers the performance seems to be at least half of what it is on my laptop?
Video drivers. I was involved in a thread on usenet a long while ago, where there was a phenomenal difference in rendering speed on machines with similar spec. Ultimately it was concluded that some machines were using outdated video drivers, and that was the root cause of the difference.
If that turns out to be the case here, your best bet is probably to do a rendering test. Check the FPS, and if it is too low, advise the user to update the drivers.
Try popping it in a profiler and see what comes up. I'd do it on both windows and mac and compare where exactly you're getting the problem. JProfiler is my favorite, but YourKit is good as well. You can get a trial version for 30 days which should be plenty of time to figure this out.
It's probably graphics hardware related, hardware acceleration vs software, since there is such a difference between Mac and Windows noted on this thread.
I want to know how Java (JSP) on Tomcat compares to PHP on Apache in terms of performance.
Two servers with the same hardware configurations, one running Tomcat/Java (JSP) the other Apache/PHP, both servers maxed out with how many connections they can handle at once. Would they be somewhat close or would one pull away from the other one by a large margin? I basically just want to know if Tomcat/Java (JSP) is going to be a big performance hit if I switch to it vs PHP. If anyone can give a detailed answer on why one is faster than the other that would be amazing. Links are great too, I was unable to find anything online surprisingly.
Please no Java vs PHP wars, this is about performance only, nothing to do with the languages themselves.
Note: If there is any other concerns I should have for switching to Java from PHP please let me know. I REALLY hate asking this question because I'm usually the first person to say "program in what you like" but in my situation I need whats also good for the projects I work for. I know that there are large sites written in JSP, but it doesn't mean that they're better.
Thanks
What's good for the projects you're working on is to spend as little time as possible to write them as developer time is way more expensive than any perceived differences in performance. So stick with what you're familiar with.
The answer to your question is: they are both fast enough.
Any such comparison is hard because you end up doing things differently in different languages. Java bytecode is probably faster to interpret but then again any decent PHP install uses as opcode cache largely negating any such advantage in real terms.
Java also has a more complicated development model because Web processes are persistent. This can have a performance advantage but also can create problems like memory and other resource leakage, which PHP doesn't tend to have because everything is created and destroyed on each request (barring session information, memcache and so on).
Also PHP extensions can be created for any parts that you want to speed up.
$10,000 can buy an awful lot of hardware. It can buy the hardware to run SO. It doesn't buy much developer time.
I've got experience doing both Java and PHP development. I will generally choose PHP for Web development because of:
quicker to test changes in development (ie no build/deploy steps and Java hot-deploy has serious limitations). Words cannot express how freeing it is to test changes by saving the file you're working on and clicking reload on a browser vs running an Ant/Maven build process;
far fewer issues of memory/resource leakage;
extensive library of functions to do pretty much anything you want;
cheaper to host (at the low end).
I will use Java for some things, like anything that involves a lot of background processing and threading, which aren't PHP's strong points.
You'll note that performance (or the lack thereof) doesn't even rate as a reason for or again.
Sorry if that doesn't answer your question, but such concerns over performance are a pointless distraction.
The best way to answer performance questions is with a benchmark. Implement some simple page in both PHP and Java and then benchmark them using ab (Apache Benchmark).
Having said that, I suspect Java will outperform PHP because of the nature of the 2 platforms. Java is compiled to optimized bytecode (once) and then interpreted by a virtual machine. When Tomcat runs, the JVM loads the classes required for any given page and keeps them in memory so they're ready to go when an HTTP request hits the web server. Contrast that with PHP which reloads and re-interprets the code from scratch with each invocation by Apache. This is helped to a large degree by op-code caching, but still not to the level of what happens in the JVM.
I have a request for a contracting gig and one of the requirements in the first draft of the specs says the software (a GUI application for end-users) should run on Win 2000 and Mac OS 7.5. I have no idea why they would want to support such ancient systems, but I guess it leaves me with Java as the only option other than raw C, or doesn't it?
So if it would be Java, are there restrictions on what Java version I can use on those targets?
Also, though it wouldn't be strictly on topic, I'd appreciate comments on strategies for making software run on both targets. Actually, supporing those ancient systems as well as modern ones might even be harder than supporting Mac and Win, right?
As another sideline, I'd also appreciate facts that could be used to talk the client out of this and make him go with OS X and XP. Like "hey, only 2% of all Macs in use today still use OS older than X".
Edit: My main purpose here is to be well prepared technically to negotiate what the specs really should be.
Things like that are often the result of some manager thinking "gee, my aunt still uses OS 9 and I bet, there's people even more old-fashioned, so let's just play it safe and write down 7.5". There's no technical judgement whatsoever involved, and that's OK. It's just that, in those cases, you have to explain carefully what tradeoffs there are and if you succeed, it usually gets you much more realistic specs. It's not even unlikely that they'd ditch Mac OS altogether if they have to bet money on it.
With that kind of specs, if you don't actively help the client reshape them, what's going to happen is, you put the number in the offer that would pay for all the crazy stuff and then yet some, and less experienced competitors won't see all the implications and put a lower number in their offer, get the gig and it all ends in tears for everybody. You can go "heh heh, told you so", but don't get the cash, either.
Edit: Thanks for still posting facts and advice although I already accepted an answer to my original question. I'll keep upvoting that stuff, and it certainly helps. Also thanks for empathizing with me and trying to save me from signing a bad contract! But don't worry, I'm not actually going to code for Mac OS 7.5 ... ;-) Really, really overseeing all the implications would be well out of my depth anyway.
Unless this is a seriously lucrative contract, or you desperately need the money, I'd recommend running away from it as fast as possible. The chances are the client is not only targeting seriously old OS's, but also old hardware. That'll mean you'll have all sorts of problems with performance (for you can bet the entire value of the contract that they want an app with modern features and performance on this ancient kit). It's near guaranteed to end in tears...
The Java Runtime for MacOS 7.x was called Mac OS Runtime for Java (MRJ) and supported at least Java 1.1.8. If my memory servers me right, the Swing implementation was pretty bad - so you would need to use AWT.
At least on the ancient MacOS systems, you will have stability & performance problems. Don't take this contract, this is guaranteed to end in a fiasco.
Unless this is a seriously lucrative contract I would stay away from this one.
I've worked on contracts like this in the past and they are almost always more trouble than they're worth. Whilst I appreciate you are just trying to be prepared, you really need to find out more about why they want to do this - its pretty unusual.
OTOH. If the contract is a big one and they are only talking a couple machines - it might be worth your while to offer to buy and install machines for them!
Coding for an older VM such as 1.1 will force you to code to a lower common denominator and will add considerably to development and testing time - you need to take this into account. The machine will almost certainly be underpowered in terms of memory and cpu.
Win2k will support at least Java 1.4 and possibly 1.5.
It's up to 1.1.8 for all Mac OS Classic (not X)
One useful stat is that about 85-90% of all Macs run OS X 10.4 or 10.5. Most of the other 10% are running older versions of OS X.
I'm not definite on this, but I believe Mac OS 7.5 will only run versions 1 and 1.1 of Java.