Aren't you really benchmarking the time it takes to poll for events, draw the circle, draw a 320x30 filled rectangle, do a bunch of TTF renderings, blit a bunch of text glyphs, flip the screen (which involves a full on 320x240 blit because it's an SWSURFACE), and a bunch of other little things like calls to rand() and modulos? I think of all those things drawing the circle would take nearly the least time. For something that's much closer to what you want to find out you should time how long it takes to draw many circles, say 1000, then do all that other stuff/print the results.
By the way, that SDL version w/o tearing is most likely waiting for vsync when you do SDL_Flip. So you're already limiting yourself to one circle per frame at most, hence why your results there are even slower. I believe GP2X defaults to something inbetween 50 and 60Hz so there you have it. Okay, I can see you posted this in the Wiz section even though the code references GP2X, but the default for SOME firmwares on Wiz is similar.
Okay, now about the circles themselves. I don't know the inner workings of filledCircleRGBA, but unless you want to draw a bunch of very small circles you're going to be limited by linefills, not the edge conversion of the circles, which can be done really quickly using Bresenham's circle algorithm (LUT would not be needed here). For this to perform at its best, SDL is going to have to have an optimized 32bit color -> 16bit fill rect (or fill line?) implementation that performs blending. The right way to do this is to convert the 32bit color into a 16bit one and multiply its components by the alpha before entering the fill, then for each pixel multiply the components by (1 - alpha) and add/repack the two. If this is done intelligently it shouldn't be that slow computation-wise, what's going to get you are the cacheline loads.
See, the thing is, a 320x240x16bpp framebuffer takes 320 * 240 * 2 bytes, or 150KB. That's way more than the 16KB of data cache the GP2X/Wiz ARM9 has, and you end up loading a cache line every time, unless your circle overlaps the last 16KB of the last one. For reference, 16KB / 320 / 2 = 25.6 lines. That's what you can store in the cache.
If you don't have alpha blending then it's entirely possible to draw circles limited to bus speed. Thanks to the writebuffer on the ARM9, you'll be able to compute the next pixel while you're drawing the current, but even that takes almost no time when you aren't blending. The bus speed on GP2X is 100MHz @ 32bits Wiz is 133MHz * 16bits * 2, so 400MB/sec and 533MB/sec. You need two bytes per pixel, so you can draw 200MPixel/s or 266MPixel/sec. Naturally you need some time for other things. Since you're not drawing straight to the framebuffer you'll need a lot of time to blit the screen because you have to do a cache load and write for each cache line's worth of pixels. So in that way it's much better to get HW surfaces and write straight to the framebuffer, using double buffering to flip. I don't know if SDL on GP2X/Wiz supports this. I do it using straight hardware manipulation.
So, if you draw opaque circles you can go at bus speed and if you draw transparent ones.. well, it's much worse, because cacheline loads aren't fast on either platform, especially Wiz. So it's worse than even half speed. But there's actually a way around this.
Let's say that you can schedule to draw N circles ahead of time, possibly drawing other stuff inbetween. If you do this then you can batch the draw operations of all of these things per scanline or per groups of scanlines (let's say 8, maybe 16 of them). What that means is that the read-modify-write cycles take place inside the cache, then get written back via the write buffer with no reads, preferably straight to the framebuffer. Now not only are your alpha blits much faster (especially if they're very well optimized) but you also don't have to write to the write buffer multiple times for pixels that overlap each other. So your worst case performance on bus usage is bounded, with the in-CPU usage being what grows. There is, however, a fixed penalty of having to copy those lines to the framebuffer, but if you're doing alpha stuff or have a ton of overdraw then it's definitely worth it.
