I've noticed a very-slight improvement when using RamDISK. Optifine, by far provides a more significant increase in performance. RamDISK isn't difficult to set up either and in the case of having 16 GB of ram, you aren't soley limited to putting FTB only on your RamDISK. You could attempt to speed up other processes on your computer.
Would 16GB of RAM help?
- Thread starter Recon
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
If you're playing SSP, a ramdisk's benefit is small. Its benefit is definitely in SMP.
When it comes to multiplayer, I've found the best help is to set the CPU Affinity to 0,1,2 and 3 for the server and 4, 5, 6 and 7 for the client. Then they don't step on each other's toes much.
For now I'm trying to set up SSP because for some bizarre reason it takes my game about 45 seconds to actually connect to my own server on SMP even though its on the same machine. Strangely this does not happen if I bring my PC over to my friend's house and plug into his network. But its on MY local PC so what difference should that make? More Minecraft mysteries I guess.
For now I'm trying to set up SSP because for some bizarre reason it takes my game about 45 seconds to actually connect to my own server on SMP even though its on the same machine. Strangely this does not happen if I bring my PC over to my friend's house and plug into his network. But its on MY local PC so what difference should that make? More Minecraft mysteries I guess.
What IP did you use when setting up the server on the same computer? Did you try 127.0.0.1? I find it odd that it takes 45 seconds. Makes me wonder if it's a router-setting (one of those things I don't quite fully understand such as NAT, NAT-loopback, etc).
Your Java arguments are misconfigured.
-Xms512m: You say you are setting minimum heap memory to 3000 and maximum to 5000. So why are you then calling an argument that potentially overwrites those settings? In the best case scenario this argument is ignored and does nothing, in the worse case it overwrites your minimum=3000 setting with minimum=512.
-XX: PermSize=128M: Never EVER fix PermSize unless you absolutely know what you're doing and your application absolutely requires it fixed. In all other scenarios, setting this is a bad idea. Use -XX:MaxPermSize instead.
-XX:MaxPermSize=512m: Two issues with this: first, because you set PermSize to a fixed value above, this parameter gets ignored. Second, if it did not get ignored, this is way too much. Default is 80. Setting it to 128m is more than enough, 160m at most. If this value needs to grow beyond 160, you a.) have a memory leak because of a faulty mod and b.) will very quickly run into performance issues.
Memory Allocation: Setting both minimum and maximum to the same value will improve performance. Because of your double call of the minimum setting, you potentially have a minimum 512 / maximum 5000 setting, which is a huge gap, which can motivate the garbage collector into wasting CPU cycles on unneeded cleanups (each of which may potentially pause the game for a tick, causing the impression of microstutter). Assign no more than 2 GB for a single client, and no more than (0.5 GB * concurrent player count) for a server. Extra memory beyond that won't help, and if you go beyond 8 GB on a single client, Java starts to hiccup.
Additional performance can potentially be gained from:
-XX:AggressiveOpts: Activates extra runtime optimizations that are currently in testing for future Java releases. May or may not do anything, depending on your Java version and the application you're running.
-XX:UseConcMarkSweepGC and -XX:CMSIncrementalMode: Activates an alternative garbage collector that attempts to do its work without pausing the application. May potentially help with microstutter, but doesn't absolve you from the need to configure your memory settings properly.
Using the JRockit JVM: For advanced users only. Replaces your vanilla Java installation with an experimental one that Minecraft likes a lot. You need an Oracle account to get access to JRockit. May require manually extending the CLASSPATH variable to load certain mods (like Redpower2 or TickThreading).
If you look at this thread of mine:
I am using the JVM Arguments that Eyamaz recommended. No, I don't know what I'm doing but clearly he does.
Now, with you giving me contradicting information, I have no idea what's the right parameters to use. I do know that the game won't even load unless I put in custom JVM arguments. So what is the solution then?
I am using the JVM Arguments that Eyamaz recommended. No, I don't know what I'm doing but clearly he does.
Now, with you giving me contradicting information, I have no idea what's the right parameters to use. I do know that the game won't even load unless I put in custom JVM arguments. So what is the solution then?
Eyamaz never suggested any specific arguments in that thread. He merely agreed with the fact that large modpacks need an increased maximum permgen space, which is exactly what you are doing with the MaxPermSize argument. You are allowing Java to assign more if needed.
However the PermSize argument (without the "Max" preceding it) instead says "your permgen space is now this big". No more, no less. Completely fixed. It cannot grow, it cannot shrink. This can be a performance issue because you don't want your permanent generation larger than strictly necessary. With that setting however, you force even a simple "hello world" program to assign 128 MB memory worth of permgen space.
However the PermSize argument (without the "Max" preceding it) instead says "your permgen space is now this big". No more, no less. Completely fixed. It cannot grow, it cannot shrink. This can be a performance issue because you don't want your permanent generation larger than strictly necessary. With that setting however, you force even a simple "hello world" program to assign 128 MB memory worth of permgen space.
makes sense. I stuck my arguments back to what I had them without the permsize setting, but with the max setting to 128. I also updated the game library. So far, no crashes and I've been doing a lot of flying around in creative mode loading chunks etc.
Amazing how much this stuff affects things.
Amazing how much this stuff affects things.
On the hardware side, I'm wondering if a big texture pack might start to fill up that 1GB memory in your graphics card, rather than the rendering effort bogging down the GPU itself. 8GB should easily be enough RAM, but the graphics memory is separate and fulfils a different role. Didn't Minecraft used to load the entire texture pack into the graphics card regularly, with the new Forge performance tweaks only modifying the frequency (i.e. wouldn't the graphics card still contain more or less the entire texture pack)?
No no no no....
This information is bad! You either set both parameters or none. The JVM is really bad with how it handles its memory and dynamically chaning PermSize is the worst part. So either set -XX: PermSize= and -XX: MaxPermSize= to the same value you don't set them at all.
I havent actually kept a list of all the things i've changed over time. Ive only ever used an external profiler when programing as they tend to actually kill performance.Out of interest, Eyamaz, have you been profiling the impact of your various arguments on Minecraft? I'm too much of an amateur to properly do that, but I've always wanted to talk to someone who can really go in-depth
Actually, its a lot better now than it was in J6. even the difference in some changes they've made between 7u25 and 7u40 are amazing performance and memory management wise. I have 0 issues with u40 and only setting a maxperm. on the other hand, i always keep my Xms and Xmx set to the same value as that does cause massive performance issues, mostly due to garbage collection. Another thing you may want to look at is my GC setup. my setup prevents the GC from throttling the game every few seconds.
btw, 7u40 is a prerelease. i dont suggest upgrading to it for any general user as it is not fully tested at this time.
Really? I have seen advice to the contrary in multiple places, including @minecraftcpw...
Also, my Minecraft definitely crashes with permgen space errors if I do not set MaxPermGen=128m, and it does not crash if I set it. So the value by itself does work fine.
But, as I said above, I am an amateur at best. I'd love nothing more than to soak up knowledge from a reliable source! It's just... there's something even worse than Java's memory management, and that's the documentation of Java's memory management
Even the official hotspot JVM section at Oracle only explains half the switches and refers to the rest as if the reader already knows them.No wonder the net is full of conflicting information.
Have a look here: https://twitter.com/minecraftcpw/status/330722669341339648
cpw says its bad to use MaxPermSize without PermSize not the other way around.
Ofc it works as it dynamically resizes the PermGen if it needs to but this resizing is bad. If you got the possibility hook into your JVM while it's running and whatch what happens when it resizes.
Yeah documentation is quite bad on memory usage and settings unfortunately.But, as I said above, I am an amateur at best. I'd love nothing more than to soak up knowledge from a reliable source! It's just... there's something even worse than Java's memory management, and that's the documentation of Java's memory management
No wonder the net is full of conflicting information.
I'm too much of a noob to have a clue how
I know there's profiling tools but I wouldn't know the first thing about setting one up.Also what cpw says there looks still pretty ambiguous to me... he advises to change the permgen setting, then says it makes a difference which switch you use, and then advises not to change the permgen setting. Confusing! But I suppose it could be interpretated like you say if what he really meant to say was "resizing permgen dynamically is bad"? Sometimes a missing word can change the entire meaning. Tsk, twitter character limits...
OP....this is what I've been using (client side) for about 2 months now with no issues whatsoever. Only time I crash is from portal gun portals and right clicking a machine when it hasn't fully loaded.
-Xincgc -XX:UseSSE=4 -XX:+AggressiveOpts -XX:+CMSIncrementalPacing -XXarallelGCThreads=4 -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
In the FTB Launcher, I simply set the max ram to be 2GB and put these codes under Advanced Options.
In SMP, these codes significantly helped with the number of see-through chunks that I get. With default settings, I'd always have gaping holes in the floor that would take a while to load, even if I stood next to the hole. With the above code, these see-through chunks almost always instantaneously load when I approach them.
Just make sure that your computer supports SSE4 for the UseSSE=4 setting and that you have 4 cores if you're going to set the ParallelGCTHreads to 4.
P.S. I'm running the latest Java 7 build.
-Xincgc -XX:UseSSE=4 -XX:+AggressiveOpts -XX:+CMSIncrementalPacing -XX
arallelGCThreads=4 -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGCIn the FTB Launcher, I simply set the max ram to be 2GB and put these codes under Advanced Options.
In SMP, these codes significantly helped with the number of see-through chunks that I get. With default settings, I'd always have gaping holes in the floor that would take a while to load, even if I stood next to the hole. With the above code, these see-through chunks almost always instantaneously load when I approach them.
Just make sure that your computer supports SSE4 for the UseSSE=4 setting and that you have 4 cores if you're going to set the ParallelGCTHreads to 4.
P.S. I'm running the latest Java 7 build.