Intel & AMD Form An x86 Ecosystem Advisory Group

[coder]

The evidence is the Pentium Pro, because that's why people hated the Pentium Pro. A lot of 32-bit code had some 16-bit code in it, which would slow down on Pentium Pro's. I'm not sure if that's the case with X86S, but I wouldn't be shocked if it was.

You can't reason this stuff by analogy, though. So far, we have no indication X86S will disadvantage 32-bit userspace and it's certainly not going to affect 32-bit arithmetic performance, since that's still a mainstay of arithmetic in 64-bit apps.

ARM has no standards, and it shows. Just look at Apple's silicon and Qualcomm's Snapdragon X chips, as none run Linux out the gate.

I doubt if can boot an old Linux distro on new x86 hardware, either. Even if you can get it to run, it won't run well. This stuff doesn't just work because of "standards", but rather takes time, effort, and devotion on the part of Intel and AMD. After all that, it's often the case that Michael has to apply patches to a bleeding edge kernel, for new hardware to work well enough for him to benchmark.

[coder]

Well, I'm honored by a reply from an AMD representative.
Please note that I'm usually quite critical, and by default I have no respect for any authorities. So, you won't be spared.
Also note, since you are affiliated with AMD (a major CISC CPU manufacturer), I have an immediate right to a presumption that you are biased.

First, he actually retired earlier this year. Second, he's from the GPU group.

https://www.phoronix.com/news/AMD-Bridgman-Retires

Finally, look at his registration date & post count. He's been around the block enough times to have no illusions about what to expect from this forum. Some people pester him with complaints and support requests, others with product suggestions, etc. There's often some respect and deference shown, but this forum has all types.

It's pretty amazing he's put up with it all, especially through all the turmoil that's AMD's driver and userspace have undergone, the past decade or so. If that hasn't sent him packing, I doubt anything you say will do it.

[r_a_trip]

You mention "custom or POSIX" software, but then go on to mention Windows and MacOS? So, it would be "Windows, MacOS, POSIX, or custom". Don't forget Android, as well.

Also, where do you get the idea that Snapdragon X is a souped up phone SoC? Apple is closer to that than Qualcomm, because the cores in Apple's M-series are an outgrowth of their custom cores designed for their iPhone and iPad. The cores used in Snapdragon X came from Nuvia, who were designing ARM cores for servers, before Qualcomm bought them. The whole reason Qualcomm spent all that money, on the acquisition, was to get high-performance cores to help them enter the laptop market. They're roughly in the same league as Apple's M-series, which isn't surprising since a lot of Nuvia's key designers came from Apple.

How do you discern a software ecosystem? Just curious.

Yes, MacOS runs on ARM these days and it also directly ties you to Apple. Yes, we have Asahi Linux (running more or less), but if that project throws in the towel, back to MacOS. Apple is anathema to me. If Apple ran the computing world, we would be wishing for the Microsoft of the 90's, when it comes to computing freedom. So them having a functional ARM desktop is moot. I don't touch poison.

Yes, Windows runs on ARM and that is about it. Discernable software eco system? Simple, how many ISVs have ported their software to run on Windows for ARM? Precious little. With Windows on ARM you get a very pale and anemic echo of what Windows is on x86.

Android? Phone OS. Plain and simple. Could be more, but Alphabet isn't interested in it. Again more limitations than helpful solutions.

ARM running custom (specific problem solving) or POSIX is simply if you want to have something that is usable and has a software selection, you are confined to these options. Did I mention Apple is off the table because of their business model?

From someone looking to have their personal computing needs comfortably met, ARM is a hodgepodge of non-standard custom SoCs, all dependent on non-standardised OS images. Choosing ARM mostly ties you to one vendor for the board, the processor and GPU and their own tailored OS images. Fully dependent on that party for support and the duration there of. So yes, ARM is well supported, just awfully fragmented and it ties you to one party or another for support. Even if Linux distributions provide an image for a certain board, you can't be certain they will provide it for another board of a different vendor. If that is a-ok for you, then yes ARM is perfectly fine.

For people who like to choose their mainboards based on what they provide and have the option of choosing from multiple vendors and then getting to choose from multiple AIBs, RAM vendors, Storage vendors, OS vendors, etc. ARM just doesn't cut it. (Even in x86 laptops there are multiple options to choose from in a lot of tiered segments.) x86 just holds the better cards. x86 offers the genuine personal computer experience. ARM gives mostly options to solve specific problems by offering tailored solutions. Neither is bad, but ARM simply doesn't cater to mainstream personal computing like x86 does. I suspect that will remain the case for at least multiple decades.

[coder]

So, he can't say "all CPUs are RISC internally", because that is a red herring,

He didn't.

since we are discussing how the front-end ISA affects the final performance. We are not discussing whether both CISC and RISC can be implemented in similar ways

Seems to me that his post was primarily concerned with the historical definition and evolution of RISC. If that's what he wanted to comment on, then it's fair for him to focus on that. Heck, this is a comment thread on an article about the new X86 advisory group. So, you really have no claim to be more on-topic than his post.

"Code density" is an argument that was relevant in the 1980's, no one cares about it today. If someone did care about code density, then more Linux applications would be compiled with gcc -Os.

To support such a claim, I think you need more evidence than that! I think concerns about code density haven't gone away, especially because aggregate core performance (i.e. number of cores * per-core performance) is scaling faster than cache sizes or memory bandwidth. I have little doubt that it's one of the issues faced by current cloud workloads. We've certainly seen gains posted by BOLT, as an example that this stuff matters.

https://www.phoronix.com/news/LLVM-Lands-BOLT

It's also a flawed test to say that people would use -Os if code size mattered. If we leave aside that most packages have build configurations aimed for general usage and just focus on the presumption that this statement applies to packages built for servers & cloud, essentially what you're claiming is that, for the issue of code density to be a real concern, the benefits of compiling with -Os must be so great as to overcome everything else done by -O2. Even if this is true for some packages, it cannot be true universally.

Finally, it presumes that the very definition of -O2 doesn't already take into account some size vs. speed tradeoffs. Even if the GCC developers aren't consciously doing this, the do base many such decisions on real-world performance data.


As an aside: if you're going to presume control over the subject of a discussion thread and put words into people's mouths, you're going to waste a lot of time & energy getting into pointless fights on here.

[coder]

True, but you are nit-picking. It is clear that I made a slight error when typing that sentence.

I didn't see it as such, but I accept your explanation and withdraw my criticism.

I have provided two pieces of evidence:
(1) it is very uncommon to see: gcc -Os
(2) code density is similar across today's popular ISAs

Now you say that you "need more evidence".
However, any of the two pieces of evidence I provided swings the conclusion highly in my favor, unless you can somehow prove both points to be false.

You made assertions about # 2, without citing any sources. Furthermore, your point doesn't apply to AArch64, which has no support for compressed instruction streams. The fact that RISC-V saw a need to introduce support for does argues in favor of it being an issue.

So, you are now arguing against point (1) only.
Both the "O2" and "Os" will optimize for both size and speed, but O2 will mostly optimize towards speed, and Os will optimize mostly towards code size. It says so in the docs.

Again, we don't know how many sub-options of -O2 were rejected on the basis of code density. The GCC developers might not even be aware of why they yielded regressions. You really can't use the prevalence of -O2 as proof that code density is a non-issue.

You are making a very convoluted argument, in such a way that it is not in any way clear that it defeats my point(1).

I didn't make the original assertion. My goal was simply to show that your claim is not firmly rooted in data or facts.

I'm not so confident, one way or another, but I think it does seem rather extreme to declare it's a non-issue. Code competes for space with data, in most of the cache hierarchy, and for memory bandwidth. In the sorts of a highly virtualized environments embraced by the cloud and most server operators, where many different VM images are executing, I expect this issue to be more prominent. That's as far as I go. I'm not saying it's a first-order concern, but I also think we shouldn't dismiss it. If you had actual data, to support your assertions, I'd love to see it.

BTW, Intel even acknowledged the issue, in the course of their discussion of APX, by pointing out that they compensated for the overhead of adding an extra prefix byte by the effectiveness of 3-operand instructions at eliminating register-to-register copies (i.e. mov instructions) from the the instruction stream. No, it's not proof, but it does show they're at least sensitive to the potential criticism of APX hurting code density.

[coder]

Is this so hard to find:
- https://www.bitsnbites.eu/cisc-vs-risc-code-density/

LOL, the very intro of that article contradicts you. It's examining the relative density of CISC vs. RISC, which wouldn't even be a worthy question if the author agreed with your assertion that density is a non-issue!

Irrelevant.

Agree to disagree.

Yes, I can.
It is a reasonable argument. You are being unreasonable here.

You can believe whatever you like. I don't accept it as such. You clearly have a winning personality.

Just because you refused to do a few quick searches on Google doesn't mean that there is no data available.

That's your job. If you make the claim, you get to back it up.

But for the purposes of our discussion, this is mostly irrelevant, because the end-effects are small.

"Small" is a very squirrelly word. It really should be quantified, and then people can decide its relevance.

[coder]

Of course, code density does matter, in the sense that if all our programs got 10 times bigger, no one would like it.
My argument is: the reason why code density does not matter in our discussion is that code density is similar in the duel of RISC vs x86.
Apparently, you have just attempted to take my claims out of the context.

Well, let's review what you actually claimed:

"Code density" is an argument that was relevant in the 1980's, no one cares about it today. If someone did care about code density, then more Linux applications would be compiled with gcc -Os.

Of course, you can say that you were only talking about CISC vs. RISC, but you sure didn't characterize it as such. In fact, if you really meant it how you're now claiming, that's a funny way to put it.

Anyway, your qualification seems to put this point to rest, so let's move on.

The problem is that the data is highly variable, although in 99% of cases the gains in speed will be similar to the losses in code size, by percentages.
This would be a "typical" result:

speed size
-O3 106% 107%
-O2 100% 100%
-Os 70% 85%​​​​​​

Simply looking at the efficaciousness of an unspecified version (of presumably GCC?) at producing smaller executables and the size vs. speed tradeoff of its options, on an unspecified executable with an unspecified value of -march really does nothing to answer the question of how bad the problem is.

To pursue the matter further, what I'd personally like to see would be stats on server apps of stalls due to instruction cache misses. I don't have this data, nor do I have time to go digging for it, just now. However, this is what I think it'd take to move the discussion forward in a meaningful way.