#define f0() x++
#define f1() x++
#define f2() x++
#define f3() x++
#define f4() x++

On the other hand, it would be extremely useful (IMHO) to have a compiler option that would suggest optimizations, perhaps using the same format as you presented, from which I could choose to code manually. I could then compile without optimization on various platforms and compilers (and versions) and reasonably expect the same results and be not subjected to unpredictable optimizations.

What does this all mean? It means the fastest way to write to write to screen was in an ascending stream of writes of maximal width.
You want an ascending stream of writes to utilize the implicit address increment. (This means that the fancy sort of blit patterns might appear to make sense when decoding certain types of data, eg interlaced images, or images comprised of square tiles, should not be used — just start at the top and proceed in raster order).
You want as wide a write as possible to keep the queue between the memory bus and the PCI bus as full as possible, which in turn means the bridge chip is most likely to keep shoveling data to PCI rather than deciding there has been enough of a break between writes that its time for a new address to be sent.

The intel bridge chips of the time (and of course still) provided write combining, so that no matter how you wrote your data to the PCI/AGP the chip would glom it into the largest possible units and then send these optimally. This meant that it didn’t much matter on PCs if you blitted using bytes, shorts, doubles, SSE or anything else. Those chipsets also seemed to allow for the maximal possible run length of data to PCI before resending an address. I could never get exact details on what the mac chips did because Apple, in their constant attempt to provide the best possible developer experience, never released the details, but the mac chips seemed to be operating on some sort of counter based system, so that after N memory transactions on the memory bus side they would start a new PCI transaction. (It’s possible that they were sufficiently lame that N was, in this case, 1 — so a word write would result in a PCI addr+data transaction, a double write would give us addr+2data, and VMX addr+4data — meanwhile Intel chips were happily doing addr+ (godawful number of) data, even when fed a stream of bytes! Remember this, kids, when you think that Apple could so so much better a job going to using its own chipsets for either Macs or iOS devices.)

In other words at that time, it was ALL about how you write the data — how you read/generate the data was a second order effect.
It looks to me like CoreGraphics is doing the right thing (for some value of “right”) at 128×128, but not at larger sizes, and that this is a bug. The right thing is presumably using doubles to read and write the data. Possibly the 256 and 512 images were not 8-aligned, and so CoreGraphics fell back to UINT32 reads and writes. (Though this is a bug — the correct thing in that case would be to use misaligned double reads, which will take a fairly minor hit on the memory read side, and aligned double writes.) Of course the larger right thing to do would be to update CoreGraphics to use VMX (again with unaligned reads handled using the two reads + permute VMX jiggery pokery), and VMX aligned writes. I don’t know exactly what stage of OSX this was at, but let’s hope that was done before the switch to Intel and then 10.6 made PPC optimizations irrelevant.

I’m out of this game now, so I don’t know the characteristics of PCI-e, but I suspect variants of the above ideas remain valid for iOS devices. Sadly Apple remains stuck in its same old ways of not providing developers with rich hardware specifications which describe these sorts of details and thereby allow one to write optimal code for the hardware.

=======================

BTW is there a bug in your pi tracking code? I wrote some quick Mathematica:
Prime[Range[num]] // (#^2 – 1)/#^2 & // FoldList[Times, 1, #] & // Sqrt[6/#] & // N

to track how pi is approximated as the number of primes increases and we get something like
{2.44949, 2.82843, 3., 3.06186, 3.09359, 3.10646, 3.11569, 3.12109,
3.12542, 3.12838, 3.13024, 3.13187, 3.13302, 3.13395, 3.1348,
3.13551, 3.13607, 3.13652, 3.13694, 3.13729, 3.1376, 3.13789,
3.13814, 3.13837, 3.13857, 3.13874, 3.13889, 3.13904, 3.13918, … 3.14119 (at num primes=100)}
Note specifically that the number is always below pi.

I then ran a simulation of the idea — generate 1000,000 random integers between 0 and 10^35, test if they were relatively prime or not, yadda yadda,
Sum[ Boole@CoprimeQ[RandomInteger[num2], RandomInteger[num2]], {i, num1}] // Sqrt[num1*6/#] & // N

(which took a few seconds — Mathematica plus modern CPUs are a pretty amazing combination)
and got on three successive runs 3.14276, 3.14127 and 3.14271
Obviously you have rather fewer than 1000,000 samples; but even when I dropped to 1000 samples I was getting values like 3.18 or 3.15 — nothing as extreme as 3.28.
It seems like either people are deliberately gaming the system with the numbers they provide (so they are not truly random) or you have a bug in your code. It might be interesting to do the calculations again with numbers that are slightly less gamed — using values input by different people against each other, or adding or subtracting one from the inputs.

Another problem was for some users that did lots of benchmarking in the same process. The program allocates a small amount of memory each time around, but in their case this was slightly larger each time. This eventually led to an Out of Memory error, even though all memory was released after each round in the benchmark!