My CPU version(C/C++) of Lightcuts (http://portal.acm.org/citation.cfm?id=1073318) has been done right now. It rocks, indeed.
(Testing Platform: Intel Core 2 Quad CPU Q6700 @2.66 GHz)
My initial testing sample: 3 venus model (1418 triangles for each, total 4254), and 483 Virtual Point Lights, the original rendering time withOUT Lightcuts is 2505.08s, while it decreases to 1303.61s – that is about 92% speed-up, nearly 100% (about 29% VPL are only important enough, that is, 71% of the non-important VPL have been cut)! Also according to the paper, Lightcuts offers a “strong sub-linear complexity”!
However, it also suffers from some limitations, as the most techniques. There are two steps of Lightcuts processing: 1. traverse the binary light tree and select the right ones; 2. evaluate pixel color linearly using the ones selected from Step 1. So it assumes that intersection computation should be much more expensive than light tree traversal operation. Or, more VPL with simple geometry will emphasize the tree traversal time cost. For example, a scene of 9 simple spheres, 5490 VPLs may even slower than the original linear algorithm. (287.88s for original algorithm, while 345.324s for Lightcuts version, in which 241.378s for tree traversal)
There's some trick when coding traversal piece: according to the paper, the redundance of the light tree is quite obvious, and this gives a perfect scenario for Dynamic Programming. This saves a lot of unnecessary relevance factor computation I believe.
Now check out the two images: 
The former one is the image generated withOUT Lightcuts, and the latter one is from Lightcuts. No visual differences!