well, quite good explanations and much more impressive examples can be found on IQ's website http://iquilezles.org
in the 'strawberry' pages.
the thing you probably want to look at is 'distance field ray-marching
see, as noted above, pure ray-marching is very expensive. it won't help you rendering a lot of instances much faster. in this cloud example it does a nice job and one does not need a very high resolution for the fluffy graphics. if you want to render geometry instead, that means you must find surfaces of objects that are defined in some way. well, let's dive into some detail.
in typical ray-tracing, you test the current ray (a line starting at the camera and going endlessly in the direction of view) for intersections with the shape of every object in the scene. this can be optimized a lot by building axis aligned bounding boxes around more complicated objects and whole parts of the scene. finally you build some tree-structure that enables you with a few intersection tests to figure out which objects wont be touched by the ray and which might need further investigation.
anyways, that's raytracing. if we forget about reflections, transparency and anti-aliasing then we have to do exactly one ray/scene-intersection test for each pixel-on-screen. for the moment, assume ray-marching geometry would be the same procedure, except that the ray/scene-intersection test has to be done a LOT more times for each pixel, since your actual 'ray' is only a small sub-section of the infinite ray, and it's moved this small bit after each ray/scene-test. that's not what you want to do however, just wanted to clearify the concept a bit.
ray-casting or -marching has a lot of advantages over z-buffer polygon rendering, but certainly it's not the execution speed. in particular you can render much more exact and/or complex/organic geometry. f.e. a sphere in opengl is actually a bunch of triangles. to get it exactly 'round' at a reasonable resolution you have to do a serious amount of subdivision. in raytracing you can simply state: sphere at xyz with radius r and use a geometrical sphere/line intersection test to find the surface which renders a perfect sphere in the end. besides, doing transparency, reflections, shadow and anti-aliasing can be done with the same algorithm, once it's working, with only minor additions. but i get lost here... i only wanted to say that, if speed is a concern for you when rendering a lot of geometry, you will not exactly find help in ray-casting. but it certainly can make things look nicer.
the 'distance field' technique is one major optimization to the brute-force ray-marcher. it works best for rendering surfaces and not so much for the cloud-thing above. the interesting part is that once you got a reasonable implementation running, you can indeed render an unlimited amount of instances at nearly the same speed. more precisely, copies of your scene or parts of it, or simply instances. but there are some constraints as you will learn. simply said, if you want a cube, a sphere, an iso-surface, what-ever - no problem. if you want the same object at, say, EVERY integer x,y,z position, as far as the eye can see - no problem - then some slight sine-waves that bend the universe - no problem. what about reflections, smooth shadows and volumetric lighting? - certainly. if you want a thousand objects at completely arbitrary and user-defined positions - that's a problem.
i won't repeat all the good tutorials about it here. rather i point you to this presentation:http://iquilezles.org/www/material/nvsc ... ne2008.htm
and hope you make the best out of it and the other stuff on this amazing site.
one thing though. writing such an algorithm in an opengl shader is nice and easy but does not scale to well. it's good for tiny scenes with not really much going on. for complex scenes, one would have to pack the scene data into textures or something like that. it's probably more appropriate to do it in CUDA or openCL because of the ability to send arbitrary data to the gpu. also, say you find that your scene has grown up and just looks so astonishing that you don't really care that it's not realtime anymore. but running an opengl shader that takes a second or so to return will lock your whole operating system.
that should not sound pessimistic in any way. i'm just sharing some experience with that kind of stuff. there are great applications for ray-marching. get used to it and let the artist in you decide.