Modern Combat 5 Playing

Trying out another popular high-end game, we have a look at Modern Combat 5. This one of many first-person shooters on Android.

The little cluster looks to behave extremely similar to what we saw in Real Racing 3: Three larger threads keep 3 of the cluster's CPU at relatively busy duty-cycles while we see some limited activity on the 4th core.

The big cluster also seems to behave in a similar fashion. One big main thread causes the bulk of the load while we only have occasional small bursts when threads get migrated onto the big cluster. This time we see a more variable load both in terms of requency and rq-depth instead of the flat-line that could be observed in Real Racing 3. 

One interesting behaviour caught in this log was how the main big thread got moved around from CPU6 to CPU4 and then again to CPU5 on the 33s mark in the log.

Even though the total rq-depth might be a bit misleading here while it's showing an average of around 2.5, we can see that in the individual per-CPU runqueues we have 4 major threads at work. Again this is a case of using parallelization for the sake of power efficiency instead of performance. The 3 smaller threads on the little cores could have well been handled by a single larger CPU at higher frequency, but it wouldn't have been nearly as power efficient as spreading them onto the smaller cores.

Games: Real Racing 3 Playing Analysis & Conclusion


View All Comments

  • modulusshift - Tuesday, September 1, 2015 - link

    Heck yes. And of course I'm interested if anything like this is even remotely possible for Apple hardware, though likely it would require jailbreaks, at least. Reply
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    Unfortunately basically none of the metrics measured here would be possible to extract from an iOS device. Reply
  • TylerGrunter - Tuesday, September 1, 2015 - link

    Add one more vote for the follow up with synthetics.
    I would also want to see how the multitasking compares with the Snapdragons as they use the different frequency and voltage planes per core instead of the big.LITTLE.
    But I guess that would be better to see with the SD 820, as the 810 uses big.LITTLE. Consider it a request for when it comes!
  • tuxRoller - Wednesday, September 2, 2015 - link

    Big.little can use multiple planes for either cluster. The issue is purely implementation, tmk. Reply
  • TylerGrunter - Wednesday, September 2, 2015 - link

    big.LITTLE can be use different planes for each cluster but same for all cores in each cluster, Qualcomm SoCs can use different planes for each core, that's the difference and it's a big one.
    I'm not sure that can be done in big.LITTLE.
  • tuxRoller - Friday, September 4, 2015 - link

    I remember that but that doesn't say that big.LITTLE can't keep each core on its own power plane just that the implementations haven't. Reply
  • soccerballtux - Tuesday, September 1, 2015 - link

    to balance everything out-- meh, that doesn't interest me. most of the time I'm concerned with battery life and every-day performance. Android isn't a huge gaming device so absolute performance doesn't interest me. Reply
  • porphyr - Tuesday, September 1, 2015 - link

    Please do! Reply
  • ppi - Tuesday, September 1, 2015 - link

    Go ahead. This is one of the most interesting performance digging on this site since the random-write speeds on SSDs. Reply
  • jospoortvliet - Friday, September 4, 2015 - link

    Yes, this was an awesome and interesting read. Reply

Log in

Don't have an account? Sign up now