Realtime raytracing is non trivial.

GPU acceleration is not going to help you much since most tests of the different thesis I have seen still fall behind CPU ray tracing.

Suggestions to implement a real time raytracer:
1. Familiarize yourself with SIMD (SSE instructions for vectorization)
2. Implement your math library using SSE
3. Use kd-trees for space partitioning (Use SAH for building the kd-tree)
4. Do packet tracing on the kd-tree (See Ingo Wald's Phd Thesis), this will allow you to trace 4 rays at once
5. Multi-thread your ray tracer, having a number of threads = to the number of logical processors, and distributing the work equally.

the whole SIMD route is the last one you should take. hardly trivial, and for what? a 2x speedincrease if youre lucky.

If you go by the suggestion of ApochPiQ, and instead focus on Global Illumination, you will learn a lot more theory too!
If you go for realtime raytracing with simple effects you will learn about optimization techniques, tricks to skip calculations etc.

I took that CG course last year.

I believe trying to make it realtime is shooting yourself in the foot.
They'll give you a higher grade if you add more features than they request but I doubt they'll give you points for dropping features so that you could make it run realtime.
Also, keep in mind that IIRC you'll have to use 3D meshes consisting of thousands of triangles, so trying to show off with 4 bouncing spheres while they were expecting dismembered naked ladies may not work as well as you'd like. (such a model should be renderable in a few seconds, but that's still at least 10x slower than needed for realtime)

Dutré likes global illumination (CG2, which I took this year), so I would suggest as others already did, go for that. It doesn't have to run fast, so you can easily let the pc's in building B render for a few hours (or days) using Monte Carlo ray tracing or some smarter technique like photon mapping.

Lastly, if you're "just" going for a high grade:
I got a 19 (which is not exceptional for that course) with CSG, 3D textures, and Perlin noise (or maybe it was my superdooper scripting language, which I claimed of on the presentation that it supported variables, conditionals, loops, classes, inheritance and polymorphism, while in reality I was just using java itself to describe scenes and having the raytracer load the scene class dynamically) (yes, I wrote it in java). The presentation consists mostly of having a bored assistant (Ares or Pieter presumably) just asking to see a few of your pictures so that they can check if certain features are implemented. Having a dozen ready rendered at 1024x768 with nice AA will do the trick.

I followed that course too, and currently I'm doing my master thesis on frameless rendering, which can be described as a common name for techniques to speed up raytracing in animations.

To be brief, real time ray tracing is not really something extravagant. All depends on the resolution you want it to run on, and even more, the features you want to support.

consider the following:
- a sphere is about the easiest primitive to render(besides a plane), try to compare it to a 500k polygon model, could be as wel 100-500x slower, depending on your sublinear intersection structures (bounding box, bsp, ...), without those it would be 500.000x slower.
- rendering soft shadows could be 10x slower than using no shadows if you want some quality
- recursive ray tracing (reflections, refractions) slows down the process with a factor equal to your recursion depth, 10 is not uncommon.
- and if you want all the above to look nice, you need AA, again a few factors slower.

All in all, a simple scene like you described, is probably 5000x faster to render than a scene that is loaded with only simple raytracing principles (excluding any global illumination), so your 20fps might drop to 0.004fps, at least, that's only 250 seconds for a picture. I remember rendering 1000x1000, fully featured pictures in maybe an hour or so, which was pretty decent.

As said above, it's better to leave the idea of trying to make it real time, and go for features. In the end, if you go for raytracing, the only thing you need to show is results, "nice pictures" if you'd like, so focus on image quality, and don't lose your time on pure speed, because you won't be able to show the rendering speed anyway, most probably.

if you just want to render your image faster your best bet is to simply distribute the program across many computers. break up the image into square tiles and hand a tile off to each computer. other then that your first step is to impliment a good acceleration structure, such as k-d tree or adaptive grids. there are tons of papers on these. the guy talking about simd stuff also brings up a good point, but this only works for bundles of rays that are close together. so they dont help you for secondary reflections much cuz the only the first pass(the visable surface determination) are the rays so coherent. specular lobes too but tracing 4 close rays can lead to bias in statistical simulation that might take some thinking to get right. first order is nice kd tree and it's really important to take your time reading some papers on how to quickly travers and more imporatantly what huristics to use when building the grid, the basic idea is to maximize the size of regions with empty space, but no point in talking about it.

one simple an obvious speed up is to only look for the first interscetion when tracing shadow rays, instead of trying to find the closest one. trace square regions of the image instead of scanline by scanline to maximize cache coherence. instead of testing a ray against one object at a time use simd and such. not this is different then tracing bundles of ray in parallel and is much easier to impliment. good luck