Key word of your post , but that's not the point now =P . You see that more and more people has same problem as me :-/ I still could play Minecraft in 13w37 snapshot , even amplified world with no big fps drop or anything . But when 13w38 was released I started to get really bad fps drop in my singleplayer worlds . I wish I could overclock my PC , but that's sadly not possible :-(
...
"yes , we have all those awesome new things in game , now let's try to make it a bit more playable even for those people who use "toaster" PC's and make even their life nicer and easyer by playing our game" .
...
If things really worked like that, people on horse-pulled carts would be allowed to "drive" on the highways right inside the 60MPH normal traffic.
This is a very ignorant statement, with nothing to back it up.
Except that by using a java based program (PICK ONE) you will be able to clearly demonstrate that it is a crawling turd of a language.
You can try to explain and apologize the stink away, but it is still going to be mind numbingly slow.
-edit
So the benefit is cross-platform portability.
Oh wait... it has to be re-written for each platform anyway.
I used to be able to run a server and play smoothly on it with 3-4 other people on at the same time. Ever since this new patch came out I was unable to even run the server alone. Maxes out my CPU and it is extremely choppy/laggy. Like... what happened?
Here are my computer specs before assuming that my PC is not capable
Processor: i7 CPU 950 @ 3.07 Ghz
Ram: 12.0 GM
Graphics Card: Nvidia 580GTX OC Edition
Windows 8 64bit (this shouldnt even matter as the previous version ran the server without a problem or even close to lag issues)
Installed on a SSD aswell...
Went from an average 20% CPU use to 80-100% spiking and none stop lag/choppiness after this new patch.
Unplayable. Stop saying to upgrade computer hardware when that's clearly not the issue here.
Unless you are telling me an i7/580+video card with 4+GB ram on server cant handle it... 80mbps download /10mbps upload connection
Actually the main languages I use for work are C# and C++. The Only Java work I've had to do for my job was so that we could use Jasper Reports, and I still want to try to convert Jasper Reports into a .NET assembly using IKVM for consistency's sake, because passing data through command-line arguments is inflexible.
As you can see, the wild programmer expresses the strange behavior of insisting that when optimized code running in a slow language running almost as fast as unoptimized code in a faster means the slow language is almost as fast as the faster.
I cannot even tell what you were trying to say, since that sentence doesn't make any sense. here's a question: if C++ is so much faster than Java, why was I able to get Java practically on par with it? And why was the F# implementation faster? What about my C++ version was intrinsically "unoptimized"? I compiled it with the highest optimizations. I'd be all ears to improve it and update the post(s). In fact the Java implementation runs slightly faster on a Dalvik-based Virtual Machine. Though I suspect the C++ compiler just sucks.
Also interesting is that when I parallelized the C# version, it actually reduced the total run-time, which sort of flies in the face of what most dilettante's would argue, which is essentially to try to thread everything for performance. In that instance running one of my cores at 25% and not using the others ended up being faster than using every core, simply due to the synchronization considerations and data sharing locks. People claiming Minecraft needs to be "threaded" are too insistent on a silver bullet.
The simple fact of the matter is that Java is meant to be easy to read and write, not run fast
One of the principles on which the Java language was originally designed was "It should execute with "high performance"". As noted here (That is actually an earlier document written by Sun Microsystems in 1999). Refer to 1.2.4.
and that there is a major reason that most of the Java VM is written in C and C++.
The Major reason that the java VM is written in C and C++ (For Hotspot) is because a Virtual Machine needs to be written using an existing compiler that emits native code without dependencies. C and C++ are the obvious best choice for this.
The Virtual Machine can never be written in Java simply because it cannot run itself by definition. The Java Compiler was originally also written in C/C++, since obviously a compiler is sort of needed. It is now written in Java, following the standard of most Compilers to be written in their own language.
the C++ Standard runtime includes C libraries such as stdlib and stdio. I could easily make the same implications by saying "there is a reason the C++ runtime is written in C".
Another consideration is that the performance gain by rewriting C++ into ANSI C can often be on the same magnitude as comparing equivalent Java and C++ implementations.
Does that mean C is better?
Further still, the performance gain by rewriting C into Assembly can often be the same magnitude as C++ to C. Does that mean assembly is better?
Except that by using a java based program (PICK ONE) you will be able to clearly demonstrate that it is a crawling turd of a language.
You can try to explain and apologise the stink away, but it is still going to be mind numbingly slow.
Windows-Based Java Applications generally suck performance-wise because of Swing, or rather, because the developers use too many advanced Swing features without considering the performance implications on all machines. The same could be said of WPF, Though WPF can be worse since it's easy to add that fancy glow effect to pretty much everything, then wonder why suddenly the entire UI is slow. standard java.awt looks reasonable as long as you don't want advanced features on the Controls you use, and looks System-Native as well as being more performant than Swing. The best way to break it down is that if a Program uses Swing, it will probably be slow. If it uses the SWT, it will run reasonably quickly. But both ofd those of course have exceptions.
I find the selection bias amusing, however; For example, if say, Eclipse is really slow, why is that a point against Java, while Adobe Reader- also typically considered to be quite bloaty- is not a point against C++, which is what it's written in? Surely if measuring and looking at them both objectively they should be measured with teh same yardstick; if Eclipse being slow is a point against the development tool used to create it, surely Adobe Reader being slow should count against the development tool used to create it as well. Instead, most people would rightly blame Adobe for Reader being slow.
And yet when people find issues with Eclipse, (or netbeans) it is instantly Java. Both Netbeans and Eclipse are pretty bulky. They are quite slow in general. Is it Java? Probably not- IntelliJ is written in Java and it manages to be more performant. So is PyCharm, PHPStorm, and RubyMine (arguably all based on the same base Jetbrains IDE). It's almost as if the software is slow, not the middleware used to create it. What a novel concept.
Add to that more performant programs such as Oxygen XML, smartsvn, and QNext ,LibreOffice, part of that is written in Java, though arguably that is vestigial from OpenOffice which was started by Sun and obviously they wanted to put Java into everything. Jasper iReport is no less responsive or performant than any other applications I've run. Consider also that 99.9% of Android Apps are written using Java. The only difference between that implementation and the desktop implementation is primarily in different UI framework, since of course Android Apps can't go using java.awt.* or javax.swing.*, after all. squirrelSQL is no slower than pgAdmin or mySQL Workbench.(Though, I'm not sure if it lets you edit schema, I was not able to find out how and ended up just using direct queries) jEdit is at least as speedy as EditPad Pro (Which is native code Delphi), though it lacks the same features. It also lacks a price tag, too, to be fair.
It's also interesting that the "It's slow because of Java" side don't seem to have any strong, experiment-based evidence supporting it. I provided my sources, which were based on my own research on the subject at hand (well, sort of, it was more "implement this stuff as fast as possible everywhere". If the C++ implementation is sub-par, I'd be interested to hear ideas for improvements; otherwise it seems a bit knee-jerk to try to refute my evidence with assertions. It would be more beneficial to point out how that evidence is flawed. I don't think it is, but I am hardly a C++ expert by any means. Perhaps there is a compiler switch or pragma I could use to make it faster; or even say a different compiler with different such flags; I fiddled with g++/gcc as well as the MS Compiler and went with the faster result I was able to get, which weighed in at around 400ms for the full calculation. the Java version was originally about twice that speed (And still shows that in my conclusions table), but with some changes to the virtual machien arguments and tuning I was able to bring that within 100ms of the C++ runtime, which includes the time required for the VM to initialize.
In terms of VM-based software one huge advantage is not only portability but forwardability- that is, the performance characteristics of the program are not necessarily static but can change based on their environment. VMs can be changed to support new CPU instructions and CPU features and every single program that runs on that VM will instantly be able to support those new CPU features when available.
In contrast- Most C++ and C Programs are still compiled to target the original Pentium instruction set, with the occasional, piecemeal support for new architectures usually only present in multimedia libraries. This also applies to many games, which while theydon't typically target i586 for their Object code, they are compiled against a lowest common denominator, the result of which is that they never support new processor features. With Virtualized Machine old code can easily be 'magicked' into using the new whizbang processor capabilities. You can run Java Programs from the 90's and they will use SIMD and SSE2/etc. The same cannot be said of older Native Applications.
Exactly. It's slow.
If I make my race car out of granite, excusing the fact that it's slow by eluding to the physical nature of rock, isn't going to somehow speed it up. In practice and execution, it's still going to be slow.
-edit
Though novel test setups could be engineered to make it seem faster, those isolated results fall the ____ apart when you apply them to something as large as , say.. a video game about stacking blocks.
-edit
The only evidence I bring is the observation of Java base programs. I am not concerned with the middleware or design paradigms used by the programmers. You claim Adobe Reader to be slow.. It works fine for me. I use it all day and have never had it collapse into a crash log of gibbering nonsense. Minecraft, Eclipse(I rarely touch this thing), and OpenOffice on the other hand, are dragging along, complaining periodically, but muddling through the best they can. It's just the observation from using the programs, not any enlightened view of the fine points of the language's design.
Big games complain and crash and fail to start for me, but they also clearly state they require specific hardware and software environments to operate correctly. Something that minecraft.net could benifit from. A system requirements section.
The end result is that if you want Minecraft to run like a beast, you need a beast machine. I'm pretty sure trying to port it to some kind of C would be an awful mess. It's a shame that such a simple looking game has to be run on monster hardware to be playable. Seems like the only solution folks come up with is to throw more hardware at it. Cool optimization technique.
Key word of your post , but that's not the point now =P . You see that more and more people has same problem as me :-/ I still could play Minecraft in 13w37 snapshot , even amplified world with no big fps drop or anything . But when 13w38 was released I started to get really bad fps drop in my singleplayer worlds . I wish I could overclock my PC , but that's sadly not possible :-(
Well it's not something that is necessary now.
I have not looked at recent snapshots so I am curious if it will affect me too. The problem with computers is that each one is different - I have even seen in the past two exact machines that I built having different results in benchmarking when all the hardware and OS components were exactly the same.
I'm pretty sure trying to port it to some kind of C would be an awful mess. It's a shame that such a simple looking game has to be run on monster hardware to be playable.
I liked your post for the matter of Java performance issues. Exclusively. But I think you extend your, otherwise correct, thoughts a little too far and into Minecraft perfomance.
The idea that we could get an optimized version of Minecraft in C++ isn't probably true. I say probably because we don't have that version yet. So we can't say for sure. But it's not really clear whether Minecraft would benefit from C++. Here's why:
Minecraft isn't processor or memory intensive. All you need is to take a good look at your computer. Don't use the pathetic performance tab in Task Manager, like some people like to do. It will give you only generic information of little use. Better is to use windows Performance Monitor (under Administrative Tools in your Start menu) and set some good processor, memory and memory page counters. You will even have the benefit of saving the whole results session in a nice report.
Since C++ and Java can only be discussed in terms of the resulting performance of their binaries, you can see how the fact Minecraft doesn't make much use of the CPU and RAM can be an issue to a claim that C++ would be a better language.
Another issue is the, for the lack of a better word, Minecraft 3D geometry. Even in C++ you don't have 3D APIs capable of handling the way Minecraft worlds are created. This isn't out typical first-person world. Everything in it is an entity. Every single block is something you can interact with. And every single block/entity needs to have it's own discreet texture. 3D engines were not written for this type of world. They operate on the assumption you have a backdrop scenery and entities. If you push the entities number too far and you get performance issues.
This is one of the reasons why we got into voxel 3d engines (the main one being they are way much better than today's polygon system). They are still in their infancy though and no in any way prepared to handle Minecraft. So in essence, C++ wouldn't offer an advantage also because no available 3D API exist that can handle its esoteric geometry.
...
Here's the conundrum: Minecraft in Java, Minecraft in C++, Minecraft in Pascal, Minecraft in C#, heck Minecraft in Assembly(!), all will have similar performance issues. The game performance isn't processor or memory relevant. What it needs is a dedicated 3D engine capable of optimizing its game geometry. You get a library in any of these languages that can do just that, and Minecraft in that language will be faster than in any other.
TL;DR: The programming language doesn't matter in a game like Minecraft.
I can concede that it isn't all Java's fault. It just bugs me when folks tell me a program is running fine while I'm sitting at my machine watching it gasp for air and it's performance is mirrored by other programs using the same language. Java make for an easy target.
Either way, I just sold out and bought a GT 610. That should get me at least to 30 FPS. If it doesn't, I'm giving my login info to one of the neighbor kids and never looking back. (Why do the kids have better equipment than me?)
In other words, you lack reading comprehension. Gotcha.
If I make my race car out of granite, excusing the fact that it's slow by eluding to the physical nature of rock, isn't going to somehow speed it up. In practice and execution, it's still going to be slow.
That's a great analogy; though it works against your intent. There is nothing inherent in Granite or Rock that would make your race car slower. it also completely ignores the wealth of examples of fast software written in Java; since the allegation is that the Java platform is itself slow, the logical conclusion would be that anything running on it is slow as well. Since software is written that is quite performant and runs on the Java platform, the only reasonable conclusion would be that it is not the platform that is inherently slow.
Though novel test setups could be engineered to make it seem faster, those isolated results fall the ____ apart when you apply them to something as large as , say.. a video game about stacking blocks.
What about my particular examples is novel? Both IntelliJ and Jasper Reports are very large and in the latter case can be much more resource intensive even than a game in some situations. In what ways does the analogy not hold up when we move to games?
The only evidence I bring is the observation of Java base programs.
Neat. That's what I brought too. IntelliJ is written in Java. So are a number of the other examples I gave. Except for one example for which I purposely included that wasn't. I'll get to that in a moment.
I am not concerned with the middleware or design paradigms used by the programmers.
That was the initial postulation. the Java Virtual Machine is the middleware being used. The supposition was that it caused anything that ran on it to be inherently slow. That was what I was mentioning. I didn't even mention anything design paradigm related, so I'm going to have to misunderstand you there.
You claim Adobe Reader to be slow.. It works fine for me.
I didn't say I didn't work. I said it was slow. It's demonstrably slower than almost every competing PDF Reader- Foxit, Sumatra, and even Nitro PDF, which despite it's name is slowest of the three (except Adobe Reader, of course). Adobe Reader takes longer to start than Visual Studio (for me) for goodness sake. (And that doesn't even account for the fact that it installs Potentially Unwanted Software (McAffee Security Scan)).
I use it all day
Hey now, I doubt that. What are you doing that requires you to view PDFs all day long :/
and have never had it collapse into a crash log of gibbering nonsense.
I can believe that. Since it would default to the Standard Windows Error Report "Adobe Reader has Stopped working".
Eclipse(I rarely touch this thing)
Neither do I. IntelliJ is worlds better IMO.
OpenOffice on the other hand, are dragging along, complaining periodically, but muddling through the best they can. It's just the observation from using the programs, not any enlightened view of the fine points of the language's design.
OpenOffice huh. Well I guess we can switch my previous mention of Adobe Reader to OpenOffice.
OpenOffice is written in C++. Only some parts are written in Java, and they are unlikely to be used particularly frequently.
More importantly, to support the argument against the Java Platform you are trying to push forward, you should have known which parts are in fact based on Java- because obviously they would be a lot slower than the rest of the program.
I am more suspect that you saw I mentioned Openoffice as using Java and started with a preception- conscious or otherwise- that it was slow and bloaty, without looking further into it. While OpenOffice uses Java- it doesn't actually require it, and the application itself is written entirely in C++. So you've essentially made my initial argument that the Language/technology doesn't matter at all. There are fast applications written in Java, there are slow applications written in Java, and there are fast applications written in C++ and there are slow Applications written in C++; and of course, you can find examples in pretty much any other language as well. In fact it would seem that you agree with my core consideration that the people using a piece of software really don't care what it's written in at all.
Big games complain and crash and fail to start for me, but they also clearly state they require specific hardware and software environments to operate correctly. Something that minecraft.net could benifit from. A system requirements section.
The end result is that if you want Minecraft to run like a beast, you need a beast machine.
Ahh. I see. You are under the (arguably reasonable) impression that because minecraft's default textures are a low resolution, and the game appears simple, that the game's geometry is trivial to process. unfortunately, Minecraft would have these same performance issues regardless of the language it is written in, simply because it falls into the immense amount of geometry.
I can concede that it isn't all Java's fault. It just bugs me when folks tell me a program is running fine while I'm sitting at my machine watching it gasp for air and it's performance is mirrored by other programs using the same language. Java make for an easy target.
I'd argue that your sample size was too small. I mean, Eclipse, which you yourself say you don't use often (but is definitely pretty slow) and Minecraft. One of the examples wasn't even Java at all, but a Red Herring C++ Program I purposely planted to trick you because I'm a dickface. But not purely because the front of my head is akin to a phallus, but also to point out that all software can be slow and there correlation!=causation.
Thing is, I'd LOVE if Java could be shown to be slow. I can't stand the language. It's restrictive, overly verbose, and about 10 years behind almost everything else. I'd prefer to work on Minecraft plugins in C# rather than Java, however my strong dislike for Java is rooted in the fact that the language is terrible, not due to anything performance related. Interestingly part of the prompt for the initial set of comparatives I made was because somebody tried to claim that C# was slower than Java.
It's probably fair to say that Java would be pretty much dead on the desktop if it wasn't for Minecraft. 99.9% of people installing a Java runtime are doing it to Play Minecraft.
Either way, I just sold out and bought a GT 610. That should get me at least to 30 FPS. If it doesn't, I'm giving my login info to one of the neighbor kids and never looking back. (Why do the kids have better equipment than me?)
Hmm, strange. I built this PC in 2009 (9800GT, 8GB DDR2, and a Q8200 @2.33Ghz CPU) and I'm able to run at 60fps. I use a view distance of 10. My base however has framerate issues because I decided for whatever reason to have massive animal farms, cactus farms, reed farms, and pretty much everything farms right near my base, not to mention stained glass, leaves, and tree farms. I did notice with the fix to view distance a massive drop in performance, but that was because when the slider was added, I maxed it out, and at that point it was fixed so suddenly the game was loading and ticking pretty twice as many chunks as before. I could reduce other things such as smooth lighting and/or Fancy graphics if I want, and occasionally I do.
Fact is if you want to max out pretty much any recent game you are going to have to get a maxed out machine. I guess the frustration comes when people either do not want to build or buy a new machine for whatever reason, especially when the game they want to max out appears so deceptively simple.
Sorry creeperskelly, but your supposed tests... how can I say this... don't agree with my own experience with the game over the nearly 4 tears of playing it and the imense amount of machines I used or saw being while playing minecraft.
Don't know how you are getting these numbers. But I won't simply trust them because you posted them and called them your tests. It's just not as most people see or experience Minecraft.
Have a nice day.
Rollback Post to RevisionRollBack
I was trying to think of a signature and this is what came up.
Key word of your post , but that's not the point now =P . You see that more and more people has same problem as me :-/ I still could play Minecraft in 13w37 snapshot , even amplified world with no big fps drop or anything . But when 13w38 was released I started to get really bad fps drop in my singleplayer worlds . I wish I could overclock my PC , but that's sadly not possible :-(
If things really worked like that, people on horse-pulled carts would be allowed to "drive" on the highways right inside the 60MPH normal traffic.
Except that by using a java based program (PICK ONE) you will be able to clearly demonstrate that it is a crawling turd of a language.
You can try to explain and apologize the stink away, but it is still going to be mind numbingly slow.
-edit
So the benefit is cross-platform portability.
Oh wait... it has to be re-written for each platform anyway.
Why is Java good again?
This is your problem.
Format your hard drive and install Windows XP. It's much faster.
Please click the button if this post/topic was helpful/useful/fun in any way!
Here are my computer specs before assuming that my PC is not capable
Processor: i7 CPU 950 @ 3.07 Ghz
Ram: 12.0 GM
Graphics Card: Nvidia 580GTX OC Edition
Windows 8 64bit (this shouldnt even matter as the previous version ran the server without a problem or even close to lag issues)
Installed on a SSD aswell...
Went from an average 20% CPU use to 80-100% spiking and none stop lag/choppiness after this new patch.
Unplayable. Stop saying to upgrade computer hardware when that's clearly not the issue here.
Unless you are telling me an i7/580+video card with 4+GB ram on server cant handle it... 80mbps download /10mbps upload connection
Actually the main languages I use for work are C# and C++. The Only Java work I've had to do for my job was so that we could use Jasper Reports, and I still want to try to convert Jasper Reports into a .NET assembly using IKVM for consistency's sake, because passing data through command-line arguments is inflexible.
I cannot even tell what you were trying to say, since that sentence doesn't make any sense. here's a question: if C++ is so much faster than Java, why was I able to get Java practically on par with it? And why was the F# implementation faster? What about my C++ version was intrinsically "unoptimized"? I compiled it with the highest optimizations. I'd be all ears to improve it and update the post(s). In fact the Java implementation runs slightly faster on a Dalvik-based Virtual Machine. Though I suspect the C++ compiler just sucks.
Also interesting is that when I parallelized the C# version, it actually reduced the total run-time, which sort of flies in the face of what most dilettante's would argue, which is essentially to try to thread everything for performance. In that instance running one of my cores at 25% and not using the others ended up being faster than using every core, simply due to the synchronization considerations and data sharing locks. People claiming Minecraft needs to be "threaded" are too insistent on a silver bullet.
One of the principles on which the Java language was originally designed was "It should execute with "high performance"". As noted here (That is actually an earlier document written by Sun Microsystems in 1999). Refer to 1.2.4.
The Major reason that the java VM is written in C and C++ (For Hotspot) is because a Virtual Machine needs to be written using an existing compiler that emits native code without dependencies. C and C++ are the obvious best choice for this.
The Virtual Machine can never be written in Java simply because it cannot run itself by definition. The Java Compiler was originally also written in C/C++, since obviously a compiler is sort of needed. It is now written in Java, following the standard of most Compilers to be written in their own language.
the C++ Standard runtime includes C libraries such as stdlib and stdio. I could easily make the same implications by saying "there is a reason the C++ runtime is written in C".
Another consideration is that the performance gain by rewriting C++ into ANSI C can often be on the same magnitude as comparing equivalent Java and C++ implementations.
Does that mean C is better?
Further still, the performance gain by rewriting C into Assembly can often be the same magnitude as C++ to C. Does that mean assembly is better?
Windows-Based Java Applications generally suck performance-wise because of Swing, or rather, because the developers use too many advanced Swing features without considering the performance implications on all machines. The same could be said of WPF, Though WPF can be worse since it's easy to add that fancy glow effect to pretty much everything, then wonder why suddenly the entire UI is slow. standard java.awt looks reasonable as long as you don't want advanced features on the Controls you use, and looks System-Native as well as being more performant than Swing. The best way to break it down is that if a Program uses Swing, it will probably be slow. If it uses the SWT, it will run reasonably quickly. But both ofd those of course have exceptions.
I find the selection bias amusing, however; For example, if say, Eclipse is really slow, why is that a point against Java, while Adobe Reader- also typically considered to be quite bloaty- is not a point against C++, which is what it's written in? Surely if measuring and looking at them both objectively they should be measured with teh same yardstick; if Eclipse being slow is a point against the development tool used to create it, surely Adobe Reader being slow should count against the development tool used to create it as well. Instead, most people would rightly blame Adobe for Reader being slow.
And yet when people find issues with Eclipse, (or netbeans) it is instantly Java. Both Netbeans and Eclipse are pretty bulky. They are quite slow in general. Is it Java? Probably not- IntelliJ is written in Java and it manages to be more performant. So is PyCharm, PHPStorm, and RubyMine (arguably all based on the same base Jetbrains IDE). It's almost as if the software is slow, not the middleware used to create it. What a novel concept.
Add to that more performant programs such as Oxygen XML, smartsvn, and QNext ,LibreOffice, part of that is written in Java, though arguably that is vestigial from OpenOffice which was started by Sun and obviously they wanted to put Java into everything. Jasper iReport is no less responsive or performant than any other applications I've run. Consider also that 99.9% of Android Apps are written using Java. The only difference between that implementation and the desktop implementation is primarily in different UI framework, since of course Android Apps can't go using java.awt.* or javax.swing.*, after all. squirrelSQL is no slower than pgAdmin or mySQL Workbench.(Though, I'm not sure if it lets you edit schema, I was not able to find out how and ended up just using direct queries) jEdit is at least as speedy as EditPad Pro (Which is native code Delphi), though it lacks the same features. It also lacks a price tag, too, to be fair.
It's also interesting that the "It's slow because of Java" side don't seem to have any strong, experiment-based evidence supporting it. I provided my sources, which were based on my own research on the subject at hand (well, sort of, it was more "implement this stuff as fast as possible everywhere". If the C++ implementation is sub-par, I'd be interested to hear ideas for improvements; otherwise it seems a bit knee-jerk to try to refute my evidence with assertions. It would be more beneficial to point out how that evidence is flawed. I don't think it is, but I am hardly a C++ expert by any means. Perhaps there is a compiler switch or pragma I could use to make it faster; or even say a different compiler with different such flags; I fiddled with g++/gcc as well as the MS Compiler and went with the faster result I was able to get, which weighed in at around 400ms for the full calculation. the Java version was originally about twice that speed (And still shows that in my conclusions table), but with some changes to the virtual machien arguments and tuning I was able to bring that within 100ms of the C++ runtime, which includes the time required for the VM to initialize.
In terms of VM-based software one huge advantage is not only portability but forwardability- that is, the performance characteristics of the program are not necessarily static but can change based on their environment. VMs can be changed to support new CPU instructions and CPU features and every single program that runs on that VM will instantly be able to support those new CPU features when available.
In contrast- Most C++ and C Programs are still compiled to target the original Pentium instruction set, with the occasional, piecemeal support for new architectures usually only present in multimedia libraries. This also applies to many games, which while theydon't typically target i586 for their Object code, they are compiled against a lowest common denominator, the result of which is that they never support new processor features. With Virtualized Machine old code can easily be 'magicked' into using the new whizbang processor capabilities. You can run Java Programs from the 90's and they will use SIMD and SSE2/etc. The same cannot be said of older Native Applications.
Exactly. It's slow.
If I make my race car out of granite, excusing the fact that it's slow by eluding to the physical nature of rock, isn't going to somehow speed it up. In practice and execution, it's still going to be slow.
-edit
Though novel test setups could be engineered to make it seem faster, those isolated results fall the ____ apart when you apply them to something as large as , say.. a video game about stacking blocks.
-edit
The only evidence I bring is the observation of Java base programs. I am not concerned with the middleware or design paradigms used by the programmers. You claim Adobe Reader to be slow.. It works fine for me. I use it all day and have never had it collapse into a crash log of gibbering nonsense. Minecraft, Eclipse(I rarely touch this thing), and OpenOffice on the other hand, are dragging along, complaining periodically, but muddling through the best they can. It's just the observation from using the programs, not any enlightened view of the fine points of the language's design.
Big games complain and crash and fail to start for me, but they also clearly state they require specific hardware and software environments to operate correctly. Something that minecraft.net could benifit from. A system requirements section.
The end result is that if you want Minecraft to run like a beast, you need a beast machine. I'm pretty sure trying to port it to some kind of C would be an awful mess. It's a shame that such a simple looking game has to be run on monster hardware to be playable. Seems like the only solution folks come up with is to throw more hardware at it. Cool optimization technique.
Well it's not something that is necessary now.
I have not looked at recent snapshots so I am curious if it will affect me too. The problem with computers is that each one is different - I have even seen in the past two exact machines that I built having different results in benchmarking when all the hardware and OS components were exactly the same.
I liked your post for the matter of Java performance issues. Exclusively. But I think you extend your, otherwise correct, thoughts a little too far and into Minecraft perfomance.
The idea that we could get an optimized version of Minecraft in C++ isn't probably true. I say probably because we don't have that version yet. So we can't say for sure. But it's not really clear whether Minecraft would benefit from C++. Here's why:
Minecraft isn't processor or memory intensive. All you need is to take a good look at your computer. Don't use the pathetic performance tab in Task Manager, like some people like to do. It will give you only generic information of little use. Better is to use windows Performance Monitor (under Administrative Tools in your Start menu) and set some good processor, memory and memory page counters. You will even have the benefit of saving the whole results session in a nice report.
Since C++ and Java can only be discussed in terms of the resulting performance of their binaries, you can see how the fact Minecraft doesn't make much use of the CPU and RAM can be an issue to a claim that C++ would be a better language.
Another issue is the, for the lack of a better word, Minecraft 3D geometry. Even in C++ you don't have 3D APIs capable of handling the way Minecraft worlds are created. This isn't out typical first-person world. Everything in it is an entity. Every single block is something you can interact with. And every single block/entity needs to have it's own discreet texture. 3D engines were not written for this type of world. They operate on the assumption you have a backdrop scenery and entities. If you push the entities number too far and you get performance issues.
This is one of the reasons why we got into voxel 3d engines (the main one being they are way much better than today's polygon system). They are still in their infancy though and no in any way prepared to handle Minecraft. So in essence, C++ wouldn't offer an advantage also because no available 3D API exist that can handle its esoteric geometry.
...
Here's the conundrum: Minecraft in Java, Minecraft in C++, Minecraft in Pascal, Minecraft in C#, heck Minecraft in Assembly(!), all will have similar performance issues. The game performance isn't processor or memory relevant. What it needs is a dedicated 3D engine capable of optimizing its game geometry. You get a library in any of these languages that can do just that, and Minecraft in that language will be faster than in any other.
TL;DR: The programming language doesn't matter in a game like Minecraft.
Either way, I just sold out and bought a GT 610. That should get me at least to 30 FPS. If it doesn't, I'm giving my login info to one of the neighbor kids and never looking back. (Why do the kids have better equipment than me?)
Ah, don't we know!
My best, most expensive computers?... When I didn't have to work for a living and my father did the buying.
Any unauthorized reposting of images or any published material of mine from this thread will be prosecuted to the fullest extent of the law.
In other words, you lack reading comprehension. Gotcha.
That's a great analogy; though it works against your intent. There is nothing inherent in Granite or Rock that would make your race car slower. it also completely ignores the wealth of examples of fast software written in Java; since the allegation is that the Java platform is itself slow, the logical conclusion would be that anything running on it is slow as well. Since software is written that is quite performant and runs on the Java platform, the only reasonable conclusion would be that it is not the platform that is inherently slow.
What about my particular examples is novel? Both IntelliJ and Jasper Reports are very large and in the latter case can be much more resource intensive even than a game in some situations. In what ways does the analogy not hold up when we move to games?
Neat. That's what I brought too. IntelliJ is written in Java. So are a number of the other examples I gave. Except for one example for which I purposely included that wasn't. I'll get to that in a moment.
That was the initial postulation. the Java Virtual Machine is the middleware being used. The supposition was that it caused anything that ran on it to be inherently slow. That was what I was mentioning. I didn't even mention anything design paradigm related, so I'm going to have to misunderstand you there.
I didn't say I didn't work. I said it was slow. It's demonstrably slower than almost every competing PDF Reader- Foxit, Sumatra, and even Nitro PDF, which despite it's name is slowest of the three (except Adobe Reader, of course). Adobe Reader takes longer to start than Visual Studio (for me) for goodness sake. (And that doesn't even account for the fact that it installs Potentially Unwanted Software (McAffee Security Scan)).
Hey now, I doubt that. What are you doing that requires you to view PDFs all day long :/
I can believe that. Since it would default to the Standard Windows Error Report "Adobe Reader has Stopped working".
Neither do I. IntelliJ is worlds better IMO.
OpenOffice huh. Well I guess we can switch my previous mention of Adobe Reader to OpenOffice.
OpenOffice is written in C++. Only some parts are written in Java, and they are unlikely to be used particularly frequently.
More importantly, to support the argument against the Java Platform you are trying to push forward, you should have known which parts are in fact based on Java- because obviously they would be a lot slower than the rest of the program.
I am more suspect that you saw I mentioned Openoffice as using Java and started with a preception- conscious or otherwise- that it was slow and bloaty, without looking further into it. While OpenOffice uses Java- it doesn't actually require it, and the application itself is written entirely in C++. So you've essentially made my initial argument that the Language/technology doesn't matter at all. There are fast applications written in Java, there are slow applications written in Java, and there are fast applications written in C++ and there are slow Applications written in C++; and of course, you can find examples in pretty much any other language as well. In fact it would seem that you agree with my core consideration that the people using a piece of software really don't care what it's written in at all.
It's not on Minecraft.net but It's pretty close.
Ahh. I see. You are under the (arguably reasonable) impression that because minecraft's default textures are a low resolution, and the game appears simple, that the game's geometry is trivial to process. unfortunately, Minecraft would have these same performance issues regardless of the language it is written in, simply because it falls into the immense amount of geometry.
I'd argue that your sample size was too small. I mean, Eclipse, which you yourself say you don't use often (but is definitely pretty slow) and Minecraft. One of the examples wasn't even Java at all, but a Red Herring C++ Program I purposely planted to trick you because I'm a dickface. But not purely because the front of my head is akin to a phallus, but also to point out that all software can be slow and there correlation!=causation.
Thing is, I'd LOVE if Java could be shown to be slow. I can't stand the language. It's restrictive, overly verbose, and about 10 years behind almost everything else. I'd prefer to work on Minecraft plugins in C# rather than Java, however my strong dislike for Java is rooted in the fact that the language is terrible, not due to anything performance related. Interestingly part of the prompt for the initial set of comparatives I made was because somebody tried to claim that C# was slower than Java.
It's probably fair to say that Java would be pretty much dead on the desktop if it wasn't for Minecraft. 99.9% of people installing a Java runtime are doing it to Play Minecraft.
Hmm, strange. I built this PC in 2009 (9800GT, 8GB DDR2, and a Q8200 @2.33Ghz CPU) and I'm able to run at 60fps. I use a view distance of 10. My base however has framerate issues because I decided for whatever reason to have massive animal farms, cactus farms, reed farms, and pretty much everything farms right near my base, not to mention stained glass, leaves, and tree farms. I did notice with the fix to view distance a massive drop in performance, but that was because when the slider was added, I maxed it out, and at that point it was fixed so suddenly the game was loading and ticking pretty twice as many chunks as before. I could reduce other things such as smooth lighting and/or Fancy graphics if I want, and occasionally I do.
Fact is if you want to max out pretty much any recent game you are going to have to get a maxed out machine. I guess the frustration comes when people either do not want to build or buy a new machine for whatever reason, especially when the game they want to max out appears so deceptively simple.
Any unauthorized reposting of images or any published material of mine from this thread will be prosecuted to the fullest extent of the law.
Don't know how you are getting these numbers. But I won't simply trust them because you posted them and called them your tests. It's just not as most people see or experience Minecraft.
Have a nice day.
Any unauthorized reposting of images or any published material of mine from this thread will be prosecuted to the fullest extent of the law.
Any unauthorized reposting of images or any published material of mine from this thread will be prosecuted to the fullest extent of the law.
Any unauthorized reposting of images or any published material of mine from this thread will be prosecuted to the fullest extent of the law.