- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
PS3 only has 512...
Admin
Yes, and a Commodore 64 has 64KB of RAM. Context... It's a useful social skill to learn.
Admin
x86 is not reduced-instruction. there are elements of the architecture which mimic risc, such as micro-operations which break some instructions down to their very-low-level cousins. however, a load command which requires arithmetic has specific logic hardware so that it does not require an arithmetic operation thereby blocking the MMU (i.e. memory addressing). x86 is a bit complicated like that. so no, it's not "true" RISC.
The further you complicate pipelining, the more expensive the hardware design & implementation can get. Your sarcasm is noted, though, because generally x86 can keep up with any other risc implementation. (generally)
Admin
Check the options you're passing to the JVM. It's entirely possible that you're saying "use 128MB for the heap as the maximum", and your apps end up getting memory starved. For that matter, check how much memory you have free, how much your java apps are using, and which version of Java is actually being used to launch them (it's possible you're calling against 1.4 by accident). Eclipse stores its parameters in eclipse.ini; take a look there, and see what's going on. Disable antivirus software; it may be aggressively interfering with what you're doing, though I haven't really had that happen with me.
Frankly, I've never had this type of issue, so I haven't got the best ideas on how to troubleshoot it, but I'd suggest popping into #java (and/or #eclipse) on irc.freenode.net and seeing if they can suggest anything, or posting on the sun forums and asking for information there. I'd definately create and run some "Hello World" complexity app, and run it on a different machine (preferably one with no connection to your work, so it would be set up different) and compare relative speeds with that, just to see just how bad things actually are.
Admin
Thank you for the offensive reply !
Well, I was trying to point that not all developer target their application for 1 gig of RAM...
Kind-hearted... It's a useful social skill to learn !
Admin
And it would be nice if developers for the PC would remember that just because we have 2 GB of RAM in there, doesn't mean we want one single app to consume it all just because the programmer was lazy and/or stupid :)
Admin
Ever heard of System.gc()? That should do the trick. And even if I prefer VS2005 or IntelliJ I need Eclipse and I'm running it on a Centino 1.7GHz CPU with 2gig ram and its performance is great.
Admin
Why would development (team of 100?) or QA (team of 10?) require the full kit? Especially if the app was informational and not financial transactions per the description.
Admin
Frankly I have to agree.
I work mostly with .NET tech but I've been playing around with Java lately using Eclipse. ... It's a dog. The VS ide is vastly superior.
IMO it's like programming with my fingers in a pool of molasses.
Admin
Why people still think that java is slow? That is so 90s
http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/03/26/java-speed_1.html
And I don't know why people say that eclipse is so slow, I find it even faster than VS 2005. And the guy who keeps saying that it crashed should check his eclipse.ini and change the maximum memory that eclipse uses that may be his problem. Although unless you are using many extensions like JBoss Tools you should not have that problem.
BTW, another successful Java application is Azureus.
Admin
Bah... as someone who works for a hardware vendor if I was told to size a solution for a certain number of users, probably a lot by the look of it, then I would have done the same thing. If I was told to size for 100 users, then it would have been a PC sitting on someones desk. You can't blame the vendor for a lack of analysis on the customers part, the vendor can only work with the information they're given. And personally I don't have a problem with taking advantage of stupid people.
Admin
The problem with slowness of Java applications is something that's not about benchmarks, it's about experience. When you forget the loading speeds and talk about basic operations like scrolling, opening windows, switching tabs in IDEs written in Java, there is some kind of annoying, almost mocking delay, too little to measure but too large to provide enjoyable experience. You can't expect well optimized natively-compiled system run slower than one depending on some cross-platform framework/pseudo-compiler. It's against the laws of physics. About the same speed is the max you can hope for.
Admin
Hmmmmm.
You know. I'd make it a point to visit a steakhouse that did that!
Now that would be pretty bloody cool.
Admin
Absurdly large Sun hardware installations go hand-in-hand with big consulting jobs. My (rather large) consulting firm is developing the new billing system for a major telco. The infrastructure team have given up describing the hardware in terms of CPUs and disks, and now measure it by weight... I think we're up to about 3.6 tonnes of Sun equipment now.
Admin
Yeah, and the smart companies were picking up "retired" Sun servers for about 5c in the $ after the dot boom. Put a lot of Sun sales rep out of commissions for a coupla years.
Admin
Hey, you have to forgive them for their lack of experience with fast computing. Some of us like to use assembler (still working to have a good line editor written, Real Soon Now). Now, for REAL speed: try solder.
Admin
Just out of curiosity (I don't do Java) what exactly does java.lang.System.gc() do? The doc doesn't read as if it only schedules a gc for later.
Admin
On the article: going with e10k may have been a wise choice. Providing that they were using the same hardware inhouse (as pointed out by an other user, makes sense for a bank to have e10ks), maintenance costs by their existing team with hardware that were familiar with may have been cheaper in the long run than hiring a new team to maintain new hardware. Typically, hardware is far cheaper than the people that operate it.
On Java: lol. I've used java for years, on desktop and mobile. On windows and linux. It is slow. That's it, end of discussion. Compared to native, you can't compare, obviously. With native, you double click/execute, your code just runs. It executes right away. Bingo! With Java? JVM loads, classes are loaded (JAVA in it's brilliant design, has classes littered over the file system if not bundled in jar files, C# grately improved on this by forcing things to compile not to individual classes but into libraries (dlls) speeding load time considerably). The IO is by far the slowest operation your CPU does because it has to wait, a CPU waiting is a CPU not executing code from your app (multithreading is not helping loading java classes as it's IO bound). Once all this is done, your code executes. This is fairly fast obviously, as benchmarks show, Sun did a decent job over the years to optimize the JVM. The initial cost of starting the JVM and launching the app is why java is so slow in small apps. This is also why it is largely slower on mobile that run from flash and have flash memory. Java also tends to use memory a lot (eclipse, netbeans, etc.) and with more memory used, the more your system is going to page, windows also likes to page applications that you minimize to the task bar. Again, more IO which slows things more. This is something all applications suffer with but the more memory they use, the more apparent it will be (I see this with firefox everyday, sigh). Also, on mobile, I suspect the jvm (and it's knock offs) do not have the heavy optimization the desktop JVM has, again adding to the java is slow thing.
On eclipse: Eclipse is slow, largely for the reasons stated above. Also something very popular in Java (and C#, sigh), is the whole encapsulation and "proper design" in OO. OO by it's design, is slow, lots more methods means lots more method calling and setting up the stack, registers is slow. It is obviously slower in a VM. This is seen not just in eclipse but in java everywhere (and C#/others). This philosophy is not as prevalent in c/c++ where "ugly code is good code". (I work in video games, I see my fare share of ugly, fast C++ code, thanks) The java community seems based on a best-of-breed approach where many frameworks do the same thing and in the end, one or two strongest survive and get to be used by everyone (hibernate, swing, struts, etc.) and magical enterprisey xml is in between everything to make it hold (a-la magical ducttape) and xml parsing is IO bound and slow.
Eclipse mind you, does a number of things very well and I generally like it. Searching in large source code bases for methods/etc, it is very quick (much quicker than searching in VS in large C++ projects). I am also quite happy that they are in the process of starting a new version with a "fresh" code base free of all the slowness.
I've also seen eclipse being unusable on some flavors of linux on high end desktops (1g ram, etc) because of the gtk native backend. Then again, if you run linux, i'm not sure why you'd want to use eclipse but oh well.
Also, a number of tools from IBM run on top of eclipse. While I was working for IBM, we had this tool RAD (Rational application dev-something) which is like an enhanced version of eclipse built on top of it. Lots more plugins, lots of xml enterprisey stuff, lots of slowness. I remember mine on a 3.4ghz 2gb ram desktop taking over 5mins to LAUNCH. Not funny, I clocked it one morning while I went to grab a coffee. It'd use so much RAM that coming in in the morning, I'd find it almost entirely paged to disk if I left it running and just bringing the window back to a usable state of responsiveness would take even more time. Once loaded though, it was quite usable, again, thanks to heavy optimizations in the JVM and in the code (at the cost of memory...).
On C#: Yeah, C# is as slow as Java. Main differance being that with C#, a service is launched on first app execution that is reused with other instances making their startup time much quicker (Java has/or is doing this, not sure but I know JEdit does something similar at least). Execution wise, C# may be slightly faster by the way the language implements generic at the VM level but I also believe it uses a bit more memory at runtime.
On mobile apps: Java makes a decent choice, (as pointed before by some other users) mainly because of portability with little code modifications to run on many devices, NOT because of speed of execution. A lot of the JVM optimizations (compiling methods to native code, etc.) are memory intensive, something usually scarce on mobile devices so launch time and execution time is considerably slower (processor speed aside). C# would suffer the same fate on mobile if it ran (does it? no idea but I'm sure that if it does, it's not any faster)
On software design: Most people are teached in school/work to make easily maintainable designs. This is OO/AOP design I'm talking about. By their very nature, they are not designed to execute fast, they are designed to be easily maintained and readable. OO slows down code if taken to extremes considerably with method invocation overhead and AOP is even slower (adds considerable overhead if not used properly or for wrong purposes).
There is an other kind of design not often teached: design for speed. This is what most games on consoles/PC HAVE to use to maintain FPS. Data structure alignment matters more than you'd think and often, aligning data means that instead of storing 1000000 vectors of x,y,z you'll instead store 3 arrays of 1000000 values (x,y,z) just because cache hitting will be better thus reducing memory hits, prefetching, etc. This code will not be easily maintainable by other people or in the future, this is why working on a game with legacy code is a nightmare (those who are/have, I bow to your courage/patience).
The former type of design was pushed heavily by Java proponents (and C#) especially because it matters a lot more in the corporate world where it doesn't matter if your CRM app is slow as hell when it has billion lines of codes you need to maintain everyday forever. (This is quite true, working at IBM we had to build a system interacting with a client's RPG system because they just couldn't get rid of it, it became too critical so we were building Java on top and extending in Java. You just know that in 20 years, some other language will have to interface with the java system that interfaces with the RPG system and you just know they will still have RPG/java developpers on staff. This is why COBOL will sadly never die and why you'll eb able to make a living with it forever)
On the GC: You can't force the Java GC to run, and i'm pretty sure the same applies to C#. Where System.GC or it's equivalent is just a suggestion. As pointed out, the Java/C# GC implementation is very good at what it does and speed wise, generational garbage collecting is as good as it gets without using too much memory. The GC is not why the language is slow overall but CAN contribute to perceived slowness where you click on something, GC fires, you wait, GC terminates and your thing pops up, yeah, it can(and will) happen. It's no LISP GC but it does the job. You just don't appreciate enough memory being managed for you until you are forced to put a hardware breakpoint to see who writes and trashes your memory address in some C++ app, it's just not fun...
These are the reasons why java is slower (in appearance and reality) depending on use/software/environment. Just stop bashing it, it's perfect (with C#) for it's intended use and it definately performs as designed (it was designed for portability, not speed and they did achieve their goal).
Sorry for the lenghty post, i'm just tired of seeing people complain/argue against java without knowing wtf they are talking about. Please go on discussing the article, it isn't about java :)
Admin
yeah i agree with some of this
Admin
So true ! And what is really sad is that even today, if you asked "how would you design the technical infrastructure of a company to compete with Google", most people would say they would buy expensive hardware, expensive support contract, etc because they think the only way to win is to be "on the technical bleeding edge".
Most people will never understand that software is the key to pretty much everything: reliability, availability, speed, price, etc.
Admin
Sheesh. Java is slow. End of story.
That fact doesn't make any of you guys bad developers, which is the tenor of the reactions I'm reading.
Admin
honestly, I wouldnt use eclipse as an example of a fast program, since pretty much every other IDE I've used is blazingly fast in comparison. ;)
Admin
I've played games written in java that ran comparably to native games. If you feel like it, check out the jMonkey engine. ;) Eclipse is just a monster of bad design.
Admin
Admin
Urgh. I work at a place with a system (yep) with a fwe hundred thousand lines of coe (once class is a ctually 27k lines on its own, with several methods clocking on on several thousand lines). It is split up in different components (which are really different programs altogether) chatting with eachother with an underlying layer. Its all in C++. And, while working on regression tests, I started getting pointer errors causing core dumps on some of the components. Yeayy!! Is the pointer deleted somewhere and then read? Is is being written over by something that it shouldnt and IF so, which one of the 30 or so components running? And where in the component?
Fun times. ;) I take working in game code over that pretty much any day. At least you can usually sift through the code of a game and understand most of the high level workings in a few days. ;) (the ugly hacks might take a bit of time each though heh) and yeah. Im very familiar with game engines and ugly hacks therein.
Admin
True
Admin
Ho ho ho! Well done sir.
Admin
What kind of a fool would spend that much?
Jesus.
Admin
Admin
As for the Java slowness:
Well, maybe you don't see big difference in response when using Eclipse, but it surely is using more resources - try running it on notebook on battery (underclocked processor - slower response && more CPU usage - less battery lifetime).
Also, try running something from IBM built on Eclipse platform - like Data Modeller and so... Slow, slow, crash, slow, slow, crash, crash... Even the Installation Manager for the application is SLOW.
And I've got no 486, its Core Duo 1.83 GHz, 2 GB RAM and fast disk drive. Not today high-end for running games like Crysis, but it should be enough for drawing boxes (that IBM software) or text editor with code features. Also Visual Studio 2008 runs jet-speed (except the MSDN Library :) ) on this hardware.
On the other hand - Opera Mini written in J2ME runs good even on very old mobile phone.
Captcha: eros :P
Admin
Hmmm... Bloody and cool. Nope - that's rare, and the e10K runs too hot to do anything under well done.
Admin
Umm, don't put all your eggs in one basket?
Admin
I have a core 2 duo with 1Gig and both my Netbeans 6 and Eclipse run faster than VS2008 and SQL Server 2005... Did I just say my java is faster than .net...
Admin
Actually, set-top boxes in the US have been rolling out with Java for about a year now, and according to my bosses ( I do set-top development) the industry is going for more in the future.
Admin
Is TRWTF that the submitter's contracting company did not demand in the contract that a compensatory payment be made if the client unilaterally decided to scrap the project, or is it that the company received a payment but didn't pass any of it along to the now-unemployed contractors?
Admin
[quote user="hallo.amt"][quote user="eryn"] the GC doesn't do anything while it detects user activity in Java... you can't even force it to collect, unlike in the .NET framework where you can. That's a reason why some apps have such big memory footprints, they wait for a lull in activity before they cleanup.
I've seen/worked with/written/laughed at some hideously slow .NET applications, you don't see me blaming the Framework.
...perhaps it has some quintiple nested loop operations with hundreds of String concatentation operations.[/quote]
Ever heard of System.gc()? That should do the trick./quote] The API doc of System.gc() is misleading. The general agreement among people who know the internals of recent JREs is that it's merely a suggestion to the JRE that now would be a good time to do GC work, and the JRE may or may not follow that suggestion.
Admin
Admin
I'm a Java programmer you insensitive clod!
Admin
Admin
It sounds Irish.
Admin
Unless you've put some thought into the architecture, then, no, you're right. This is an absurd purchasing decision. Based on my own experience, I would suggest that bringing Sun and IBM on board at the beginning of the process, rather than at the point where you choose your hardware configuration, is ahem TRWTF.
Admin
Your definition of "Native" compilation is interesting. It involves tomahawks, war paint, and ululation, possibly? Here's a challenge: define me a task or an algorithm, and specify any platform you want. I'm pretty certain that I could write a C++ program that would out-perform your Java program by at least a factor of two (speed) over ten thousand cycles or so, and it would most certainly have a smaller memory footprint (not to mention caches or anything).
Both of them suck at threading, though.
Admin
It depends on the software configuration.
If you are running J2EE with EJB, about 20 users.
Apache and mod_perl, maybe 50,000.
So we recommend J2EE with EJB, says the saleman in the Armani suit.
Admin
C'mon. I sometimes use Eclipse on a notebook with 1 GB and 1.7 GHz (and using speed scaling when running on battery) and it works like a charm. Check your setup.
Wait... perhaps it's because I'm using Linux as the underlying OS? ;o)
You see, Linux is also often deemed "crappy" by Windows users, who - if you look/ask more closely - never even have seen a decent Linux implememtation, let alone having tried or used one.
And the very same holds true for most of the "Java-is-so-slow" moaners ;o)
Admin
I just finished loading a 2 TB database on a Sun product on a 4 day consulting gig. The sweetest part of the gig was the Sun Hardware (which is quite real). I had to restart the load due to Oracle bugs, but it didn't really matter ("I'll start the load of the 5 billion row table before we leave tonight. It should be done when we get in tomorrow.")
How come I can't get a Sun box to run my databases on?
Admin
And let's face it: the server is exactly where you often do NOT need to optimize performance to the last cycle, because for a custom app (which a large percentage of server apps are) throwing more hardware at it is usually a cheaper option than having a developer micro-optimize your code.
Whereas C++ is accessible to the cowboy coders who exclaim "you'll take my manual memory management from my cold, dead fingers", just as they implement another buffer overrun?Let's leave the FUD out of this.
Har de har har.What percentage of applications do you think are run on a CPU for which they were specifically compiled, using all possible optimizations? I have no idea, but I'd bet good money that it's fewer than 0.01%.
I assumed that by "natively compiled", Azeroth really meant "compiled directly to machine code", and I did not claim that Java code is always faster than that, just that it is in fact possible.
How about these: http://www.osnews.com/story/5602Or these: http://pages.cs.wisc.edu/~plakal/javatraces/benchmarks.html
I just tried the Quicksort.
C++ version compiled with Borland C++ 5.5: bash-3.00$ QSort 10000000 startup time: 0.578 sort time: 2.297
Java version run on JDK 1.6.0_04: bash-3.00$ java -server QSort 10000000 startup time: 0.219 sort time: 1.86
I'm curious.
Admin
And, the biggest one, if you're using bash, why not use the time command to get the program times? Why let the program report the time?
My guess is because Java's true startup time and library load time would bloat the faked test time to make it lose to a C++ program.
Plus you have to do some form of cheating to be able to skip the penalty of JIT compilation. Otherwise there's no way interpreted code would be as fast as native code.
Admin
Urgh indeed... but here obviously many (if not all) principles of OO design have been violated.
No class has 27k lines (and certainly no method several 1000 lines, at that!) if an OO system and its components are modelled correctly from the beginning.
I'd not be surprised if this was some "multi-purpose-does-all" class which in fact should be split up into multiple classes or even modules...
Admin
I'm surprised no-one here has mentioned IntelliJ yet (or if they did I scrolled past it). It's the only Java IDE that I'm willing to use, for performance and usability reasons, and because it has some very powerful refactoring and code analysis abilities. IntelliJ is written in Java (using Swing for the UI, no less!) and it looks and feels almost like a native app, whether you're running on Windows, OS X, or Linux. There's a small amount of native code to do things like watch the filesystem for any changes you made outside the IDE. It even has a part of the status bar showing exactly how much Java heap you are using, with a trashcan icon to force a GC if you feel so inclined. Generally you don't need more than the default max Java heap which they set at 192MB, but it's easy to bump this up if you need/desire.
IntelliJ does cost $$$, but it's worth every penny IMHO (even more so if you can get your company to pay for it!). I highly recommend downloading the 30-day trial if you are sick of your current IDE. At any rate, it's a perfect counterexample to show that Java apps on the desktop are not inherently slow. Azureus is another example that's already been mentioned, and also Frostwire.
As for phones, my company designed the software for a popular Java-based smartphone, and without getting into anything proprietary, I can say that Java is generally a good thing for anything that's not performance critical, primarily because bugs in the code will 99% of the time turn into exceptions that you can catch in log output during development, rather than memory corruption and crashes. You still have to deal with race conditions and other multithreaded complexity, but Java is easier to work with than C/C++ here as well. In a previous life I wrote some apps for Nokia Series 60 (very weird flavor of C++ with proprietary classes for exception handling) and I much prefer Java.
You do have to pay Sun for the right to use the Java logo, and to license the TCK's (unit tests) to verify that you are compatible with the API's and JSR's that you have implemented, even if you didn't license any Sun code for your implementation. So there is a bit of a "Sun tax" but it's no different from paying for the right to use the Bluetooth or Wi-Fi logos, for example.
Admin
You are aware, however, that for large server side systems the use of a strongly typed (and perhaps OO) language is the only viable option? You can not give up "proper design" for speed in that case, otherwise all you will produce is a maintenance nightmare.
Also, large distributed systems are not dependent on "raw CPU speed", the overall performance depends on many factors, and they have to scale well, which they often won't if they are "optimized" by low-level tricks for a certain platform and/or CPU architecture.
And this "ugly and fast" is good? And this is bad how? I beg your pardon? Apart from XML based communication protocols (SOAP et al.) all the "magical enterprisey xml" in these frameworks is used for configuration and thus only parsed once at start-up, which renders the XML parsing speed irrelevant. The start-up phase of a complex service is always bound to be slower than the execution phase, no matter which language it is written in, and services are not restarted frequently (at least if they are run on a decent OS (!) and are written and configured correctly!) What? I'm running Eclipse on a relatively old Notebook (1GB, 1.7 GHz, Linux OS) and it runs smoothly. (1 GB is not high end nowadays, BTW...) The other services like appserver, database etc. are running on the same machine simultanously while developing without problems. Out of curiosity I tried this on the same hardware with XP, but this was no good idea ;o) I beg your pardon? I'm not sure what you are trying to say here... This might also have been due to the OS used (its caching/paging strategies, memory management, task scheduling etc.) and of course on the RAD tool itself - only because it was made by IBM does not mean that it must have been written well. I wished that was only remotely true... if it was, we wouldn't see this plethora of crappy and unmaintainable lumps of software that plagues most businesses. The first (speed) is simply not true and the latter (maintainance) is a good thing too. Only that it is unfortunately not done properly very often... Each programming technique can be slow when not used properly or for the wrong purpose. You can *not* blame this on paradigms like OO or AOP. I have seen games implemented in Java which had the same FPS as native ones. And I've seen many "optimizations" backfire in unexpected and desastrous ways... At least you are acknowledging the problems here for the first time. Good. I'm sorry, but the one thing does not have to do with the other in the slightest. You can have well-written, easily maintainable apps which are still fast and you can have maintainance nightmares which are CPU and memory hogs (unfortunately the latter is much more prevalent...) It mostly only depends on the skills of the development teams. And that's a good thing too. The heuristics used to judge the necessity of a GC run are much better than nearly all developers' aptitude to handle this themselves. It is the same as "hand tweaking" programm code: quite often this will just backfire and make matters worse, because you have to know damn well what you are doing. The same is true for memory management: It is not to say that it's not *possible* to write explicit memory management code which is much more efficient than any GC - but only *very* few people are capable of this. I'd go with an implicit approach at any time for the average IT project - it is simply not possible to have enough "gurus" on the team to avoid all the common pitfalls. The prevalence of memory leaks in so many programs/systems bears witness to this fact. Now I'm nearly forgiving most of your statements above ;o) because this is quite a sensible way to see these languages - only that the generalization about performance is simply not true. Thus some of your statements had to be retorted, no offence meant :o)