Miesru99 answer is correct, let's just add a few points to help understanding these two gauges.
The following is technical blabla and may be skipped, it's there just to those willing to get a brief understanding on the stuff.
Code:
The actual EE is the PS2 CPU and GS is it's graphics system with the VUs being yet another subsystem (nowadays integrated into the same EE chip).
From the emulator's view point, The EE gauge measures the load over the PC CPU due to the activity of emulating EE+VU work while GS gauge measures how much the GS is stalling (so only indirectly indicating how well the GPU is doing it's work). In a sense, these two gauges indicates how the emulation is stalling. Besides is important to know EE gauge does not indicate the actual load on the PC CPU, only it's ability to perform what the emulator's core emulation. That's the reason one could be surprised seeing EE is nearing 100% all the while a PC CPU monitor could show the CPU is relatively unloaded and sometimes "underclocked" even. This is the case where a Windows power plan other than "Performance" which forces the CPU to run at nominal value may cause slowdown.
So, high EE gauge values is the main indicator the CPU is the bottleneck and GS is the indicator the GPU is the problem. One interesting problem arises from this situation but it's somewhat transparent to the non geek user.
That is the VUs could be looked as being one the most important parts of the graphics calculations on PS2 and that's right almost completely. Just the bulk of that VU processing is done on the CPU (at PCSX2) and then reflected on EE gauge also. The consequences of using the speedhacks may be foreseen and used to pinpoint potential issues in the gaming and help getting the best compromise for performance vs accuracy, as follow:
EE cyclerate speedhack actuates reducing (virtually underclocking) the Emotion Engine clock, the point is if EE (the PS2 CPU) running slower it becomes easier to emulate. The obvious drawback being this may seriously compromise the whole syncing and timings, hence problems with sound are the most evident.
VU cycle stealing on the other hand deals with graphics specifically, the actual PS2 VUs block is where most of graphics treatment and PS2 post processing is done. Notice this is not the same as PCSX2 post processing that is almost totally done on the plugin and does not directly affect the emulation. When this speedhack is too aggressive, and how much aggressive depends on the game, the main symptom is the game feels lagging despite the actual PCSX2 FPS is increased. Since this 60 or 50 FPS (NTSC or PAL respectively) refers to the actual PS2 refresh rate and is important to keep PCSX2 timings, some people call it "fake FPS" when the lag occurs due to speedhacks (The FPS is actually real but the "motion", the actual changing in the image is harmed).
Then, about performance vs final image quality and
"The best PCSX2 setup: the answer should be: It's a compromise.
The best PCSX2 configuration is "no speedhacks or any PCSX2 post processing features", this is what can give you the most "real" PS2 experience.
But then not every machine can do without speed hacks due to performance constraints (due to CPU lack of power) or can get the most beautiful image, better than original PS2 (due to GPU lack of power). Then...
The answer for "best PCSX2 configuration" becomes: the least hacks of any kind that the machine can afford AND the best post processing the GPU can afford meaningfully.
Just know that EE cycle rate in excess may and probably will give you sync problems, mainly with sound, reduce it if that is happening.
VU cyclestealing in excess will make the game feeling laggy and may introduce visual artifacts, reduce it if experimenting such kind of issues.
MTVU is an attempt to give multithread capacity to the VU module, this is very, very very timings depending and will help with multicore CPUs, where it does not breaks things... the other speedhacks may harm it also.
The roundings and clamping aren't really speedhacks, best keeping them at normal almost always for they are the standard for float point calculations. They may help in those cases PS2 game's code is "misbehaving" against that standard.
On the graphics quality side, use your taste and best judgement, these aren't really part of the emulation but are nice, when they don't make things worse.
in general, use criteria and the above information to get an idea of which speedhack to increase and when to try lesser values depending on the collateral effects becoming evident.
@devs
If the VU processing is moved from the CPU (at least the bulk of it) to the GPU, maybe using OpenCL or available general GPU access languages, the overall PCSX2 performance could get a greater performance boost. Still I'm not sure at all of what that suggestion implies in terms of feasibility to be even worthy further thoughts.
