First the good news: A hacker has figured out how to make Samsung’s latest smartphone even more powerful, by convincing it to run all 8 cores at once and overclocking those cores for good measure.
Now the bad news: The chip generated enough heat to cook itself and the phone is basically dead.
So don’t try this yourself unless you know what you’re doing, are willing to risk breaking your device, or both.
The Samsung Galaxy S4 is one of the first devices to ship with Samsung’s Exynos 5 octa-core processor. It has 4 ARM Cortex-A15 high-performance CPU cores and 4 lower-power ARM Cortex-A7 cores. But they usually don’t all run at the same time.
Instead, the Cortex-A15 components kick in when you need a performance boost, but the power-saving Cortex-A7 cores handle basic tasks in order to provide longer battery life.
Android Central forum member DSWR reports that he was able to trick the phone into thinking that it was in power saving mode so that the Cortex-A7 cores would run at the same time as the higher-performance Cortex-A15 cores. He also tweaked things so that both sets of processor cores would run at the same frequency.
Theoretically it might be possible to run all 8 cores without overheating, but apparently overclocking the system to run at 2.8 GHz and running it for an hour is a pretty good way to end up with a paperweight.
Well winter is coming, a nice portable leg warmer might be nice for this time of the year, great thinking samsung and even greater thinking mr hacker
The 2.8GHz might explain the cooking part more than the 8 cores….
that man is fucking crazy . !! 2.8GHZ for god sake why do you want such a power on a phone ? 2.8×8 = 22.4GHZ of proccessing power . thats the equivalent of a i7 or oven greater LOL . with only 2Gigs of ram? such a waste ..
Never do multiplication on cores….
I salute you sir.
wth! why? i udnerclaocked my s4 to 1GHZ and still runs all of games like GTA:VC or MC4 meltdown smooooooth! no lags at all! even think more stable! im still looking way to udnerclaock the GPU and also make sure its runing on low power cores!
Watercooling add on back cover?
So how long before NSA uses this to set someones pants on fire?
Here, have my like.. and this random plate of fried eggs… You sir are brilliant. They are bound to give me a promotion now <3
Wow that’s nuts. I was thinking maybe run them all at 1 GHz, but certainly not 2.8. What would be interesting is if you could trick the A7 cores to come on when the system needed a boost in processing power so that all 8 ran when under high load for example.
do it! its freaking cold now and still freaking fast/smooth havent tryed benchmarks but who cares! when tehres no game use that power why should i even overclock it? im still looking how to underclaock The GPU!
I salute this brave and foolish pioneer!
Now you know why Sammy doesn’t do it.
Could be other issues too, big.LITTLE works with software to cover the differences between A15 and A7 processors… they’re not the same and thus how the software handles them has to account for the differences but running everything at once could confuse the software that normally helps deal with the differences… along with which quad core set gets a particular thread could also effect efficiency as the A15s are better for performance and both quad cores won’t perform equally…
The architecture and feature set of the Cortex-A7 processor is identical to the Cortex-A15 processor. The difference is that the A7 processor takes up significantly less die area than the A15 and its microarchitecture is focused on providing optimum energy efficiency. To clarify, the A7 and the A15 are actually fully instruction set binary-compatible with each other.
Apparently the A15 cores on the Exynos 5 Octa occupy 5x the die area as the A7 cores and consume nearly 6x the power.
Incorrect, the Cortex A7 is compliant with A15, in that they can work together under big.LITTLE, but it’s not exactly the same!
Cortex A7 is for example an In Order Processing SoC and optimized to be more power efficient than Cortex A8. While A15 is Out Of Order and optimized for better performance!
This is why they even bother with the big.LITTLE solution otherwise there’s no point combining them if they’re the same!
Not incorrect. Cut and paste from https://www.arm.com/products/processors/cortex-a/cortex-a7.php
“The architecture and feature set of the Cortex-A7 processor are identical to the Cortex-A15 processor, with differences in the Cortex-A7 processor’s microarchitecture focused on providing optimum energy efficiency, enabling the two processors to operate in tandem in a big.LITTLE configuration to provide the ultimate combination of high-performance with ultra-low power consumption.”
Sorry but it is incorrect, the Cortex A7 is based on similar core architecture, based on the same ARMv7A architecture including Virtualization and Large Physical Address Extensions, but they are different in that the A7 is an In Order Prcoessor like the Cortex A8 and not an Out Of Order Processor like the A15, which is one of the reasons why it’s more energy efficient because Out Of Order processing is more power consuming but is also one of the reasons why the Cortex A15 is a better processor!
The Cortex A15 is specifically a 15 stage integer/17–25 stage floating point pipeline, with out-of-order speculative issue 3-way superscalar execution pipeline.
While the Cortex A7 is specifically a Partial dual-issue, in-order microarchitecture with an 8 stage pipeline.
So don’t let them being based on the same core technology confuse you into thinking they are actually the same!
That’s like comparing Windows desktop OS with Windows Phone OS and saying just because they use the same kernel that they’re the same when they’re very different OS and you can’t just run the same apps on both!
Also, big.LITTLE itself specifically works by translating the calls to each type of processor differently and masking the differences from the OS!
Besides, A7 and A15 specifically have different processor efficiencies and that means they will get through data processing at different rates and anything that can interfere with allowing big.LITTLE to differentiate between both core sets will start messing up data flow consistency and start generating errors…
No, big.LITTLE does not mask the differences from the OS as there are no software visible differences to mask. There is nothing to translate.
Sorry but it does!
A7 and A15 are only the same on the core level but from that point up they are very different and big.LITTLE has to mask the differences to the OS!
This is how it works!
Really, why do you think they describe it as making it “Transparent” to the Applications and Middleware? Why do you think they need a software aspect to big.LITTLE at all? Why do you think they call it “big.LITTLE” if they were identical to begin with?
You should try researching how it actually works rather than just reading the overly simplified promotional materials and accepting them at face value when there’s so much more to it!
What part of “the A7 and the A15 are actually fully instruction set binary-compatible with each other” don’t you understand? I never said they were absolutely identical, just that they have an architecture and feature set in common. The changes big.LITTLE requires of the OS have nothing to do with software transparency and everything to do with power efficiency and performance. If you don’t care about either of those things you don’t have to alter the OS as standard SMP support will still work.
Maybe you should try doing some research? Try ARM’s big.LITTLE microsite to start with: https://www.thinkbiglittle.com Quoted from there: “Transparent to apps, middleware and most parts of the operating system, so today’s software will work seamlessly.”, i.e. software transparency is inherently part of big.LITTLE.
No, big.LITTLE does mask what it does from the application and middleware… and it does treat the A7 differently from the A15.
It’s part of why it is called big.LITTLE in the first place!
Like dynamic voltage clocking, big.LITTLE starts on the low end of the A7 and then passes it to the A15 at the A7’s peak! Then reverses back on the way down.
While operating all cores at the same time means prioritizing data threads and it can’t do that if it’s treating them the same.
Point remains that they are not the same where it counts for processing and performance. A15 is more efficient for processing, so it has to be treated differently for things like timing, which is needed to keep data flow consistent and not corrupted or slowed down!
This is like having two different power motors on the same AC power but they still have to be treated differently because they don’t perform the same!
And this is more complicated than just power efficiency!
The processor switching you describe is governed by the operating system’s scheduler which needs to be big.LITTLE aware in order to make sensible scheduling decisions when running on big.LITTLE hardware. You’re implying that the hardware itself does this, which is completely wrong.
I’m going to stop replying to you as it’s quite clear you really don’t know what you’re talking about.
The PDF at https://www.linaro.org/documents/download/77ee402977299bd4545bf7027e3175284fc3128188e4d is an interesting read. Maybe you’ll start to understand how big.LITTLE actually works if you study it.
https://www.linaro.org/documents/download/77ee402977299bd4545bf7027e3175284fc3128188e4d
So the part about “Why is big.LITTLE different from SMP?” went completely over your head?
Cause it only backs what I already told you!
If these were truly architecturally the same throughout the processor then this part…
“Contrary to SMP, it matters where a task is scheduled.”
Wouldn’t be there as it would be treated as a SMP if they were the same throughout and there were no significant differences!
So again, you fail to understand what you’re discussing!
Last comment from me. Are you actually reading what I write? As I stated in a previous post you can treat big.LITTLE as though it was SMP if you don’t care about power efficiency or performance. You can even use all eight cores simultaneously as the PDF I linked to makes clear. But what runs where is entirely determined in software, not in hardware as you seem to think.
Are you reading what you link?
As the pdf document states…
“Contrary to SMP, it matters where a task is scheduled.”
Stop glossing over the details that clearly show you to be wrong!
big.LITTLE is not the same as SMP… it only allows the two core sets to be used similarly to a SMP but not in the exact same way… otherwise there would be no listed differences!
But you can’t really treat different processors the same and like it or not these are different processors… optimized for different processor efficiencies and power consumption!
So big.LITTLE software has to compensate and manage the differences!
Skimmed through this spirited debate (a little late to the party). I think I see the discrepancy here; Both cores implement the same ‘Architecture’ (i.e. ARMv7A), however their ‘Microarchitecture’ is completely different (hence the larger area, higher power consumption, etc.). This means both cores can run all of the same instructions (architecture), but the internal mechanisms to execute the instructions is different (microarchitecture). So you both are mostly correct, however the terminology is off in places.
No, I’m implying the software needs to handle big.LITTLE hardware precisely because the cores are not the same!
And it’s only clear that you’re the only one who doesn’t know what they’re talking about by claiming they’re the same processors and ignoring all the obvious things that make them different!
Let’s make this abundantly clear, from the moment I pointed out that Cortex A7 is a In Order Processor and A15 is a Out Of Order Processor it showed without a doubt that the architecture between the two are not the same!
They are designed to process data very different and the underlying technology doesn’t change this!
Like it or not big.LITTLE works by combining different processors to cover a larger spectrum of operations and thus achieve a higher level of efficiency by using the processor best optimized for a particular processing job vs another processor that is optimized to handle a different range of processing better.
The only thing identical is the base building blocks of their architecture, but like two buildings made from bricks, it doesn’t by any means mean they were designed the same!
While for the software it’s not as simple as just handing off what processor is optimized for a specific work load because big.LITTLE also allows both core sets to be used at the same time.
So it also has to intelligently split and recombine the work load between the two processor sets and do so in such a way as to maintain efficiency as the opposite can easily happen as well… Like sending a high work load to the A7 instead of the A15 and thus forcing the A15 to have to wait till the A7 is done before recombining the data and continuing.
The fact big.LITTLE requires software to help it work shows how complex it really is and that it has to deal with the differences in the processors in order to make it work right!
Otherwise, if they were really the same then they could be treated just like normal multiple cores but that is clearly not the case and why they are making the point in this article that they’re coming out with actual Octo Cores instead of a combination of two quads!
Really, even in your first post you failed to note they included the fact there are differences!
Just because the core architecture is based on the same ARMv7A base doesn’t make them the same!
Since they’re clearly not designed to process in the same way!
In Order Processing is not the same architectural implementation of ARMv7A as Out Of Order Processing, along with the many other differences that make the A7 better optimized for power efficiency and the A15 better at processor efficiency for higher performance range!
These are all hardware differences and big.LITTLE has to account for them in order to juggle work between the different processor cores and maximize efficiency!