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.

If you try the same on an ARM7 the method may be still useful.

On the other hand, embedded applications are usually restricted to a certain executable size and suffer from boot-up performance problems, so we usually do bitmap serialization instead of compilation. Which is an altogether different technique, so my comment may not be very informative.

Back in the old days of DOS I wrote a transparent sprite blitter. My main concern were the speed and the fact that the sprites could be partially outside of the screen. So I had a mask that was not compressed, but contained the RLE values of the mask. i.e: ALLLLLLL. Where the bit A determined if the run is transparent or not, and the bits L determined the length of the run.

Also as noted above, using the FPU is the way to go if all you have is 16 or 32 bits registers otherwise. Which makes me wonder what kind of CPU you have since my 21yo Atari has 16 32bits registers.

You should check :

– http://www.azillionmonkeys.com/qed/blockcopy.html
– http://www.azillionmonkeys.com/qed/asmexample.html (esp: Sprite data copying)

They are aimed at x86 processors but they provide actual code with annotations of which pipeline will execute which instructions, and

There is a nice S/N here !

just curious: Do you have an ICBM yet? I’d really be interested in hearing whether it works better for them.

Cheers,
– Uli

I’ve come to realize that some of the techniques I’ve forgotten over the years really are best forgotten…

-jcr