Ok, if two processors read/write the same address what happens? Could I assume the reads are coherent but writes are not? If this is the case then I assume I'd just need to design-wise restrict one processor from writing to another's area, yes? I've worked on worse. Quite promising set of ideas from my limited reading.
A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
11–16 of 16 posts
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#12I think it's interesting to compare this to a dual 64 core AMD system (so 128 cores) or similar in terms of the programming model or performance.
This completely different from EPYC (and the Xeon Phi). The x86's present a single coherent memory image and lots of identical CPU cores whereas this one doesn't. In some aspects it resembles a Cell processor, with the difference that the "SPUs" (the tiny in-order cores) have some direct access to the main memory and are mostly binary compatible with the "PPUs" (the five large RISC-V cores).
The question is whether it's worthwhile to adapt that new programming model and architecture? What can be achieved that is not possible or is price compatible with something boring and old-fashioned like 128 x64 cores etc.
I am all for new architectures. But the trick is getting people to make the effort to make use of them.
I think that when I write a good comment it gets buried and the only time comments are really popular is when I write something trite or silly that a lot of people are already thinking.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#13I like that only permitting writes to other cores' memory simplifies the design. If you want to read, you have to write a request to that core by storing the request in a place it will look, and tell it where to put the answer. And, all the cores heve to check for such requests. It is kind of surprising that that is acceptable. I suppose the usual case is that each core already knows what its neigbors will want to se…
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#14Earlier quoted context omitted.
This completely different from EPYC (and the Xeon Phi). The x86's present a single coherent memory image and lots of identical CPU cores whereas this one doesn't. In some aspects it resembles a Cell processor, with the difference that the "SPUs" (the tiny in-order cores) have some direct access to the main memory and are mostly binary compatible with the "PPUs" (the five large RISC-V cores).
I know that its a different architecture. The question is whether it's worthwhile to adapt that new programming model and architecture? What can be achieved that is not possible or is price compatible with something boring and old-fashioned like 128 x64 cores etc. I am all for new architectures. But the trick is getting people to make the effort to make use of them. I think that when I write a good comment it gets bu…
probably more to do with the gamification of user generated content. you see the same thing on imgur and reddit: the well thoughtout comments don't get up voted nearly as much as the memes and injokes.
>I am all for new architectures. But the trick is getting people to make the effort to make use of them.
IIRC at the time there were a lot of complaints against the Cell processor that it was "too hard" to program for. >https://www.cnet.com/news/sony-ps3-is-hard-to-develop-for-on...
>https://www.gtplanet.net/playstation-3-cell-more-powerful-mo...
>https://www.gtplanet.net/the-ps3-era-was-a-nightmare-for-pol...
>What can be achieved that is not possible or is price compatible with something boring and old-fashioned like 128 x64 cores etc
That's probably the main issue today, x86/64 are cheap and nearly all the problems can be fixed in software. Changing architectures and instruction set is too big of an upfront cost for most people/companies to deal with, and I think that is why we're only seeing Google and Amazon starting to look for other solutions. >https://aws.amazon.com/ec2/graviton/ >https://www.google.com/amp/s/www.wired.com/2017/04/building-...
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#15I think it's interesting to compare this to a dual 64 core AMD system (so 128 cores) or similar in terms of the programming model or performance.
If it's going to be compared to something though, I think a GPU would make much more sense.
Re: A Look at Celerity’s Second-Gen 496-Core RISC-V Mesh NoC
#16Earlier quoted context omitted.
I know that its a different architecture. The question is whether it's worthwhile to adapt that new programming model and architecture? What can be achieved that is not possible or is price compatible with something boring and old-fashioned like 128 x64 cores etc. I am all for new architectures. But the trick is getting people to make the effort to make use of them. I think that when I write a good comment it gets bu…
>I think that when I write a good comment it gets buried and the only time comments are really popular is when I write something trite or silly that a lot of people are already thinking. probably more to do with the gamification of user generated content. you see the same thing on imgur and reddit: the well thoughtout comments don't get up voted nearly as much as the memes and injokes. >I am all for new architectures…
Indeed. Interestingly GPUs were initially very hard to program (and still are kind of a pain). What made them viable was the introduction of practical development tools that Cell never had. This machine shares (some of the) instruction set between the fat and the puny cores, which makes it a much easier target to program.