Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Makosuke

macrumors 604
Original poster
Aug 15, 2001
6,806
1,527
The Cool Part of CA, USA
Could some kind soul with a current-gen iPod Touch download the Linpack app and run a quick test with it to confirm what MFLOPS it's capable of? My 3GS-gen Touch maxes out at just a hair above 30Mflop/s, which means that the current one should do about 37.5, but I'm curious if that's what it actually gets.

Just to note, with a problem size of 200 over 50 runs (the default setting) I got an average of 26, max of 30; with a couple of runs at a problem size of 2000 (takes quite a while), I got a consistent hair above 30. At 500, for some reason, I only get about 21 average and max (I assume it has something to do with how the test works? Not a Linpack expert...).
 
Here are the results.

Problem Size/Number of Runs

200/50
Mflop/s: Max 38.67 Avg 32.92

2000/1
Mflop/s: Max 38.02

500/40
Mflop/s: Max 22.91 Avg 22.50

If you need any more runs tell me.
There really isn't a huge processor gap between the 3GS and 4 (gen processors, same between iPod touch and iPhone). Both have the SGX535 as GPU, and a similarly clocked CPU, both ARMv7 A8-Cortex, the 3GS/3 at 600MHz, and the A4 at 810MHz. You rarely hit the 800s in the 4th gen unless you're hardcore gaming anyway. :p

The difference is just the camera (for iPod) and the Gyro, and the screen.
I kinda sometimes regret buying the iPod 4th gen and rather get a 3GS as my "iPod", but the gyro... I want a Gyro... Haha.
 
Thanks much!

I for some reason thought the CPU was clocked at 750MHz, not 800, but those numbers are right in line with what I was expecting given that it uses the same CPU and has a ~25% clock advantage.

I do wonder why the results are so much worse with a problem size of 500. I assume it has something to do with the math not aligning bit-wise or something.
 
why lower performance on bigger data set

the answer is very simple. the app on the iphone does NOT block the data in the processor cache. thus as the data set gets bigger, more references are out of cache and thus the benchmark runs slower. also, when main memory is referenced more power is generally consumed compared to in cache data references

the above is generally thru.
 
I follow you on data caching, but if it was simply data set size, shouldn't the much larger problem size of 2000 be slower than, or at least the same speed as, 500?

Since 500 is consistently slow, while 2000 is consistently very fast, and 200 fluctuates between the two (that one is so small, and finishes so quickly, that there's probably a lot of overhead causing irregular results), it seems like there must be additionally some kind of data set alignment issue in terms of the cache (or RAM) size causing unnecessary fetches or swapping of some sort.

I suppose I could just read up on what exactly Linpack is doing to understand better myself.
 
Clock advantage won't necessarily yield better performance - remember, Linpack stresses the Floating Point Unit (FPU) in our CPU, not the CPU main core itself, so it won't make a big difference.

Both are ARMv7 Cortex-A8s, and AFAIK, it's the same FPU. What gives the Mflop/s advantage is probably just some faster RAM or things like that.

Though after playing a game (thus forcing the ARMv7 core running at 810MHz), I did get a 68.67 Mflop/s, problem size 200. Guess there is a difference at full clock...
 
Both are ARMv7 Cortex-A8s, and AFAIK, it's the same FPU. What gives the Mflop/s advantage is probably just some faster RAM or things like that.
I'd kind of assumed the FPU was clocked the same as the main CPU, which the ~30% increase in speed seems to bear out, but I suppose it's possible that's all coming from somewhere else in the process (pure RAM throughput advantage seems unlikely, though, given that the bus should be similar in both chips, and I can't imagine the Linpack routines being that constrained by memory throughput).

Though after playing a game (thus forcing the ARMv7 core running at 810MHz), I did get a 68.67 Mflop/s, problem size 200. Guess there is a difference at full clock...
Now that's really weird; I'd expect whatever the Linpack app is doing to be just as effective at bumping the clock to full speed as any game would be, but apparently that's not the case. Odder still, though, I tried a couple of different games (one 2D and one 3D), then switched immediately to Linpack on my 3GS, and didn't get any performance difference at all. I suppose the 4G could be doing more overclocking than the 3GS, but even then with only a 33% clock advantage at max in either case it shouldn't be THAT much faster than mine on the same benchmark.

Weird.
 
Indeed, I'm also interested in this. My iPod touch 2 scores max 28.23 and average 26.82 whilst my iPod touch 4 scores 22.57 and 22.50 respectively.

The iPod touch 4 has a 750MHz Cortex A8 processor and 256MB of LPDDR RAM. Why does my iPod touch 2 which has a ~533MHz ARM11 processor and 128MB of RAM?

EDIT: Just realised the iPod touch 2 is running iOS 4. That must be the reason. Perhaps iOS 5 is under clocking?
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.