The effective speed of modern CPUs is determined both by the clock speed of the processor (in MHz) and the number of independent execution units (cores). For a given processor design, the available CPU bandwidth is roughly proportional to the product of these two. Consequently, if you create a virtual server with 2100 core-MHz of CPU allocated, you should expect performance roughly equivalent to a single core of AMD Opteron 2352 clocked at 2.1GHz, and this performance varies linearly in proportion to the core-MHz number.
While the above is the case the CPU speed setting in the Go2Cloud control panel influences the time-slice that a VM gets, and with several VMs running on a host they all get a time-slice in proportion to this, and as a result, on a host that has few VMs running, they can get more time than they've requested simply because there are spare cycles to go around.
However, a vCPU core cannot run with a faster clock speed than the actual physical core that it runs on. Therefore, if you set a VM to 1 core and 8GHz, it will get plenty of time but will only run as a single core of whatever speed the physical hardware is (typically around 2GHz). You can go the other way, and give a VM 8 cores at a total CPU speed of 2GHz and then you might start to see some of those vCPU cores get starved of time-slice because the others have already used more than the allocated 2GHz equivalent time-slice. In general therefore, unless you have a specific requirement, it is best to leave the cores setting on automatic, which selects the optimum number of vCores to provide sufficient overall speed to match the requested speed.
As an example 4 cores with 8000 core-MHz total will get twice the time-slice of 4 cores with 4000 core-MHz total, but both will show up as 4 cores in the VM.