Personal computing discussed

Moderators: Flying Fox, morphine

 
Jason963
Gerbil In Training
Topic Author
Posts: 1
Joined: Mon Oct 08, 2018 2:47 am

Is x86 RISC or CISC?

Wed Nov 28, 2018 12:35 am

According to Wikipedia, x86 is a CISC design, but I also have heard/read that it is RISC.

What is correct? I'd to also like to know why it is CISC or RISC.

What determines if a design is RISC or CISC?

Is it just the number of machine language instruction a microprocessors has or are there any other characteristics that determine the architecture?
Last edited by Jason963 on Thu Nov 29, 2018 11:14 pm, edited 1 time in total.
 
biffzinker
Gerbil Jedi
Posts: 1990
Joined: Tue Mar 21, 2006 3:53 pm
Location: AK, USA

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 1:34 am

The Pentium MMX was the last cpu that executed x86 CISC. Everything up til today's current CPU is CISC on the front-end but gets decoded to RISC on the back-end.

From Wikipedia:
Some[who?] RISC proponents had argued that the "complicated" x86 instruction set would probably never be implemented by a tightly pipelined microarchitecture, much less by a dual pipeline design. The 486 and the Pentium demonstrated that this was indeed possible and feasible.

https://en.wikipedia.org/wiki/P5_(microarchitecture)
Last edited by biffzinker on Wed Nov 28, 2018 1:42 am, edited 1 time in total.
It would take you 2,363 continuous hours or 98 days,11 hours, and 35 minutes of gameplay to complete your Steam library.
In this time you could travel to Venus one time.
 
synthtel2
Gold subscriber
Gerbil Elite
Posts: 845
Joined: Mon Nov 16, 2015 10:30 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 1:41 am

Actual definitions of RISC and CISC are at best a bit fuzzy. A good metric might be how many instructions it typically takes to get something done; CISC will tend to have specific instructions for every situation, where RISC relies more on the composition of simpler instructions. The idea is that a RISC design can execute a lot more instructions in the same amount of time, even if each one accomplishes less.

x86 is definitely CISC, but one of the first things a modern x86 CPU does with an instruction stream is convert it into a different instruction set that it uses internally, which is (but doesn't have to be) more RISC-like. Effectively, they appear as CISC to the outside world, but are RISC under the hood.
 
jihadjoe
Gerbil Elite
Posts: 709
Joined: Mon Dec 06, 2010 11:34 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 3:56 am

New instructions like SSE and AVX definitely lean toward CISC though, and the performance gains are so good that even chips that started from a pure RISC design are using them.
 
just brew it!
Gold subscriber
Administrator
Posts: 51933
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 8:39 am

As others have noted, it's a nuanced question.

The instruction set itself is definitely CISC. Early x86 CPUs did indeed implement the instructions in hard-wired logic, and these were pure CISC CPUs.

Modern x86 designs all decompose the CISC opcodes into simpler "micro-ops", which are very "RISC-like". These are then executed by a core which is basically a highly pipelined RISC design.

So modern x86 is really a hybrid, using CISC instructions externally, but RISC techniques internally.

One interesting side effect of this is that CISC instructions tend to take up less space to encode a given amount of work. So x86 tends to be efficient in its use of code memory, and requires less memory bandwidth for instruction fetching, compared to comparable RISC designs. This is arguably one of the factors which helped x86 stay competitive with RISC. Also, as on-die caches have expanded to take up a majority of the die area on modern CPUs, the percentage of die area required for the CISC-to-RISC decode logic has shrunk to the point where it is essentially "lost in the noise".
Nostalgia isn't what it used to be.
 
tipoo
Gerbil First Class
Posts: 110
Joined: Tue Mar 19, 2013 5:43 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 9:24 am

synthtel2 wrote:
x86 is definitely CISC, but one of the first things a modern x86 CPU does with an instruction stream is convert it into a different instruction set that it uses internally, which is (but doesn't have to be) more RISC-like. Effectively, they appear as CISC to the outside world, but are RISC under the hood.



I wonder what that underlying ISA is like. I've always wondered if they could build an architecture that gets rid of the x86 block and just uses their underlying internal RISC architecture, as a basis for a post x86 RISC Intel CPU.

If Intel wasn't still in post Itanium x86-or-bust PTSD.
 
just brew it!
Gold subscriber
Administrator
Posts: 51933
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 9:30 am

I'm sure they could if they wanted to. Just isn't much point, other than as an academic exercise.
Nostalgia isn't what it used to be.
 
tipoo
Gerbil First Class
Posts: 110
Joined: Tue Mar 19, 2013 5:43 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 9:43 am

just brew it! wrote:
I'm sure they could if they wanted to. Just isn't much point, other than as an academic exercise.


Well, the ucode ROM and x86 decode blocks being almost as large as a performance driving unit like Int or FP seems like a reason it may have had difficulty scaling down to where ARM is.

Image
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 9:54 am

tipoo wrote:
I wonder what that underlying ISA is like.


It's different for each micro-architecture (sometimes a lot, sometimes a little). Intel documents some of it, indirectly, because it impacts the performance of ISA. Other people have deduced and empirically discovered further details, again, indirectly: the goal is performance.

It doesn't make sense to refer to this as an ISA: it is actually the exact opposite of an ISA. There is no abstraction. There is no binary compatibility. There are no other implementations.

tipoo wrote:
I've always wondered if they could build an architecture that gets rid of the x86 block and just uses their underlying internal RISC architecture, as a basis for a post x86 RISC Intel CPU.


Contradiction in terms, yet again: this cannot be an "architecture". An architecture is a model of how an abstract chip performs computations. That model can be implemented by different physical designs.

The "underlying internal RISC architecture" is simply a loose conceptual analogy. It is not actually a separately packageable discrete thing. It is inextricably (and uniquely for each design) intertwined with the ISA that operates above it, presumably across the entire spectrum. There is little reason to believe that Intel has even remotely attempted to maintain any sort of "separation of concern" between the two at any level or towards any distinct minor purpose even.

Could they design a different, more RISC-like, ISA? Yes.

In fact, they have. More than once. Decades ago. They built two in house in the late 80s/early 90s and they took over at least one from someone else. You probably haven't heard of any of them.

Could they do so again, using some of the design principles and expertise they've gained in the last quarter century since then? Sure.

Why though?

tipoo wrote:
If Intel wasn't still in post Itanium x86-or-bust PTSD.


That has nothing to do with it.
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 10:03 am

tipoo wrote:
Well, the ucode ROM and x86 decode blocks being almost as large as a performance driving unit like Int or FP seems like a reason it may have had difficulty scaling down to where ARM is.


Intel is putting -EIGHT- entire high performance cores on mid-tier consumer desktop processors now.

The GPU is ~30% of the 9900k's die.

The previous one, last year, had 6. The one before that had 4.

Hence, from just a very limited perspective, what you are saying can't be meaningful.

---

As to scaling down to where ARM is, the minimum size of an ARM design is already constrained by the lands--since the chip has to be affixed and connected to something otherwise it's a useless flake of silicon, the limiting factor is that, and has been for quite some time.

----

That's just the start of explaining why your misapprehension here is wrongheaded. (teaser: ARM chips also have microcode and instruction decode)
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1886
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 10:29 am

As Glorious pointed out there's a major misconception that ARM magically doesn't need and instruction decoder or microcode cache.

That might be true for some trivial embedded ARM processor, but for any large ARM chip (and by "large" I mean something that attempts to compete with an Atom core) that's not the case at all. Anybody who has paid attention to ARM's development can see that it is acquiring CISC features all the time. This leads to another misconception that anything and everything that's not x86 must be RISC, which is also wrong.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
TheRazorsEdge
Gerbil First Class
Posts: 192
Joined: Tue Apr 03, 2007 1:10 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 11:01 am

Jason963 wrote:
According to Wikipedia, x86 is a CISC design, but I also have heard/read that it is RISC.


x86 is the mullet of CPU architectures: CISC in the front, RISC in the back.
 
Chuckaluphagus
Silver subscriber
Gerbil Elite
Posts: 843
Joined: Fri Aug 25, 2006 4:29 pm
Location: Boston area, MA

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 11:27 am

tipoo wrote:
I've always wondered if they could build an architecture that gets rid of the x86 block and just uses their underlying internal RISC architecture, as a basis for a post x86 RISC Intel CPU.

A long time ago, back when the millennium was young and Apple was rumored to be switching their machines over to yet another processor architecture, I remember reading speculation that they were going to be commissioning/had commissioned exactly such a processor from AMD (this was back when Athlon64s stomped all over Pentium 4s, for reference) and were testing the idea in the lab. Don't know how much of that was true, of course.
 
techguy
Gerbil XP
Posts: 353
Joined: Tue Aug 10, 2010 9:12 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 11:48 am

TheRazorsEdge wrote:
Jason963 wrote:
According to Wikipedia, x86 is a CISC design, but I also have heard/read that it is RISC.


x86 is the mullet of CPU architectures: CISC in the front, RISC in the back.


LOL

Intel needs to hand out bumper stickers with this slogan to all their engineers.
 
dragontamer5788
Gerbil First Class
Posts: 174
Joined: Mon May 06, 2013 8:39 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 12:15 pm

RISC vs CISC is a long dead debate. ARM has vectorized SIMD instructions, and **lots** of them. Heck, ARM just added a new instruction called "FJCVTZS". Know what it does?

http://infocenter.arm.com/help/index.js ... 92868.html
Floating Point Javascript Convert to Zero Signed.

I dare you to call this a RISC instruction.

---------

ARM even had Jazelle instructions a long time ago (not anymore today...), which accelerated Java performance. This included an instruction called "BXJ", Branch to Java. This isn't "RISC" at all.

---------

Modern CPUs have instructions that their customers demands. Power9 (also a "RISC" instruction set, arguably) has decimal-floating points for all the financial people, as well as 128-bit floating point numbers. There's nothing "reduced" about those instruction sets at all.

The main thing that x86 does is translate their microcode into a load/store architecture. But even x86 executes complicated instructions like mov base_array[rax + rcx*4], rdx in a single clock cycle, suggesting that that entire "complex" instruction can indeed complete in a single clock. Which means the uOp is still quite "CISC-ish".
Last edited by dragontamer5788 on Wed Nov 28, 2018 12:20 pm, edited 1 time in total.
 
chuckula
Gold subscriber
Gerbil Jedi
Posts: 1886
Joined: Wed Jan 23, 2008 9:18 pm
Location: Probably where I don't belong.

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 12:19 pm

dragontamer5788 wrote:
RISC vs CISC is a long dead debate. ARM has vectorized SIMD instructions, and **lots** of them. Heck, ARM just added a new instruction called "FJCVTZS". Know what it does?

http://infocenter.arm.com/help/index.js ... 92868.html
Floating Point Javascript Convert to Zero Signed.

I dare you to call this a RISC instruction.

---------

ARM even had Jazelle instructions a long time ago (not anymore today...), which accelerated Java performance. This included an instruction called "BXJ", Branch to Java. This isn't "RISC" at all.


You beat me to posting that tidbit. To misquote Jeff Foxworthy: If your ISA is hardwired to make JavaScript run better, it's probably not RISC.
4770K @ 4.7 GHz; 32GB DDR3-2133; GTX-1080 sold and back to hipster IGP!; 512GB 840 Pro (2x); Fractal Define XL-R2; NZXT Kraken-X60
--Many thanks to the TR Forum for advice in getting it built.
 
blargh4
Gerbil
Posts: 11
Joined: Thu Oct 20, 2016 12:31 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 1:33 pm

> What determines if a design is RISC or CISC?

The main characteristic of what people call RISC these days is that instructions for memory access and operations on that data are decoupled, and that instructions tend to be either fixed length or simpler variable-length encoding than x86.

It's not a particularly interesting debate anymore. As Intel/AMD have pretty consistently demonstrated by driving most of the RISC competition out of the market, a sub-par ISA is not the important bottleneck in high-performance CPUs.
 
ludi
Lord High Gerbil
Posts: 8127
Joined: Fri Jun 21, 2002 10:47 pm
Location: Sunny Colorado front range

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 1:40 pm

TheRazorsEdge wrote:
Jason963 wrote:
According to Wikipedia, x86 is a CISC design, but I also have heard/read that it is RISC.


x86 is the mullet of CPU architectures: CISC in the front, RISC in the back.

Perfect.
Abacus Model 2.5 | Quad-Row FX with 256 Cherry Red Slider Beads | Applewood Frame | Water Cooling by Brita Filtration
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 2:03 pm

blargh4 wrote:
The main characteristic of what people call RISC these days is that instructions for memory access and operations on that data are decoupled, and that instructions tend to be either fixed length or simpler variable-length encoding than x86.

It's not a particularly interesting debate anymore. As Intel/AMD have pretty consistently demonstrated by driving most of the RISC competition out of the market, a sub-par ISA is not the important bottleneck in high-performance CPUs.


I feel I cannot endorse this comment enough.
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 2:41 pm

biffzinker wrote:
The Pentium MMX was the last cpu that executed x86 CISC.


Again, this is where the loose conceptual analogy starts to seriously mislead.

The P5, of any variety, didn't "execute x86 CISC" in any real sense any more than the P6 (Pentium Pro) did. It was superscalar, with unequal pipes.

Therefore, without knowing anything else about it, one can deduce that behind the scenes there was something less "CISCy" going on: if pipe A can handle any instruction, but pipe B can circumstantially handle only certain (and simpler) instructions, what is pipe B but a more "RISCy" backend? (again, speaking -very- loosely).

Was the P6 even more abstracted? Yes, but we're already on the continuum, are we not?

More to the point, as I've said before, the canonical "CISC" processor, the VAX, had implementions in the 80s in which all of their different formats and so on where decoded into simpler (and potentially shorter) "microwords" of a certain fixed-length (!!!). DEC technical literature freely spoke of the macro versus micro instruction, going back to the original VAX. It's not even their innovation, (It was from IBM's revolutionary the System/360, the very birth of the ISA itself) but it's notable with DEC because on some of the VAX implementations the more complex instructions infamously performed way worse than a set of their simpler (but yet still "macro") instructions that implemented the same thing in assembler. RISC proponents made serious hay with this.

But, if you think about it, that's obviously just an engineering short-coming. The chip could do better, the microcode, for whatever reason, just didn't. But this demonstrates that not even processors from the 70s "natively executed" CISC in the sense you are implying.

The only ones that did were the limited, basically crude, microprocessors of the 70s that couldn't afford anything else, and as a result, they couldn't really be referred to has having an ISA: Typically, (as in the 8008 or whatever) it was assembler-compatible, not binary compatible. (And there is the classic five stage RISC pipeline, which like the "trivial embedded ARM processors" Chuckula spoke of were *extremely* minimalistic [almost ascetic in both their dedication and accommodation] RISC designs like Chuckula spoke of.

Essentially, having an ISA at all implies what you say ended with the P5. Why? Because either you blatently don't have one (8008 et al, the computers of the 60s or earlier that the system 360 overturned) or your "ISA" results in a bunch of darn-near identical designs (like the classic five-stage RISC pipeline, all those early RISC processors were *very similar* in implementation---hence the appellation of "classic".)
 
blargh4
Gerbil
Posts: 11
Joined: Thu Oct 20, 2016 12:31 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 2:50 pm

"One interesting side effect of this is that CISC instructions tend to take up less space to encode a given amount of work. So x86 tends to be efficient in its use of code memory, and requires less memory bandwidth for instruction fetching, compared to comparable RISC designs."

FWIW, in my experience, compared to the commercially important modern "RISCs", the x86 win here isn't huge (though I assume you could design a denser CISC). From my experience, the average gcc-compiled amd64 linux object file is about 85-90% the size of its arm64 equivalent, though it depends strongly on the particular code. If you compare it to some dense variable-length encoding like ARM's thumb2, the advantage swings the other way.
 
dragontamer5788
Gerbil First Class
Posts: 174
Joined: Mon May 06, 2013 8:39 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 3:11 pm

tipoo wrote:
I wonder what that underlying ISA is like. I've always wondered if they could build an architecture that gets rid of the x86 block and just uses their underlying internal RISC architecture, as a basis for a post x86 RISC Intel CPU.

If Intel wasn't still in post Itanium x86-or-bust PTSD.


https://media.ccc.de/v/34c3-9058-everyt ... aid_to_ask

And no, the internal microcode should never be exposed. Intel Skylake increased the number of renaming shadow registers to 224 for example, which are used for reordering operations and hiding memory-latency. Since the number of "true" internal registers changes from architecture-to-architecture, there's no point in actually exposing that. Future CPU designs will want to be able to change their internal shadow registers to whatever is most efficient to the Cache design.

Even "RISC" systems like ARM or Power9 have internal "renaming registers" and microcode.

The RISC vs CISC debate is fully dead. There is almost no difference between architectures these days. All architectures compile down to microcode, divvy out the microcode to multiple execution pipes, use register-renaming to map a set of "ISA Registers" to "internal shadow registers" for out-of-order execution, and then uses a retirement engine to put everything back in order.

Literally every chip today: from your cell phone to $10,000+ Power9 boxes, to Intel and AMD systems. Its all roughly the same architecture. Even 128-bit SIMD, AES-instructions, and cryptographic polynomial multiply (useful in elliptical curve cryptography and GCM mode) have been added to ARM, Power9, and x86 systems. Since most CPUs today are really trying to optimize web-browsers.
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 3:17 pm

blargh4 wrote:
FWIW, in my experience, compared to the commercially important modern "RISCs", the x86 win here isn't huge (though I assume you could design a denser CISC). From my experience, the average gcc-compiled amd64 linux object file is about 85-90% the size of its arm64 equivalent, though it depends strongly on the particular code. If you compare it to some dense variable-length encoding like ARM's thumb2, the advantage swings the other way.


There's less room to play with RISC, but if you don't really focus on the different addressing modes/complex instructions on the CISC side, you won't actually get the full benefit of the potential. Compilers almost always emphasize for performance over size, and since often times those complex instructions get what you might call "performance orphaned" (i.e. they are there, and they work, but over the years they aren't a performance target anymore), compiler writers typically avoid them (and for other reasons too).

At any rate, I recall 25% being the historical rule of thumb, so what you say you saw now sounds about what I'd expect.

The biggest thing here is that, today, the code density -is- related to performance: cache matters. And if you are concerned about memory, as memory, it has an impact there too.
 
dragontamer5788
Gerbil First Class
Posts: 174
Joined: Mon May 06, 2013 8:39 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 4:05 pm

Honestly, the machines these days which have the "spirit of RISC" are GPUs. You have very, very simple cores, all tied together with a single instruction pointer. You get 64-wide 32-bit operations typically in AMD or NVidia CPUs. (I think NVidia shrank it to 32-at-a-time in more recent architectures). In either case, you're executing a LOT of operations per clock tick, but have difficulty with "if" statements and loops.

So you've got your typical CPU design, which is an out-of-order design which looks for parallelism at run time. Then you have GPUs which are explicitly programmed with parallelism at compile-time.

Those are IMO, the only real kinds of designs going on today. Since CPUs have a huge engine to look for parallelism, "classic" code runs faster, since there's a huge amount of innate parallelism in most people's math problems. (Quadratic equation: -b +/- sqrt(b^2 - 4*a*c) / 2a. The 2*a, b^2, and 4*a*c can all execute at the same time. Any modern CPU would automatically parallelize the instruction stream and do so). Doesn't matter if you are Intel, AMD, ARM, or Power9. All systems will read the instruction stream, break it apart into micro-ops, scheudle the renaming engine, execute those instructions out of order, and innately parallelize it (even though the code wasn't designed for parallelism, the CPU "discovers" the parallelism and executes it).

GPUs do NOT have an out-of-order engine, and instead rely upon the programmer to point out splotches of code which can become parallelized. CUDA / OpenCL / OpenMP, and other technologies, have made this easier to do. Since the programmer points out the parallelism explicitly, GPUs get rid of the out-of-order engine and almost purely rely upon the programmer / compiler. Even then, neither NVidia nor AMD expose the internals of the GPU (like how many registers actually exist). PTX code and GCN code are compiled, and reinterpreted for specific architectures. IE: Your CUDA code turns into PTX "intermediate assembly" first, and then later the PTX code turns into "final device machine code" at a later time.

Its very important to have a steady instruction-set that works across generations of designs. So you'll never see the "real system" exposed. There will always be a translation layer.
 
biffzinker
Gerbil Jedi
Posts: 1990
Joined: Tue Mar 21, 2006 3:53 pm
Location: AK, USA

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 4:52 pm

dragontamer5788 wrote:
GPUs do NOT have an out-of-order engine, and instead rely upon the programmer to point out splotches of code which can become parallelized. CUDA / OpenCL / OpenMP, and other technologies, have made this easier to do. Since the programmer points out the parallelism explicitly, GPUs get rid of the out-of-order engine and almost purely rely upon the programmer / compiler.

Reminds me of a discontinued uARCH that didn't take hold that might of replaced IA-32. Hint: IA-64
What I wouldn't give for an alternate reality.

Edit: https://en.wikipedia.org/wiki/IA-64
It would take you 2,363 continuous hours or 98 days,11 hours, and 35 minutes of gameplay to complete your Steam library.
In this time you could travel to Venus one time.
 
dragontamer5788
Gerbil First Class
Posts: 174
Joined: Mon May 06, 2013 8:39 am

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 5:44 pm

biffzinker wrote:
dragontamer5788 wrote:
GPUs do NOT have an out-of-order engine, and instead rely upon the programmer to point out splotches of code which can become parallelized. CUDA / OpenCL / OpenMP, and other technologies, have made this easier to do. Since the programmer points out the parallelism explicitly, GPUs get rid of the out-of-order engine and almost purely rely upon the programmer / compiler.

Reminds me of a discontinued uARCH that didn't take hold that might of replaced IA-32. Hint: IA-64
What I wouldn't give for an alternate reality.

Edit: https://en.wikipedia.org/wiki/IA-64


Well, that basically played out entirely in the past 10 years in the GPU world. AMD started with VLIW5 (5x VLIW per clock), shrank to 4x VLIW, and eventually GCN gave it up completely.

VLIW seems like a good idea, but it seems like in practice, even in the highly-parallel GPU world, its not really practical for the compiler to be making that decision. Modern GPUs are slightly "smarter" than VLIW and are kinda designed to be 10x SMT / hyperthreaded. So sure, there's a VLIW-like thing going on, with VPUs being allocated by the compiler. But the GPU is smart enough to realize when these cores aren't being fully utilized, and can quickly switch between threads to find more work.

EDIT: Consider this: DDR4 RAM needs to be refreshed every 8 microseconds, which causes a ~100nanosecond delay in any load/store operation. At 3GHz, 100-nanoseconds is 300-cycles btw, so that's a big delay. The compiler doesn't know when DDR4 RAM is going to be refreshed, it will never know. The CPU core on the other hand can easily just hold a "list of things to do" (ie: retirement engine / out-of-order queue) to execute other work if DDR4 starts to refresh itself and cause a delay. In effect: the modern CPU core assigns a "shadow register" to hold that information and wait for it, and then moves ahead in the instruction stream to find work to do and execute out-of-order. A VLIW computer however would be stuck, because one of the instructions it promised to execute is being held up to the refresh.

GPUs only implement a "little" bit of smarts, but it goes a long way. Like "here's (upto) 10 threads, choose the one that can run RIGHT NOW every clock tick". Its not like the compiler knows how fast RAM, L2, or L1 between generations. Its really best decided at runtime.

In effect: both AMD GPUs and NVidia GPUs have taken the "best part" of VLIW: the ability to execute a lot of math-operations in a single clock cycle. And then they added varying amounts of dynamic, runtime behavior to dramatically increase runtime performance. A wide scheduler to effectively run 10-threads or so at once (although only ~4ish in practice) to "look for work" seems to be what GPUs go for.
 
blargh4
Gerbil
Posts: 11
Joined: Thu Oct 20, 2016 12:31 pm

Re: Is x86 RISC or CISC?

Wed Nov 28, 2018 5:57 pm

biffzinker wrote:
dragontamer5788 wrote:
GPUs do NOT have an out-of-order engine, and instead rely upon the programmer to point out splotches of code which can become parallelized. CUDA / OpenCL / OpenMP, and other technologies, have made this easier to do. Since the programmer points out the parallelism explicitly, GPUs get rid of the out-of-order engine and almost purely rely upon the programmer / compiler.

Reminds me of a discontinued uARCH that didn't take hold that might of replaced IA-32. Hint: IA-64
What I wouldn't give for an alternate reality.

Edit: https://en.wikipedia.org/wiki/IA-64

The problem with static scheduling by the compiler is that the compiler is missing a lot of context. It has little idea what code paths are actually getting executed unless you train it; it has no clue about calls to code outside whatever it's optimizing, or what else is running on the CPU at the same time, it has no idea about what's in cache/tlb, etc. Even the last generations of Itanium starting moving to dynamic scheduling.
 
Glorious
Gold subscriber
Gerbilus Supremus
Posts: 11292
Joined: Tue Aug 27, 2002 6:35 pm

Re: Is x86 RISC or CISC?

Thu Nov 29, 2018 7:35 am

biffzinker wrote:
Reminds me of a discontinued uARCH that didn't take hold that might of replaced IA-32. Hint: IA-64
What I wouldn't give for an alternate reality.


I program for multiple IA-64 machines.

It's just another computer.

blargh4 wrote:
The problem with static scheduling by the compiler is that the compiler is missing a lot of context. It has little idea what code paths are actually getting executed unless you train it; it has no clue about calls to code outside whatever it's optimizing, or what else is running on the CPU at the same time, it has no idea about what's in cache/tlb, etc.


Which illustrates yet another aspect of how all this talk of "let's just use the "Internal RISC" of Intel's x86!" is deeply misleading: it's not like a "look-up translation table" in which one x86 instruction translates into several smaller micro-ops, BAM, done. No, it's part of an extraordinarily complex engine of dynamic execution, tied deeply into OOE and everything else.

You can't just separate the two. They're the same thing.
 
Buub
Maximum Gerbil
Posts: 4797
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: Is x86 RISC or CISC?

Thu Nov 29, 2018 12:13 pm

dragontamer5788 wrote:
Honestly, the machines these days which have the "spirit of RISC" are GPUs. You have very, very simple cores, all tied together with a single instruction pointer. You get 64-wide 32-bit operations typically in AMD or NVidia CPUs. (I think NVidia shrank it to 32-at-a-time in more recent architectures). In either case, you're executing a LOT of operations per clock tick, but have difficulty with "if" statements and loops.

So you've got your typical CPU design, which is an out-of-order design which looks for parallelism at run time. Then you have GPUs which are explicitly programmed with parallelism at compile-time.

Those are IMO, the only real kinds of designs going on today. Since CPUs have a huge engine to look for parallelism, "classic" code runs faster, since there's a huge amount of innate parallelism in most people's math problems. (Quadratic equation: -b +/- sqrt(b^2 - 4*a*c) / 2a. The 2*a, b^2, and 4*a*c can all execute at the same time. Any modern CPU would automatically parallelize the instruction stream and do so). Doesn't matter if you are Intel, AMD, ARM, or Power9. All systems will read the instruction stream, break it apart into micro-ops, scheudle the renaming engine, execute those instructions out of order, and innately parallelize it (even though the code wasn't designed for parallelism, the CPU "discovers" the parallelism and executes it).

GPUs do NOT have an out-of-order engine, and instead rely upon the programmer to point out splotches of code which can become parallelized. CUDA / OpenCL / OpenMP, and other technologies, have made this easier to do. Since the programmer points out the parallelism explicitly, GPUs get rid of the out-of-order engine and almost purely rely upon the programmer / compiler. Even then, neither NVidia nor AMD expose the internals of the GPU (like how many registers actually exist). PTX code and GCN code are compiled, and reinterpreted for specific architectures. IE: Your CUDA code turns into PTX "intermediate assembly" first, and then later the PTX code turns into "final device machine code" at a later time.

Its very important to have a steady instruction-set that works across generations of designs. So you'll never see the "real system" exposed. There will always be a translation layer.

Or to put it in simpler terms: CPUs are for general-purpose computing while GPUs are for specialized computing. Neither does the other's job particularly well.
 
Buub
Maximum Gerbil
Posts: 4797
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: Is x86 RISC or CISC?

Thu Nov 29, 2018 12:17 pm

dragontamer5788 wrote:
VLIW seems like a good idea, but it seems like in practice, even in the highly-parallel GPU world, its not really practical for the compiler to be making that decision. Modern GPUs are slightly "smarter" than VLIW and are kinda designed to be 10x SMT / hyperthreaded. So sure, there's a VLIW-like thing going on, with VPUs being allocated by the compiler. But the GPU is smart enough to realize when these cores aren't being fully utilized, and can quickly switch between threads to find more work.

"Seemed like a good idea" is the key here. It is impossible for the compiler to predict run-time behavior without a lot of additional information (for example PGO, which is itself imperfect).

VLIW failed because it was the wrong solution to the problem. IMHO, it was the opposite of the right solution.

Modern compilers are fantastic at optimizing code. People often don't realize just much amazing "rocket science" there is in a modern compiler's optimizer. They're fantastic. But, that being said, once again, they can only infer the programmer's intent and turn it into better code; they cannot predict runtime behavior because there are so many external factors that affect the runtime path.
Last edited by Buub on Thu Nov 29, 2018 12:19 pm, edited 1 time in total.

Who is online

Users browsing this forum: No registered users and 2 guests