Linked by Thom Holwerda on Mon 5th Dec 2011 22:48 UTC
PDAs, Cellphones, Wireless Cheap Android tablets are all over the place, and generally not any good. They often have resistive touch screens instead of capacitive ones, are slow, or have no access to the Android Market. For Ice Cream Sandwich, MIPS Technologies is trotting out its existing Honeycomb tablet - which, you guessed it, uses a MIPS processor - licensed to Ainovo. For some reason, that makes this $99 tablet with capacitive screen kind of interesting.
Thread beginning with comment 499367
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: MIPS!
by Alfman on Thu 8th Dec 2011 03:09 UTC in reply to "RE[3]: MIPS!"
Member since:


"Uh? MIPS has two version of integer operation: ADD/ADDU, SUB/SUBU (one which trap on overflow, one which doesn't and corresponds to modulo operation"

I wasn't really disagreeing with you.

"so the big thing here is that there is nearly no difference in performance between 'modulo' computations and 'trap on overflow' computations(*) which isn't the same with other ISA."

To be fair we'd need to actually test the performance differences on real CPUs. We cannot draw performance conclusions by counting instructions. For some x86 CPUs, jumps are "free" as long as they are predictable.

For example:

mov ecx, 0x00000000
mov eax, 0x00000000
add eax, 0x00000001
jo .overflow
loop .again

mov ecx, 0x00000000
mov eax, 0x00000000
add eax, 0x00000001
loop .again

mov ecx, 0x00000000
mov eax, 0x00000000
add eax, 0x00000001
jno .nooverflow
loop .again

On my 3GHz machine, 2^32 loops * 3 passes gives the following:

Test1=8.597570, 8.597259, 8.597007 -> 8.597278
Test2=8.596904, 8.599724, 8.598505 -> 8.598377
Test3=8.596864, 8.596893, 8.597207 -> 8.596988

Note that the addition of a jump instruction did not hurt the performance of the loop within a reasonable margin of error.

The same tests with unpredictable branching (adding 0x80000000 forces the branch to toggle each iteration).

Test1=10.694893, 10.742191, 10.759600 -> 10.732228
Test2=8.597308, 8.596457, 8.595678 -> 8.596481
Test3=10.862917, 10.777331, 10.680178 ->10.773475

So, the unpredictable branches hurt the performance, but I have to question whether a MIPS trap would do any better. Can MIPS do overflow checking without a trap? So long as the overflow is exceptional behaviour, I think we should both agree from these tests that the extra jump won't make any significant difference.

Now maybe it's true an inordinate amount of silicon has gone to branch prediction in the x86, which may have theoretically gone to better use in the MIPS, but you can't deny the x86 seems to do a decent job in this microbenchmark. Unfortunately I don't have a MIPS processor to test with.

Reply Parent Score: 2