Founder of REX here, and surprised to see this posted here. Happy to answer any questions, and you can check my comment history for some of my prior posts on REX.<p>We've had some really great progress that we hope to share in the near future, so stay tuned.<p>EDIT: Since this article is over a year old, we have made a lot of progress, and have recently taped out our first chip. We haven't officially posted a job opening, but we are very shortly going to be looking for software engineers that would love to work on our architecture. Feel free to shoot me an email if you're interested!
From the article: “Caches and virtual memory as they are currently implemented are some of the worst design decisions that have ever been made,” Sohmers boldly told a room of HPC-focused attendees at the Open Compute Summit this week.<p>As a lay processor designer, I couldn't agree more. I don't like VLIW, but this architecture makes a lot of sense. I think it took up to this point for compiler technology to catch up with what is possible in hardware.<p>Almost all the good ideas in computing were mined out long ago, the trick I think is to get the computing world to give up on those which are holding things back (cold dead hands if necessary).
This is a 2015 story that I remember reading, then. Google news search shows only a couple articles this year about Rex Computing and only one tiny bit of news, that they're at tapeout. That's probably par for the course for a startup creating product (or prototype) one.
<a href="http://semiengineering.com/power-centric-chip-architectures/" rel="nofollow">http://semiengineering.com/power-centric-chip-architectures/</a><p>also a speaking engagement:
<a href="http://insidehpc.com/2016/01/call-for-papers-supercomputing-frontiers-in-singapore/" rel="nofollow">http://insidehpc.com/2016/01/call-for-papers-supercomputing-...</a><p>and a comment elsewhere that mentions another approach: the "Mill CPU of Mill Computing"<p>As I recollect (perhaps quite wrongly) Itanium (VLIW) failed because compiler-writers couldn't really be bothered or couldn't mount the learning curve. So I'm most curious about what progress is being made on the compiler side.
> there is no virtual memory translation happening, which in theory, will significantly cut latency (and hence boost performance and efficiency). This means that there is one cycle to address the SRAM, so “this saves half the power right off the bat just by getting rid of address translation from virtual memory.”<p>In protected mode (i.e., what the kernel is using), will an Intel processor not also disable virtual memory lookup? Couldn't we just recompile scientific software to a protected mode environment to get those same benefits?<p>Also, I think it is more useful and fair to compare against a GPU than a general purpose CPU.<p>(As an aside, I don't see where the reduced latency gives such a big advantage. There will be latency anyway, so in any case your software has to deal with waiting in an efficient way (doing useful stuff in the mean time). Shaving off some latency will only help if your software design was bad to begin with.)
It would just be great to get in a decent chip that does not have built in, and unblockable, back-door hacking, like those on Intel, AMD and probably ARM.
I'm curious about the thermal issues.<p>From the article, the power density is (4 W)/ (0.1mm^2), or 40W/mm^2. Intel's Haswell chip has a TDP of ~ 65W, an area of 14.7mm^2, for a power density of 4.4W/mm^2.<p>Is this power density a cooling challenge?
This chip was discussed on RealWorldTech a while ago: <a href="http://www.realworldtech.com/forum/?threadid=151566" rel="nofollow">http://www.realworldtech.com/forum/?threadid=151566</a><p>Let's say it wasn't well received.
There is nothing to disrupt. Exascale computing is a haux perpetrated on the US government by unscrupulous hardware vendors. Kudos to Rex for grabbing a piece of that action.