By: juanrga (noemail.delete@this.juanrga.com), December 21, 2018 10: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 08:36 AM |
RISC-V gut feelings | Konrad Schwarz | 2018/12/20 04:30 AM |
RISC-V inferior to ARMv8 | Heikki Kultala | 2018/12/20 07:36 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/20 01:31 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/20 02:18 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 03:43 AM |
RISC-V inferior to ARMv8 | Ronald Maas | 2018/12/21 09:35 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 10:28 AM |
RISC-V inferior to ARMv8 | Maynard Handley | 2018/12/21 02:39 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 03:38 PM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/23 04:39 AM |
With similar logic nor do frequency (NT) | Megol | 2018/12/23 09:45 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/23 04:44 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/23 06:21 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/20 03:24 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/20 04:22 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 06:16 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/22 03:53 AM |
Execution runtimes and Spectre | Foo_ | 2018/12/22 06:02 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/20 08:51 PM |
RISC-V inferior to ARMv8 | Doug S | 2018/12/20 11:10 PM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/20 11:38 PM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/21 02:31 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 03:23 AM |
RISC-V inferior to ARMv8 | random person | 2018/12/21 02:04 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/21 04:27 AM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 10:36 AM |
RISC-V inferior to ARMv8 | Doug S | 2018/12/21 12:02 PM |
RISC-V inferior to ARMv8 | juanrga | 2018/12/21 10:23 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/20 11:21 PM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 01:48 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 03:44 AM |
RISC-V inferior to ARMv8 | anon | 2018/12/21 05:24 AM |
RISC-V inferior to ARMv8 | Adrian | 2018/12/21 04:09 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 04:28 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/21 02:27 AM |
RISC-V inferior to ARMv8 | Gabriele Svelto | 2018/12/21 01:09 PM |
RISC-V inferior to ARMv8 | Maynard Handley | 2018/12/21 02:58 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 03:43 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 05:45 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 04:37 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 06:54 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 10:32 AM |
Cracking is not free | Gabriele Svelto | 2018/12/22 02:09 AM |
Cracking is not free | Wilco | 2018/12/22 04:32 AM |
Cracking is not free | Travis Downs | 2018/12/22 07:07 AM |
Cracking is not free | Wilco | 2018/12/22 07:38 AM |
Cracking is not free | Travis Downs | 2018/12/22 07:47 AM |
Cracking is not free | Wilco | 2018/12/22 10:24 AM |
Cracking is not free | Travis Downs | 2018/12/25 03:41 PM |
Cracking is not free | anon.1 | 2018/12/25 08:14 PM |
multi-instruction decode and rename | Paul A. Clayton | 2018/12/22 06:45 PM |
Cracking is not free | Gabriele Svelto | 2018/12/22 12:30 PM |
Cracking is not free | Wilco | 2018/12/23 06:48 AM |
Cracking is not free | Michael S | 2018/12/23 08:09 AM |
Cracking is not free | Gabriele Svelto | 2018/12/26 02:53 PM |
RISC-V inferior to ARMv8 | rwessel | 2018/12/21 01:13 PM |
RISC-V inferior to ARMv8 | Seni | 2018/12/21 02:33 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/21 03:33 PM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 05:49 PM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 04:58 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 07:03 AM |
RISC-V inferior to ARMv8 | Wilco | 2018/12/22 07:22 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 07:40 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/21 03:57 AM |
RISC-V inferior to ARMv8 | Konrad Schwarz | 2018/12/21 02:25 AM |
RISC-V inferior to ARMv8 | j | 2018/12/21 10:46 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/21 06:08 PM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/22 07:45 AM |
RISC-V inferior to ARMv8 | Travis Downs | 2018/12/22 07:50 AM |
RISC-V inferior to ARMv8 | Michael S | 2018/12/22 08:15 AM |
RISC-V inferior to ARMv8 | dmcq | 2018/12/22 10:41 AM |
RISC-V inferior to ARMv8 | AnonQ | 2018/12/22 08:13 AM |
RISC-V gut feelings | dmcq | 2018/12/20 07:41 AM |
RISC-V initial take | Konrad Schwarz | 2018/12/21 02:17 AM |
RISC-V initial take | dmcq | 2018/12/21 03:23 AM |
RISC-V gut feelings | Montaray Jack | 2018/12/22 02:56 PM |
RISC-V gut feelings | dmcq | 2018/12/23 04:38 AM |
RISC-V Summit Proceedings | juanrga | 2018/12/21 10:47 AM |
RISC-V Summit Proceedings | dmcq | 2018/12/22 06:21 AM |
RISC-V Summit Proceedings | Montaray Jack | 2018/12/22 02:03 PM |
RISC-V Summit Proceedings | dmcq | 2018/12/23 04:39 AM |
RISC-V Summit Proceedings | anon2 | 2018/12/21 10:57 AM |
RISC-V Summit Proceedings | Michael S | 2018/12/22 08:36 AM |
RISC-V Summit Proceedings | Anon | 2018/12/22 05:51 PM |
Not Stanford MIPS but commercial MIPS | Paul A. Clayton | 2018/12/23 03:05 AM |
Not Stanford MIPS but commercial MIPS | Michael S | 2018/12/23 03:49 AM |
Not Stanford MIPS but commercial MIPS | dmcq | 2018/12/23 04:52 AM |