By: juanrga (noemail.delete@this.juanrga.com), December 21, 2018 11:36 am
Room: Moderated Discussions
random person (random.delete@this.person.com) on December 21, 2018 2:04 am wrote:
> Doug S (foo.delete@this.bar.bar) on December 20, 2018 11:10 pm wrote:
> > Adrian (a.delete@this.acm.org) on December 20, 2018 8:51 pm wrote:
> > > The RISC-V fans argue that the extra instructions do not matter, because a fast implementation will fuse
> > > the address computation instructions with the data handling instructions, achieving the same throughput.
> > >
> > >
> > > I do not agree, because I believe that it is stupid to code
> > > the address computation with an extra instruction
> > > word, when the same thing can be encoded with a couple of
> > > bits in an addressing mode field and the instruction
> > > decoder is also certainly simpler than the one that must fuse those instruction pairs.
> >
> >
> > Aren't these differences due to the fact ARMv8 has evolved from previous ARM ISAs over a
> > few decades of real world use that showed where the weak points were, whereas RISC-V is
> > mostly from an academic ivory tower purist background with very little real world usage?
> > Sometimes you find you must compromise your purist principles to produce a better result,
> > which is why ARMv8 adopted some features that aren't considered traditionally RISC.
>
> I think this is oversimplifying things - you don't have to have built an ARMv7 chip to have learned from some
> of ARMv7's mistakes. Or x86's. You seem to be oddly dismissive of academics, but they articulate why they
> made the choices that they did. Clearly, one of their primary goals was to create an ISA that is as simple
> as possible to decode, with some obvious sacrifices to code density. Having such a small and easy to decode
> ISA allows them to push to even smaller design points than might be possible for some other ISAs.
>
> > The arguments made by the RISC-V fans sound a lot like arguments made by Itanium fans
> > where the compiler would pick up the slack for the shortcomings, and the raw speed would
> > enable it to beat all comers. But RISC-V fans aren't even claiming this will result in
> > superior performance, only that it will be the same. If so, what's the point?
> >
> > They are trading complexity in instruction decode for dynamic execution complexity. I think the
> > performance that x86 is able to attain has shown us that instruction decode complexity matters
> > little if at all given modern transistor budgets. Getting wider to issue and execute those index
> > calculations as separate instructions in parallel, on the other hand, requires very careful design
> > to insure all paths have enough resources without escalating power draw too much.
>
> Let's not get carried away here - x86 processors are attaining performance by fighting against/working
> around ugliness of the ISA here. Those uop caches take a lot of transistors, and will have to continue
> to grow over time and then they still have to put down a lot of logic for the regular decode path,
> so they sure are spending a lot on this for it to supposedly 'matter little if at all'. Wide issue
> helps little if you can only sustain a couple of uops per cycle from the front end.
>
> The loss of some code density does hurt though, so there is definitely room for a more middle-ground
> approach. RISC-V C extension presents either 2B or 4B instructions, which is certainly a lot better
> to deal with than the 'anywhere between 1 and 15 bytes' of x86. However, there's something to be
> said for the simplicity of pure fixed-length ISAs, as it simplifies quite a bit in the fetch, decode,
> branch prediction. Notice that even Samsung's ARMv8 core can hit 48B fetch per cycle, where Skylake
> can get to at most 16B. Is x86 able to achieve 3x the code density to make up for it?
>
>
As dmcq mentioned, ARMv8 is slightly more dense than x86-64.
RV64 is about 8% less dense than x86-64 (on SPECint2006). But RV64C is about 30% more dense than x86-64.
> Doug S (foo.delete@this.bar.bar) on December 20, 2018 11:10 pm wrote:
> > Adrian (a.delete@this.acm.org) on December 20, 2018 8:51 pm wrote:
> > > The RISC-V fans argue that the extra instructions do not matter, because a fast implementation will fuse
> > > the address computation instructions with the data handling instructions, achieving the same throughput.
> > >
> > >
> > > I do not agree, because I believe that it is stupid to code
> > > the address computation with an extra instruction
> > > word, when the same thing can be encoded with a couple of
> > > bits in an addressing mode field and the instruction
> > > decoder is also certainly simpler than the one that must fuse those instruction pairs.
> >
> >
> > Aren't these differences due to the fact ARMv8 has evolved from previous ARM ISAs over a
> > few decades of real world use that showed where the weak points were, whereas RISC-V is
> > mostly from an academic ivory tower purist background with very little real world usage?
> > Sometimes you find you must compromise your purist principles to produce a better result,
> > which is why ARMv8 adopted some features that aren't considered traditionally RISC.
>
> I think this is oversimplifying things - you don't have to have built an ARMv7 chip to have learned from some
> of ARMv7's mistakes. Or x86's. You seem to be oddly dismissive of academics, but they articulate why they
> made the choices that they did. Clearly, one of their primary goals was to create an ISA that is as simple
> as possible to decode, with some obvious sacrifices to code density. Having such a small and easy to decode
> ISA allows them to push to even smaller design points than might be possible for some other ISAs.
>
> > The arguments made by the RISC-V fans sound a lot like arguments made by Itanium fans
> > where the compiler would pick up the slack for the shortcomings, and the raw speed would
> > enable it to beat all comers. But RISC-V fans aren't even claiming this will result in
> > superior performance, only that it will be the same. If so, what's the point?
> >
> > They are trading complexity in instruction decode for dynamic execution complexity. I think the
> > performance that x86 is able to attain has shown us that instruction decode complexity matters
> > little if at all given modern transistor budgets. Getting wider to issue and execute those index
> > calculations as separate instructions in parallel, on the other hand, requires very careful design
> > to insure all paths have enough resources without escalating power draw too much.
>
> Let's not get carried away here - x86 processors are attaining performance by fighting against/working
> around ugliness of the ISA here. Those uop caches take a lot of transistors, and will have to continue
> to grow over time and then they still have to put down a lot of logic for the regular decode path,
> so they sure are spending a lot on this for it to supposedly 'matter little if at all'. Wide issue
> helps little if you can only sustain a couple of uops per cycle from the front end.
>
> The loss of some code density does hurt though, so there is definitely room for a more middle-ground
> approach. RISC-V C extension presents either 2B or 4B instructions, which is certainly a lot better
> to deal with than the 'anywhere between 1 and 15 bytes' of x86. However, there's something to be
> said for the simplicity of pure fixed-length ISAs, as it simplifies quite a bit in the fetch, decode,
> branch prediction. Notice that even Samsung's ARMv8 core can hit 48B fetch per cycle, where Skylake
> can get to at most 16B. Is x86 able to achieve 3x the code density to make up for it?
>
>
As dmcq mentioned, ARMv8 is slightly more dense than x86-64.
RV64 is about 8% less dense than x86-64 (on SPECint2006). But RV64C is about 30% more dense than x86-64.
Topic | Posted By | Date |
---|---|---|
RISC-V Summit Proceedings | Gabriele Svelto | 2018/12/19 09:36 AM |
RISC-V gut feelings | Konrad Schwarz | 2018/12/20 05:30 AM |
RISC-V inferior to ARMv8 | Heikki Kultala | 2018/12/20 08:36 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/20 02:31 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/20 03:18 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 04:43 AM |
RISC-V inferior to ARMv8 | Ronald Maas | 2018/12/21 10:35 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 11:28 AM |
RISC-V inferior to ARMv8 | Maynard Handley | 2018/12/21 03:39 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 04:38 PM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/23 05:39 AM |
With similar logic nor do frequency (NT) | Megol | 2018/12/23 10:45 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/23 05:44 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/23 07:21 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/20 04:24 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/20 05:22 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 07:16 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/22 04:53 AM |
Execution runtimes and Spectre | Foo_ | 2018/12/22 07:02 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/20 09:51 PM |
RISC-V inferior to ARMv8 | Doug S | 2018/12/21 12:10 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 12:38 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/21 03:31 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 04:23 AM |
RISC-V inferior to ARMv8 | random person | 2018/12/21 03:04 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/21 05:27 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 11:36 AM |
RISC-V inferior to ARMv8 | Doug S | 2018/12/21 01:02 PM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 11:23 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 12:21 AM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 02:48 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 04:44 AM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 06:24 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 05:09 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 05:28 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/21 03:27 AM |
RISC-V inferior to ARMv8 | Gabriele Svelto | 2018/12/21 02:09 PM |
RISC-V inferior to ARMv8 | Maynard Handley | 2018/12/21 03:58 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 04:43 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 06:45 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 05:37 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 07:54 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 11:32 AM |
Cracking is not free | Gabriele Svelto | 2018/12/22 03:09 AM |
Cracking is not free | Wilco | 2018/12/22 05:32 AM |
Cracking is not free | Travis Downs | 2018/12/22 08:07 AM |
Cracking is not free | Wilco | 2018/12/22 08:38 AM |
Cracking is not free | Travis Downs | 2018/12/22 08:47 AM |
Cracking is not free | Wilco | 2018/12/22 11:24 AM |
Cracking is not free | Travis Downs | 2018/12/25 04:41 PM |
Cracking is not free | anon.1 | 2018/12/25 09:14 PM |
multi-instruction decode and rename | Paul A. Clayton | 2018/12/22 07:45 PM |
Cracking is not free | Gabriele Svelto | 2018/12/22 01:30 PM |
Cracking is not free | Wilco | 2018/12/23 07:48 AM |
Cracking is not free | Michael S | 2018/12/23 09:09 AM |
Cracking is not free | Gabriele Svelto | 2018/12/26 03:53 PM |
RISC-V inferior to ARMv8 | rwessel | 2018/12/21 02:13 PM |
RISC-V inferior to ARMv8 | Seni | 2018/12/21 03:33 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 04:33 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 06:49 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 05:58 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 08:03 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 08:22 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 08:40 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/21 04:57 AM |
RISC-V inferior to ARMv8 | Konrad Schwarz | 2018/12/21 03:25 AM |
RISC-V inferior to ARMv8 | j | 2018/12/21 11:46 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 07:08 PM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/22 08:45 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 08:50 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/22 09:15 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/22 11:41 AM |
RISC-V inferior to ARMv8 | AnonQ | 2018/12/22 09:13 AM |
RISC-V gut feelings | dmcq | 2018/12/20 08:41 AM |
RISC-V initial take | Konrad Schwarz | 2018/12/21 03:17 AM |
RISC-V initial take | dmcq | 2018/12/21 04:23 AM |
RISC-V gut feelings | Montaray Jack | 2018/12/22 03:56 PM |
RISC-V gut feelings | dmcq | 2018/12/23 05:38 AM |
RISC-V Summit Proceedings | juanrga | 2018/12/21 11:47 AM |
RISC-V Summit Proceedings | dmcq | 2018/12/22 07:21 AM |
RISC-V Summit Proceedings | Montaray Jack | 2018/12/22 03:03 PM |
RISC-V Summit Proceedings | dmcq | 2018/12/23 05:39 AM |
RISC-V Summit Proceedings | anon2 | 2018/12/21 11:57 AM |
RISC-V Summit Proceedings | Michael S | 2018/12/22 09:36 AM |
RISC-V Summit Proceedings | Anon | 2018/12/22 06:51 PM |
Not Stanford MIPS but commercial MIPS | Paul A. Clayton | 2018/12/23 04:05 AM |
Not Stanford MIPS but commercial MIPS | Michael S | 2018/12/23 04:49 AM |
Not Stanford MIPS but commercial MIPS | dmcq | 2018/12/23 05:52 AM |