Oct-Core phones?


Fzero

Advanced Member
Joined
Mar 9, 2010
Messages
4,702
seen this, sounds like could be a bit if a beast eh


m.techradar.com/news/phone-and-communications/mobile-phones/eight-core-samsung-galaxy-s4-on-horizon--1114243
 
SOoo...


1 core for adware


1 core for logging / tracking


1 core for glossy animations


1 core for decoding supa-doopa-hi-res touch-sensing


1 core for continuously rendering facebook pages


1 core for supporting all that java


1 core for playing angry birds


1 core for background tasks, and keeping track of all he radios


note that four of the core are nowhere near as powerful as the others


---


(can you tell I'm not in a good mood today? - maybe I should shut up)


This could be good, providing stuff mulithreads well
 
Last edited by a moderator:
Calm down folks, It's really just a high powered quad core with a lower powered quad core that kicks in at low usage times to save power. It makes sense. It's actually a power saving direction ie I don't think you can utilise all 8 cores at once.
 
ARM's big.LITTLE does in fact let you use all of the cores at once, but it's still intended first and foremost as a power saving mechanism and not a bid for more concurrency. Being able to run them simultaneously will probably be used at least as a latency optimization when switching (keep both on just for a while just to give the other time to get ready). The main point is no one would dream of putting 8 homogeneous CPU cores on an SoC this generation.


You shouldn't really let yourself get overwhelmed with core counts.. the number by itself doesn't say anything without considering the nature of the cores. Those Cortex-A7s are small enough that the cluster doesn't add too much on its own. I would however still expect to see some dual A15 + quad A7 arrangements at some point.


Current Exynos 5 devices don't have the ability to power the cores independently. I don't know yet if this is a limitation of those devices, the SoC, or even the Cortex-A15 core - from what I've heard so far I doubt the SoC can accommodate it. That'd mean you have to run both cores at the same clock speed and voltage, which is a disadvantage compared to fully asynchronous core DVFS. Having big.LITTLE side-steps this somewhat, since it's guaranteed you can run the A15 and A7 clusters at different clocks and voltages, at the very least. So you might see common scenarios where one or more A7s are powered up then a single A15 core is powered and frequency scaled with a single demanding thread, and the other A15 cores are only brought up if there are a lot of demanding threads. One should see much better power consumption from this sort of arrangement.
 
I love overkill , but pumpkin seeeeeds 8 cores ? WITH a 1080p screen ? I don't think my tv does 1080p , come to think of it we don't even own an hdmi cable .
 
I'm not advocating silly core usage, but in realistic terms:


Core 1: the 'main thread' processing the main game stuff


Core 2: the 'render thread' processing the queue of stuff to be sent to the GPU


Core 3: the 'loading thread' which does the logic for loading in new sections, for instance fixing up pointers, setting up structures, registering systems, etc.


Core 4: the 'decompression thread' which decompresses data in memory


Core 5: the 'file thread' which handles loading from file into memory, decoupled from decompression, as these can be run in parallel


Core 6: the 'music thread' which loads into memory via the 'file thread' and then decompresses and passes to audio system


Core 7: the 'online thread' which handles various online acitivies


Core 8: the 'system thread' which handles any system events that must be processed with high priority


Core 9: etc.


I'm not saying all the threads above would always be working at the same time, and that they would all need to be on separate cores necessarily, but all I wanted to get at is when working with larger games, you can use up threads relatively quickly (whether this is through bad code/design is another argument). I have certainly seem multiple high profile console games that are using all the main cores available on Xbox 360/PS3 and are finding themselves CPU bound (a full rewrite could alleviate this, but when it is a code base built over over years/decades this isn't always so possible).


It isn't always a highly appreciated view, but I think having as many hardware resources available as possible and allowing the developer to write code as fast as possible (without worrying too much about optimisation) often results in more cool stuff for the end user to actually play, rather than the developer spending time optimizing around sensible hardware. Write code that is easy to understand, maintain, debug, YES, YES, YES, spend time making said code optimal, hmm, would rather just have more powerful hardware!


Just my opinion of course!
 
Back
Top