I am confused about your reply. You answered yes to all 3 of my questions, but then in the sentence above you say the opposite. Did you mean to answer no to all 3 questsions?
Thanks for the links. I will look at them.
"Faster" is relative to a workload.
Code that is primarily limited by
- IO
- network
- constant reference to DRAM (ie does not cache well)
- unpredictable branches
Will not run much faster on a P core than an E core. For example a lot of OS code is in this category, and it makes sense to usually run OS code on the E core.
Apple continues to experiment to try to characterize what types of code run best on E cores. Theoretically you can predict what should happen, but you can't be quite sure till you experiment!
Obviously the experiments have shown that there is more of such code than was first guessed (hence first the M3 Pro with 6 E cores, now looks like everyone will get 6 E cores [and maybe 4 Pro gets 8 E cores, to see how well that works?])
And there are obvious cases where P is the winner, basically anything that consists of heavy-duty compute. So compiling, HPC, a JS-heavy web page, stuff like that.
Honestly no-one knows how this will play out. Apple, Intel. AMD, ARM, Qualcomm will all introduce different combinations of P vs E cores, and it's stupid to insist dogmatically that one of these combinations is the *right* one.
If I'm compiling, do I want 6 P and 6 E cores, or 4 P and 12 E cores? Could even depend on the patterns of my code (do I frequently modify .h files that are included a lot, or mostly modify a single .c file?)