anonconformist

hammeroftruth said:

One of the most important things to remember is now Apple controls their own processors in the Macintosh which was something they could never do. They always relied on Motorola, IBM and Intel. Now they have the freedom to design their own chips and not have to make severe modifications for heat and power requirements. 

Intel has its own problems with consumer perceptions that they would be better off using an AMD cpu than Intel. Too many years of celeron and budget Intel cpus have turned off the bargain shoppers. Sure, high end users still use Intel, but if you look at history, all of the high end cpus like Dec Alpha and MIPS and RISC were all replaced eventually by cheaper cpus by Intel.  Now Intel could be a victim of its own playbook. It all depends on what Microsoft and Linux distros do in the future. 

Once SoftBank sells off ARM, whoever buys it could put a severe hurt on Intel, that is, as long as Microsoft allows it. They were one of the driving forces to propel Intel to the top. They killed off PPC versions of Windows because Intel asked them to back in the 90s. 

Your extraordinary claim regarding Microsoft killing off the PPC version of Windows at Intel’s request requires extraordinary proof: I call total BS on that claim.

The ugly truth of the matter is Windows has never flourished commercially on any platform that didn’t have sales numbers for number of computers sold and thus operating systems sales seats.  Only the more recent versions of the client for ARM processors has even enough users to justify the effort, and that’s with Microsoft selling the ARM-based devices to ensure there are enough of them.  Also, don’t forget the version of Xbox that was its own PPC creature.

The PPC machines with the largest numbers of seats, bar none, have been Macintoshes and their clones, and compared to PC sales of the time, they were a rounding error for units.  Apple didn’t want Windows running on them, either.  The rest of the PPC machines were expensive workstations/servers and more commonly bundled with expensive UNIX variants.  Somewhere in that range in the late 90s and early 2000s was the BeBox variants.  Again, a rounding error of PPC machines existed to run any version of Windows on, and if you don’t have native code to execute on them (again, chicken/egg numbers issue) and either emulation is extremely slow or doesn’t exist, why would you buy them?

Windows versions didn’t stop being produced due to your unfounded conspiracy theory, but rather fell victim to market forces.

y2an said:

blastdoor said:
… There's no way Intel wins on equivalent process because x86 requires much higher clock speeds (and therefore voltage) to beat Apple's core design on single thread performance.

Lower voltages allow higher clock speeds. 

Show us you know nothing about how electronics work without telling us you know nothing about electronics works.

Wait, you already did!

Lower power usage enable pushing up higher clock speeds by not exceeding what can be done without melting: voltage is only one component in that, and isn’t the most important one, total current is.  Current is a result of how many things are being powered during execution.  You could make the voltage much higher and it may be possible to design things such that it still uses less power, which is voltage times current, and in an electronic device that’s not DC, there are many interesting things that affect power usage and efficiency, including voltage required, such as operating frequency.  RC time constants factor heavily into processing speed, as well as any inductive factors.  The faster you want values to become stable with RC time constants, the higher the voltage needs to be to drive it to a stable-enough state, because the C part of that (capacitors, capacitance) take time to charge to a given voltage, as capacitance resists the change in voltage.  Meanwhile, the resistive properties don’t change, resulting in power usage going up much faster, with a lot more of the power dissipated in the form of waste heat.

As such, the key to being able to run with the least power and thus the least voltage for a given arbitrary clock speed (which varies from one processor to another and isn’t directly comparable) is to keep as little as possible of the circuitry from being powered on and changing state, because changing of state always requires more power by its nature in this situation.

Other than the more moving parts issue is the question of what the user wants and why: perhaps there’s an issue of being in a less-than-private environment while working with private stuff, while another situation involves lighting conditions. Perhaps you’re limited in space as to how wide you can open it (airline seat).

DO NOT WANT

cloudguy said:

anonconformist said:

Weird headline indicates operating systems aren’t software, which is nonsensical on its face: operating systems are the quintessential software, upon which separate user space applications depend on to exist, as abstract libraries full of functions that allow users to interface between the physical hardware interfaces and the user space applications. 

So, if you have more to worry about than adapting compiler toolchains, boot code, a little abstraction code for certain optimized APIs in the OS, and the HAL and device drivers, you’re doing it wrong.

The rest is mechanical in nature.

Point 1: good grief. People who have, you know, actually studied computer architecture and organization please speak up. In the meantime ... it has been common parlance for decades to refer to application software as software and systems software as the OS. And also to refer to both the kernel and the software that runs on top of the kernel but below the application software (conceptually) like the GUI as "the OS" when you really shouldn't, especially when it comes to Linux. So ... I don't get where you are going with this?

Point 2: "You're doing it wrong ... the rest is mechanical in nature." Ah. That is where you are going with this. The first is FALSE and the second is VERY FALSE. Clearly you haven't done this before. Let the people who have be the ones to talk about this because they are the ones who are actually qualified to do so. Go try to port a major application from x86 to ARM on the same OS (i.e. Linux or Android) and see how "mechanical" it is. Not even that ... merely port a 32 bit application to a 64 bit one. Done it before? It is neither easy or fun. But I guess it should have been "mechanical" and it was "being done wrong" eh? Goodness where do people like this come from?

Well, I go to clear out long-open tabs, and come back to this thread.

Guess what, I do this sort of thing for a living.  I work in the bowels of a major OS, in the context of ALL the code, not just that which executes in user-space.  Guess what? It’s exactly as I’ve described it as far as how things are abstracted! Also guess what? The OS provides LOTS of abstractions in libraries you link into your application for a huge number things to make your life far easier.  Guess what? Yes, making a direct port between one machine architecture and another IS done by the Hardware Abstraction Layer of the OS for a lot of the things that need to be abstracted, a d there is ALSO an ABI (Application Binary Interface) standardized for each compatible processor that runs the same low-level code, in the case of Intel, how things are passed via the registers and the stack vary based on whether it is 32-bit or 64-bit.  Sure, you could pass everything via the same ABI on 64-bit, but it has more registers to work with, so that’s something good to take advantage of.

Now, about the code in user-space applications: given the same source code, whatever the higher-level language, even if it is NOT perfectly “portable” (C/C++ have a huge number of things in the language specifications explicitly left to the vendors to specify, because they’re intended for use at the lowest system level for performance) and, this will clearly amaze you, to get perfectly correct translations from one CPU to any other CPU for anything at a level higher than native assembly language ABSOLUTELY has a mechanical transform you can make from code A to code B to achieve the same logical results.  Things are a little more interesting when sizes of integers used from one CPU to the next, but despite all that, it is STILL very mechanical and straightforward to translate working code from one CPU to the next: this is very commonly done in C/C++ via macros and the preprocessor.

tht said:

anonconformist said:

With dedicated media acceleration they don’t have a need for several low-power cores while playing back video, or even encoding it: most common desktop applications rarely make use of more than 2 separate threads at any given time, with one being for front end GUI interaction with the user, and a background thread for waiting on I/O, which, when the hardware is implemented correctly, is mostly waiting without much processor use anyway. Thus, it’s fully possible in most use-cases you can do all you need with just the 2 energy-efficient cores: Mail or Pages will be far more than fast enough with the 2 small cores. Web browsing, similar for I/O, but other things will cause greater power core usage, and a lot more threads.

The other reason you would use efficiency cores are for regular scheduled background system tasks, that don’t need much CPU power. Again, even 2 threads is more than a lot of those will use. I personally thought it was more an odd choice for the M1 to start out with 4 energy-efficient cores because of these reality-based considerations. Perhaps that was more a question of getting some real-world results achieved with lower risk, and getting real-world data of core usage in practice as to why they went with those decisions.

If you look at the die shots, the e-cores take up about 1% of the SoC chip area in the M1 Max and about 2% in the M1 Pro. Adding another 2 e-cores isn't a big cost. I can only think of one reason for them to do this: they needed the standby and idle power consumption of the M1 Pro and Max to be as low as they could possibly go, and they felt that 2 additional e-cores was enough CPU to handle standby and idle tasks, like all the app and system tasks you mention. But the iPhone has 4 e-cores! And, you'd think an iPhone would really need to save on power, and yet, it has 4 e-cores. So, here we are, why the difference?

The e-cores are so small such that having 4 or 6 e-cores just isn't that big of a cost. If they prevent the p-cores from firing up while web browsing, especially background web pages, it seems like a nice gain in energy efficiency. It's a browser-centric, javascript-centric workflow most of the time for users, even if they do a lot of GPU compute or multi-threaded workloads, most people still spend a lot of their time just web browsing. So, managing background web pages with e-cores seems like a really good idea.

At some point adding e-cores isn't effective in the energy efficiency versus perf trade, so, it's not going to be 8, 12, 16 e-cores, but I would think 4 to 8 would be the sweet spot for 8, 16, 32 p-core systems.

Consider this for a possible explanation as to why only 2 e-cores versus more: as much as each of their cores are a tiny percentage of the die space, it’s distance signals must traverse farther for, and included in this is memory controllers and cache coherency for each core, which I’m reasonably guessing is as complicated and as large and as much of a system performance overhead with no regards to how fast the core is. In software development a big overhead for many processes with more than one thread is due to synchronization between threads, and the e-cores versus p-cores won’t be any better, perhaps even worse, since they tend to run at different frequencies, which has its own fun for buffering between them.  The iPhone isn’t something I’d ever expect will expand beyond around what it has for number of main CPU cores and similar GPU cores, and the other added things in the SoC, because… it’s a phone, and not a wise use-case trying to do all you can do in a laptop or even a full-sized iPad for human reasons, if nothing else.

Glue logic has its place and its price in any design, and can make or break a system.  It’ll be interesting to see what Apple does for core breakdowns across all their products, from the Watch up to their MacPro.  I also consider the original M1, as much as anything, a usable lower-risk proof of concept release for many things, including the scaled-up design of things along so many fronts, and a rational iterative development strategy of walk (fast!) before you try to run.  It’s really the Mac MVP for their transition.