Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Risc-v
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
jlpoole
Apprentice
Apprentice


Joined: 01 Nov 2005
Posts: 235
Location: Napa, CA

PostPosted: Thu Aug 21, 2014 1:09 pm    Post subject: Risc-v Reply with quote

This headline caught my attention: RISC creator is pushing open source chips for cloud computing and the internet of things. I learned of it on reddit:

http://www.reddit.com/r/opensource/comments/2e2emz/risc_creator_is_pushing_open_source_chips_for/

Computer scientists at the University of California, Berkeley, are spearheading a movement to create an open source instruction set. RISC-V (Reduced Instruction Set Computing) was originally developed in the Computer Science Division of the EECS Department at the University of California, Berkeley. Their project page is at http://riscv.org/

See also: http://en.wikipedia.org/wiki/Field-programmable_gate_array

This piqued my curiosity, and I found this guide to building a system:

http://riscv.org/download.html#tab_zynqfpga

It seems that there are two platforms where the RISC-V could run on:

Zybo: http://www.xilinx.com/products/boards-and-kits/1-4AZFTE.htm $189

Zedboard: http://www.zedboard.org/buy ~$395?

Has anyone worked with these boards? I'm thinking Gentoo could be installed on one of these and thus have a completely open source computer. Although it may not be practical, it seems to be a step in the direction of being completely self-sufficient and free of black-box technologies and free from potential government intrusion -- an ideal I sense is embraced by the Gentoo community.

Comments?


Last edited by jlpoole on Sat Aug 23, 2014 10:01 pm; edited 1 time in total
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7938
Location: Somewhere over Atlanta, Georgia

PostPosted: Thu Aug 21, 2014 3:13 pm    Post subject: Reply with quote

Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.

- John
_________________
I can confirm that I have received between 0 and 999 National Security Letters.
Back to top
View user's profile Send private message
jlpoole
Apprentice
Apprentice


Joined: 01 Nov 2005
Posts: 235
Location: Napa, CA

PostPosted: Thu Aug 21, 2014 3:59 pm    Post subject: Reply with quote

John R. Graham wrote:
Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.

- John


Would that lack of performance be a result of the architecture, itself, or a result of the fact that it runs on a an FPGA board? I read at http://www.lowrisc.org/ that they are hoping to manufacture a run of chips that might sell for $10 in a couple of years. Would such a chip be, in your guess, have the same problems or competitive with what's available to day from AMD or Intel?
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7938
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Aug 22, 2014 2:27 am    Post subject: Reply with quote

Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:
  • Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
  • AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have.
  • There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction).
- John
_________________
I can confirm that I have received between 0 and 999 National Security Letters.
Back to top
View user's profile Send private message
jlpoole
Apprentice
Apprentice


Joined: 01 Nov 2005
Posts: 235
Location: Napa, CA

PostPosted: Fri Aug 22, 2014 2:46 pm    Post subject: Reply with quote

John R. Graham wrote:
Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:
  • Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
- John


I shared your comments and learned of a paper presented at the 19th IEEE International Symposium on High Performance Computer titled "Architecture Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures" which suggests otherwise:

Quote:
Our study suggests that whether the ISA is RISC or CISC is irrelevant...

Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy.

Thus, while ISA evolution has been continuous, it has focused on enabling specialization and has been largely agnostic of RISC or CISC.

http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf


I do not mean to be argumentative, but what you have written sounds very damning for RISC-V and with all due respect, I do not want people to read this thread thinking that statement is the final word on the matter. Your statement above seemed particularly compelling, so I wanted to learn more and share what I found.
Back to top
View user's profile Send private message
_chris
n00b
n00b


Joined: 22 Aug 2014
Posts: 2

PostPosted: Fri Aug 22, 2014 5:18 pm    Post subject: Reply with quote

As a RISC-V user, I would like to clarify a few misconceptions in this thread.

John R. Graham wrote:
Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.


I believe you misunderstood the links. The provided "Rocket" in-order core runs at well over 1 GHz in silicon. For an FPGA, it depends on what you buy, but I've been able to run it at 100 MHz while using 64kB level 1 caches and 256kB level 2 caches using the above zedboard. Just to make life easy for people with really tiny FPGAs, we provided a version with very small caches. But that's just a parameter.



John R. Graham wrote:
"Clock for clock, CISC provides 2 to 3 x performance vs. RISC."


Incorrect. Modern, high performance CISC processors translate CISC instructions into RISC micro-ops. This is almost always a 1:1 conversion (if they want to see any decent performance anyways). As the previously quoted Wisc "ISA Struggles" paper demonstrated, CISC and RISC are fairly equal in performance- certainly not 2-3x.

John R. Graham wrote:
"AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have."


Intel's main advantage has always been its foundries. But AMD (and pretty much all other processor companies like NVIDIA and Apple) are fabless.


John R. Graham wrote:
"There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction)."



OoO and branch prediction are micro-architectural implementation details that are completely orthogonal to the ISA. If anything, x86 makes OoO harder than RISC, requiring incredibly complex decoder units that they attempt to turn off for energy and performance reasons when they can (aka, the "run in RISC mode"). There is no reason RISC-V can't utilize the same micro-architectural features to run as fast as modern x86 processors (and in fact, I know of at least IIT Madras building OoO RISC-V cores). Performance will be dependent on the quality of the implementation, not the instruction set architecture.


John R. Graham wrote:
I don't see it becoming a practical "daily driver" right away.


I think the biggest hurdle to Gentoo on RISC-V would be the device driver story (Linux already works, but most system calls are proxied onto something else, like the ARM core attached to the FPGA). I think "lowrisc" is a good group to follow who are working on building exactly what jlpoole wants - an open-source SoC that can run Linux and talk to your devices.
Back to top
View user's profile Send private message
lowrisc
n00b
n00b


Joined: 23 Aug 2014
Posts: 1

PostPosted: Sat Aug 23, 2014 5:56 pm    Post subject: Reply with quote

Hi all,

yes, as Chris notes, the lowRISC team is aiming to create (and sell, in volume) a RISC-V based SoC. We're a not-for-profit organization.

Our (placeholder) website is at www.lowrisc.org (it has a brief FAQ).

We're also hiring right now! Two positions are open based in Cambridge UK (closing date 9 Sep 2014).

Personally, I'm a huge Gentoo fan (and user), so I hope we will see it running on one of our devices some day. :D
_________________
Gavin
Back to top
View user's profile Send private message
jlpoole
Apprentice
Apprentice


Joined: 01 Nov 2005
Posts: 235
Location: Napa, CA

PostPosted: Sat Aug 23, 2014 6:40 pm    Post subject: Reply with quote

Gavin's reputation in the open source world is noteworthy: http://www.gnome.org/news/2013/07/interview-with-gavin-ferris-gnome-privacy-campaign-donor/

In 2007, he started with Ubuntu. As of July 2013 he reconsidered his choice and moved to Gentoo about two years ago, undoubtedly touched by the omniscient one.

I'm pleased to learn of his participation as a principal in this endeavour.

A milestone will be running Gentoo on such a platform and then comparing results from standardized performance tests. It's tempting to try installing Gentoo on a system Zybo or Zedboard (see my prior postings in this thread) just to do a proof-of-concept and have a baseline for performance. Could also compare with my experiences on a Sheeva Plug (1.2GHz Marvell Sheeva CPU), Genesi Efika (Freescale i.MX515 (ARM Cortex-A8 800MHz)), and BeagleBone (AM335x 720MHz ARM® processor) just for kicks.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32434
Location: 56N 3W

PostPosted: Sat Aug 23, 2014 8:22 pm    Post subject: Reply with quote

I'll stir the pot a little.

its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
szatox
Guru
Guru


Joined: 27 Aug 2013
Posts: 443

PostPosted: Sun Aug 24, 2014 4:49 pm    Post subject: Reply with quote

Quote:
its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32434
Location: 56N 3W

PostPosted: Sun Aug 24, 2014 5:04 pm    Post subject: Reply with quote

szatox,

In theory, you can write your own microcode for you CPU but its a daunting task - even when you know which bit in the microcode does what.
The first thing you need to to is to reverse engineer existing an microcode, which itself may not be correct.

In effect, the microcode builds up CISC instructions from a sequence of RISC instructions.
Being able to do that in the microcode will be faster than the extra RISC instructions since less instructions need to be fetched from RAM.

Of course, if you know how the hardware operates maybe you can optimise the microcode better than AMD/Intel but somehow I doubt you have the time for that.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
_chris
n00b
n00b


Joined: 22 Aug 2014
Posts: 2

PostPosted: Sun Aug 24, 2014 9:32 pm    Post subject: Reply with quote

szatox wrote:
Quote:
its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost?


As NeddySeagoon mentioned, the best you could do is write your own micro-code to govern the x86->RISC uop translation. This has two huge assumptions (which aren't true) - 1) you have the ability to upload your own micro-code and 2) you understand the micro-code.

Unless you are Intel (or the NSA), I don't know of anybody who has the ability to patch micro-code. But let's assume we do...

For performance, most of the x86 instructions are 1:1 to the RISC uops. So there's nothing to gain here. Then there's instructions like string operations, but I bet Intel has put serious development into making those instructions very fast. So I doubt a hacker will do better than Intel.

Of course, if you control the micro-code, you can always add your own x86 instructions that will only run on your own hacked Intel processor. I'm not sure what there is to win here though, especially if you're a RISC person who doesn't believe in heavily micro-coded instructions.

Perhaps what you were really asking is "would there be a performance improvement if we could remove the complicated x86 front-end and direct execute RISC micro-ops with no complicated translation required?" That's a damn good question and the answer is hotly debated. I'll give two answers to that question.

The first is "almost certainly." In fact, high performance x86 processors make use of uop caches to allow them to turn off the x86 fetch and decode front-end, and run "RISC-style" straight out of the uop cache (treating it as a regular RISC L1 instruction cache). This gives Intel significant performance and power savings. So naturally, one would think this would be a win if they could just always get away with it, right?

My second answer is "not really." First, you would need to handle all of the corner cases of executing weird x86 instructions, otherwise you are no longer an x86 processor. So you already need the hardware datapaths for stopping the machine and injecting micro-code. Second, most executed x86 instructions are 1:1 decoded to RISC uops, so they already can basically execute "natively" as is. And this common case datapath is what's on the "critical path" of the machine, allowing it to speculate that it can execute stuff quickly with minimal decode anways. And again, Intel has added uop caches, so they can still stay CISC and get the benefits of RISC, so why bother trying to be "more pure"? Finally, all of the complicated x86 front-end let's them do weird things like micro-op fusion, micro-op cracking, and other such things to get great performance that would match an equivalent RISC machine.

Basically what I'm saying is I suspect CISC and RISC are probably not very different in terms of raw machine performance (although low-power CISC may be very difficult) ... but in terms of ease to build, CISC has got to be a fucking terrible architecture to implement, verify, and debug.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32434
Location: 56N 3W

PostPosted: Mon Aug 25, 2014 4:39 pm    Post subject: Reply with quote

_chris,

_chris wrote:
... CISC has got to be a fucking terrible architecture to implement, verify, and debug.


There is lots of evidence for that. Consider the early AMD x86 CPUs. They didn't have the same bugs an the Intel chips so there were a few nasty corner cases.
As Intel was the defacto standard for x86, it didn't matter that Intel chips did not work as advertised, just that the AMD offering was different.

AMD learned the lesson and copied the Intel bugs too.

I have been in the position of debugging microcode for an in house embedded system.
It gets really hard when you run out of space in the microcode storage area but you need just one more line.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum