You say to Oracle, Yeah T4 SPARC64 RISC chips look nice. But coding against non-symetric asychronous cores is hard.
Oracle counters, Yup, that is why we wrote /maintain the Java JIT that does that for you!.
Now Google is selling ARMv8 with A57 non-symetric asynchronous RISC chips, which you optimize with Java and we do this song and dance over again.
Intel, Nvidia, AMD (formerly ATI) solved this problem a long time ago just by putting the binary logic between the scalar processors and only exposing 1 scheduler to pipeline these smaller weaker cores but make them pretend to be a single processor to the OS/User.
The paired relationship between the phone and watch could probably benefit from either side being able to do a little computation and coordination without having to spin up the big cores.
There, of course, I'd expect Apple to make it developers' problem to designate which thread(s) could operate in a limited environment.
This makes a lot of sense. LLVM byte code is pretty damn portable. It just makes a lot more sense since you can maintain PPC/x64/ARMv8 support of a binary file. Yet have native performance in all environments.
What I'd consider more likely is on install you compile to native for both High Power/Low Power chips. It might get funky from an OS standpoint but theoretically you could dyanmically switch between binaries if they were compiled to do that. Its really just dynamic dispatch in Kernel Space.
Less so when using task queues, I guess.
But… the T3 is symmetric? And not from the 90s, it was launched in 2010?
> Intel, Nvidia, AMD (formerly ATI) solved this problem a long time ago just by putting the binary logic between the scalar processors and only exposing 1 scheduler to pipeline these smaller weaker cores but make them pretend to be a single processor to the OS/User.
That's the original use case for big.LITTLE actually, either cluster-switching between the low-power (A7/A53) cluster and the high-power (A15/A57) cluster, or presenting groups of low power and high-power cores (1/1, 2/1) as a single virtual core.
I was thinking of the T4 and I had my dates wrong. T4 does weird dynamic threading internally. So it can be Out of Order and In Order at the same time. Depending on the number of execution units you need.
Furthermore you illistrate that Intel was again ahead. Having 6 core scalar galaxy hiding behind a virtual processor. You can just change that to a 3 and low-and-behold 50% less power consumption!
Am I missing something? That sounds like it means the decade beginning in 2010 ... which we're still only half-way through.
Do you mean something like "in 2011-2012"?
[EDITED to add: Oh, wait, looking at the comments I think I see what happened. You already wrote "already fought in the 1990s", then someone pointed out that the thing you were talking about was a lot later, and then you changed the date. I'm afraid the result is a pretty odd paragraph, talking about a decade still in progress as if it's ancient history.]
For a mobile device, having multiple smaller cores going at lower voltage may be more beneficial than one big core screaming ahead at higher voltage. This because most devices these days have all sorts of stuff running in the background.
Yeah i know Intel is talking big about race to idle. But my main concern there is that given the number of background tasks etc, idle will never be reached in a meaningful sense.
Notice how it sounds identical? We've had this debate before.
You can argue phone's have stricter power requirements then server farms. But power is the primary expense of server farms. Much like battery life is a big selling point of phones.
Its the same debate. Power is king, always has been.
It makes alot of sense when you think about it. Android has some good clues about what a process is responsible for.
It would be quite interessting to have all the background daemons doing mostly I/O being scheduled on a light core and the heavy ones (UI -> GPU, whatever) on more robust ones.
This is a cargo cult mentality. You're expecting a company to get it right. Simply because they will.
>Android has some good clues about what a process is responsible for.
This is actually already a thing on servers. Or will maintained servers. You set core affinity of running process to the same core that handles the interupts for that task to preserve better cache locality when it comes to handling system calls.
People keep telling me Phones/Desktops/Servers are fundamentally different, but it always seems like they're trying to solve the same problems.
Servers are a different story, we are talking mobile systems here.
> This is a cargo cult mentality. You're expecting a company to get it right. Simply because they will.
Do you want to bet that Google will totally ruin their mobile platform by messing up big time with a new architecture ?
Ok I'm in, how much you got ? :)
I'm talking about the similiarities between the two, and how one can solve the others problems. Creating arbitary divides based on name alone is the core crux the problem I'm attempting to address.
Using processor neutral binary formats was always a thing with them.
I hope Qualcomm gets back to 4-core designs with a custom ARM v8 optimized implementation (2.5-3GHz with independent CPU core frequency and voltage dynamic control).
P.S. "Snapdragon --Better Cores, Not More Cores" video: https://www.youtube.com/watch?v=qdauwqhmsas
Then marketing wants new features to sell to consumers so you increase the core count which is one way of making the phone faster but at the same time you drain the battery a lot faster.
And making a phone faster will almost neccesarily drain the battery faster. The important metric is task energy where you multiply the time it takes a phone to do some task by the power it consumes while doing it to figure out how much energy was needed overall to do it. By that metric adding more cores usually has less of a negative effect than speeding up a phone by upping the clock speed or the size of the OoO structures.