First: Do you have a 20 MHz crystal or crystal oscillator? Those are two different things. A crystal oscillator will all on its own generate a 20 MHz clock signal for the PIC and you use the external oscillator option with it.
On the other hand, the quartz crystal is an external part of the internal oscillator and internal components together with the crystal and load capacitors make a complete oscillator. In such configuration, you use various crystal modes. Also take a look at figure 2.2 on page 27 of the datasheet.
Now to set up this part correctly, you need to understand a few things, so I'll quote the datasheet:
When the PIC18F4550 is used for USB connectivity, it must have either
a 6 MHz or 48 MHz clock for USB operation, depending on whether
Low-Speed or Full-Speed mode is being used.
You need to combine things so that the USB clock is 48 MHz or 6 MHz and then you need to set-up the microcontroller operating frequency so that it works at suitable speed. Those two clocks may be different.
On page 26 of the datasheet, you have a nice diagram which you should take time to analyze. The USB PLL input expects 4 MHz frequency which it will use to generate the 96 MHz from which it will derive the operating frequency for USB and the microcontroller.
In your screenshot, the 20 MHz are divided by 5 to get the 4 MHz needed for USB PLL which then raises that to 96 MHz, as seen in the PLL prescaler section.
Then you have the system clock postscaler section. It is currently set to use the 96 MHz created by USB PLL and divided by 2 as the main system clock. You also have other options to set the main systme clock. I can't remember exactly what they are and I've just formatted my HDD, so mikroC isn't installed yet. They should offer you to derive the system clock from an internal oscillator or directly from the clock used to generate the 4 MHz for the USB PLL or as it is shown in the screenshot from the 96 MHz generated by the USB PLL.
The point here is that you can independently select the main clock and the USB clock. For example, if you have a 20 MHz oscillator, you could run the PIC main clock at those 20 MHz and at the same time run the USB clock at needed 48 MHz.
Next you have the oscillator selection part. For real crystal oscillators, you should use EC options and connect the output of the oscillator to the OSC1/CKLI pin (in your case pin 9). You can then use the 20 MHz oscillator to drive the PIC.
In case you're using a crystal, you need to use the crystal options. They are XT, for low frequency crystals, up to 4 MHz, and HS for high frequency crystals up to 20 MHz, if I remember correctly.
As for which crystal is better, well that depends on a lot of things such as which exact crystal you're using, its characteristics, characteristics of the PLL used in the PIC and so on.
Usually low frequency crystals drift less over time and produce cleaner signal while high frequency crystals often give as their output a harmonic of some lower frequency and the signal is usually weaker. I myself would use the 4 MHz crystal here.
Also I forgot the last part of your question: In the "Oscillator frequency" field, you should enter the effective operating frequency of the PIC, that is to say the frequency the "primary clock" on figure 2.1 on page 25 of the datasheet sees. In your particular case, that would be 48 MHz.
So to sum this up: In the 20 MHz crystal case, you should first set the "oscillator selection" to HSPLL. That will give 20 MHz at the input of "primary oscillator" in the above-mentioned figure 2.1. Next, you should set the PLL prescaler to divide by 5, so you get 4 MHz which are multiplied by 24 to get the 96 MHz for USB. Next set the "USB clock selection" to 96 MHz divided by 2 and set the "System clock postscaler selection" to 96 divided by two. Finally, set the Oscillator frequency to 48 MHz and you're done with this part.
For the 4 MHz crystal, you should first set HSPLL. Set the PLL prescaler to divide by 1 and then set the "USB clock selection" to 96 MHz divided by 2 and set the "System clock postscaler selection" to 96 divided by two and set the Oscillator frequency to 48 MHz and that's it.
Funny, I use both at work :)
The Cortex-M3 (we use STM32s) is a general purpose MCU that is fast and big (flash storage) enough for most complex embedded applications.
However, the R4 is a different beast entirely - at least the Texas Instruments version I use: the RM42, similar to the TMS570. The RM42 is a Cortex-R4 with two cores running in "lock-step" for redundancy, which means that one core is 2 instructions ahead of the other and is used for some error checking and correction.
Also, one of the cores are (physically) mirrored/flipped and turned 90 degrees to improve radiation/noise resilience :)
The RM42 runs at a higher clock speed than the STM32 (100MHz vs 72MHz) and has a slightly different instruction set and performs some of the instructions faster than the M3 (e.g. division instructions execute in one cycle on the R4, not sure they do on M3).
HW timers are VERY precise compared to Cortex-M3. Usually we need a static offset to correct for drift on the M3s - not so with the R4 :)
Where I'd call a Cortex-M3 a general purpose MCU, I'd call the Cortex-R4 a complex real-time/safety MCU. If I am not mistaken, the RM42 is SIL3-compliant...
IMO the R4 is a big step up in complexity even if you're not planning to actually use the real-time/safety features.
A really nice example of the complexity difference: The SPI peripheral has 9 control and status registers on the STM32 whereas the RM42 has 42. It's like this with all the peripherals :)
EDIT:
For what it's worth, in my use cases the Cortex-R4 @ 100MHz is usually 50-100% faster than the Cortex-M3 @ 72MHz when performing the exact same tasks. Maybe because the R4 has data and instruction caches?
Another comparison, a few 1000 lines of C and ASM code are executed on reset before reaching the call to main() with the subset of the safety features I currently use :D and not peripheral initialization or anything, just startup and self test (CPU, RAM, Flash ECC etc.).
This page has more details
Best Answer
You don't start out chosing a particular frequency. That eventually falls out of other requirements. Just the frequency spec accross a broad range of processors is pretty meaningless.
The real spec is some minimum performance or latency reqirement the processor has to meet. In general for any one microcontroller, processor performance is proportional to clock speed. A large portion of the power current is also proportional to clock speed, so that is one reason to not make it wildly higher than needed in power-sensitive applications. For high end general computing processors, performance is not necessarily proportional to clock speed because there are issues like cache hit percentage, memory latency, etc. Small microcontrollers intended for self-contained embedded applications don't usually have these kinds of advanced architectures and performance is pretty much linear with clock speed.
However, clock speed is a poor indicator of performance accross different microcontroller architectures. Some microcontrollers, like low end PICs for example, require 4 clock cycles per instruction cycle, some 2, and some even just 1. Then there are differences in what each architecture can accomplish in a instruction cycle. Comparing clock frequency between anything other than related processors in the same family is largely meaningless.
Another issue is that some micros have fancy internal clock chains including PLLs and dividers. The purpose is so that they can run at a variety of speeds from easy to use and find crystals. 8-16 MHz is a nice frequency for a crystal. You can certainly use crystals well outside that range, but 8 MHz is about the limit where really small packages become available, and having the external clock be otherwise as slow as reasonable is a good thing. That then brings up the question as to what the "clock speed" really is. Is is the external clock frequency you actually feed into the chip, or what the chip derives from that inside before using it otherwise? Each of these are relevant in different ways.
In short, focusing on microcontroller "clock speed", whatever that really means, is like obscessing about piston displacement and turbo boost overpressure when all you really want to know is horsepower and fuel economy. You have little reason to care how they got there, only what the result is.