Java Processing Speed
Community Forums/General Help/Java Processing Speed
| ||
| I took the advice of some in a thread I started a while back and have been learning Java AND JavaScipt. I may be using those two for now on to create games or do whatever I do. I especially like Java. It’s perfect. I like how one can write applications as well as games, AND do web stuff. I haven’t been using Blitz for a while now (but it still is the best foundation and has been a great reference for things I've been trying to do). I found that I mostly enjoy making web games and making things for the web all together. But, I was wondering has there been any effort to make Java a faster and/or less clunky language. It does seem that Java can be kind of slow, heavy, and is it just me or does Java or its applications sometimes slow down the computer)? Could there ever be a Java 2.0 or something like that (as is C# is to C++) or so? Last edited 2012 |
| ||
| Could there ever be a Java 2.0 or something like that (as is C# is to C++) or so? Java's already on something like version 7! Yes, it gets updated all the time. That's the world of business computing for you. However, you're confusing several related concepts with that question: 1) C#, C++ and Java are different languages. While they share design influences, C# is not an upgrade to C++; it is something else. 2) Languages are not the same things as runtime systems. It's possible for any one of Java, C# and C++ to produce programs to run on any one of the JVM, CLR or bare-metal. There is no direct connection between the language and the platform in this case except for convention (indeed, people do write in all three for all three). 3) There are a whole bunch of runtime systems for Java (including IKVM, which runs on the CLR/.NET, just because). Being written by different people, they have different performance characteristics. The default one is probably the best, however. 4) The JVM is probably the fastest JITting platform available at the moment. Yes, a lot of effort by a lot of smart people at billion-dollar companies has gone into optimising it. It started life as a dinky little bytecode interpreter, and is now a superfast JIT engine that can often outperform C++ programs. 5) As a language, Java will probably not change very much. It is the clunky, boilerplate-heavy thing that it is by design, because that's what its users want. If you want to type less, you'll have to choose something else - and believe me, there is no shortage. Plenty of other languages offer compilers for the JVM, so you can still access the important part, which is the Java libraries. Remember that you've entered a world where not only are languages and platforms different, but languages and libraries are different too. As for Java's heavyweightedness... that's an unfortunate consequence of what you want it to do. That extremely capable runtime system needs a lot of memory to get off the ground. Its applications may also take a few minutes to get up to running speed, as its JITting system requires code to run for a bit so that the profiler can determine exactly which bits to optimise and speed up. You can't have the features of the Java platform without also having to put up with its weight. The best thing to do is to use it for everything; make your apps part of the ecosystem instead of little applets that just call into it occasionally. That way, if you're going to use it, at least you get your money's worth. Java, both platform and language, is a business product, intended for big heavy tasks. If you aren't going to use all of that power, or enough to justify the size of what you're using, it may well be worth looking into writing for something else. TL;DR: -- different languages are different things -- a language is not a platform, nor is it a library. A language is just something you write in -- you get what you pay for, in this case, paying memory for power Last edited 2012 |
| ||
| Basically everything Yasha said. C# is -very- similar to Java (in fact it started out as "Microsoft Java", chuck a bit of Delphi in and redesign the namespace structure and boom, C#). It is now an ISO standard language and not just an "MS" one. However Java & C# have very little in common with C/C++ (except perhaps a few syntax similarities to the untrained eye). IMO C# is more organized and cleaner than Java, but Java is by far the most powerful in terms of sheer range of what you can do with it. Speed wise they are probably similar (or a case of "my xyz is better than your xyz" (and vice versa), meaning better for some things worse for others) Last edited 2012 |
| ||
| There is no perfect language, only the right language for a given situation. A situation in this case being defined as a combination of developer experience/comfort level/skill set, intended project goal, project resources, user resources and requirements. That's a lot of BIG things to cram into a concept but in the real world the most important for the vast majority of situations is all down to the developer(s). If you don't know C and aren't even familiar with basic C syntax it's probablt a poor idea to try to build a supremely fast and resource light 3D engine in it... you're going to spend more time learning the language and everything around it than actually writing your code. For this reasons BMax is often a great choice for all kinds of things if you're familiar with it. It's just easy and often that's the most important thing, a game that's never done never ships and never makes any money or anyone happy. The opposite end of the spectrum is sometimes you'll just hit a wall, something a language wasn't designed for at *all* and while you can almost always shoehorn in some form of solution it isn't always worth it. e.g. want to develop for iOS? Java is just going to cause you problems since the platform only runs Objective C/C/C++ natively... you could try to hack something into an applet but I'm not sure mobile safari could handle it and you'll have all kinds of trouble with inputs. Similarly you should really focus on Java if you're developing for Android. While you can include C through the NDK you still have to wrap it with Java, and the NDK's debugger is... well I'm not sure it exists for a start... So trying to code in Objective C for Android is just as daft as Java for iOS. There's no magic bullet, just bullets that are better for certain situations, and sometimes the bullets you have don't fit the gun you want to use so you need to go learn something new. The good news is that programing fundamentals are universal. It's just math and logic. Beyond that it's syntax and there's really only 3 popular conventions there these days (things that look like basic, things that look like C and things that use smalltalk like Objective C/Ruby). Then you get down to the nuts and bolts of the language and platform etc. which takes some learning but if you have the basics down then you're really most of the way there, you just need to learn quirks (not saying that's easy, but it's a lot easier to learn your 4th language than your first no matter how simple the first was just because you didn't know what an if statement was when you started the first time...) Personally I try to dabble in lots of languages to keep a well stocked arsenal, and then I dig deeper into things the more I use them. My Java skills are atrocious but I know enough to a) make a few bucks from my apps written in Java and b) know that there's a LOT more to learn if I want to go further down that road. On the flip side I'm pretty darn solid with Objective C at this point but I still keep my eyes open for new features and tools that can save me time (oh protocols how did I ever live without you in those early days). It's when you start to target multiple platforms that middleware and cross compiling languages and tools really save time. As with everything else there's a trade off, usually performance and optimization in favor of ease of support, but sometimes that's worth it. 1 person supporting a family of apps for Mac/Windows/Linux/iOS/Android is pretty daunting if you don't have some cohesion in your code base, and structural similarities across languages/platforms. |
| ||
| Thanks for the insight I enjoy everything I’ve been learning with Java so far. I guess I get a bit nervous with the heaviness of the platform/language. That is, I guess I haven’t had any problems with it so far, but every time I run a program with it, it feels like my computer is going to crash or something. Unlike, Blitz, Python, FreeBasic or others where things just run with almost a snap. Thanks |
| ||
| Well, as I said above, it's got a lot to do with what the language is intended for and how they go about making it do that. Most of the other languages you've been using are intended for games and small programs, while Java is intended for high-powered business servers that need to run for weeks at a time. Here's something that's worthy of notice: Unlike, Blitz, Python, FreeBasic or others where things just run with almost a snap. Assuming you're using CPython (the one you get from the Python website), did you know that Python is actually interpreted? That means the instructions are "read" in software rather than directly executed as machine code. As a simple matter of mathematics, a bytecode interpreter has to be 6-30 times slower than running the same code directly on the metal (because you need to allow for the host program's surrounding instructions). And yet Python "feels" faster than Java... ...well, that's probably because of 1) Java needing time to load up the massive runtime with the vast array of powerful libraries - a "batteries included" Python runtime is still only a dozen MB or so - and 2) the JIT engine kicking in. JIT is what I mentioned above: a profiler runs alongside the code, which itself starts out interpreted, and Java spends a few minutes measuring the performance characteristics, how many times methods get called etc., in order to decide how to best 1) rearrange what you've written to make it more efficient (e.g. it might "flatten" loops, or "inline" methods), and 2) which sections are worth compiling down to x86 machine code so they can run directly on your CPU (it will eventually do this for the whole program, but start with the most important bits). In other words, while a Java program will eventually become the fastest thing to run if left long enough, it needs a substantial amount of time to warm up, get everything spinning, get up to speed etc. Python doesn't bother with any of that, and the end result will crunch numbers quite slowly... but it kicks off almost immediately as a result. (As analogy: consider an Olympic sprinter vs. a train. The sprinter will beat the train to cover 200 metres no problem, and the train will look very sluggish if you only judge it on such a short race.) This is where the intended use topic shows its face. Because Java is intended primarily for Big Things, it's 1) worth all that initial hassle, and 2) the hassle itself is less evident since the programs aren't usually interactive on the same sort of timescale as games. ... that's just intended to be an explanation/observation, by the way: do stick with Java, it's an excellent tool and certainly not unsuitable for games by any stretch. You can go very far with it! If you really do experience problems though, you might want to take a look at GCJ (although if you're on Windows, setting it up might be difficult). That's a more "normal" compiler for Java that just emits machine code like a Blitz or C++ compiler usually would. While it obviously won't have the potential for dynamically adaptive optimisations, it might save you some headache with the program startup time. Last edited 2012 |
| ||
| Ok, thanks Yasha. It all makes sense now. Yes, I’ll be using Java for a long time. I often hear about C++ for games, but so far, Java seems to have done more than what I need it to do and it seems powerful enough I think. So as you said, I’ll probably be using that for virtually everything regarding programming. I especially into doing games, internet stuff, and hopefully applications (when I learn more about how to do those). So thus, I get all of those things readily in one platform. And that has been what I've been needing. Last edited 2012 |
   |