A Tiny Chip That Could Disrupt Exascale Computing (2015) • Hacker News Board

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#11

Post by white-flame » Mon, Jul 25, 2016, 8:25 AM UTC

trsohmers wrote: post #9

Nomentatus wrote: post #2

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. http://semiengineering.com/power-centric-chip-architectures/ also a speaking engagement: http://insidehpc.com/2016/01/call-for-papers-supercomputing…

You are correct that we have already taped out, though we haven't made any announcements yet, though will be talking publicly about it in the future with a big focus on the "magic" on the software side. You can read my comments on the Mill architecture elsewhere on HN (not a fan of stack machines), but my biggest disappointment in them is the fact that they have been working on Mill for ~10 years with a team ranging…

> while we have gone from a complete custom architectural idea to tapeout in ~11 months from closing our first seed funding.

To my understanding, the Mill project is not financed. They're enthusiasts working for sweat equity, and are likely going to seek (non-controlling?) investment to finally hit silicon when they're ready.

For the scope of what they're doing, I think it's a defensible enough approach. It's not something that can be created in evolutionary stages; all designs of all parts need to be working together properly for there to be benefit from any part, and it's quite complex while also trying out tons of novel designs.

(and the Mill isn't stack-based or stack-related. It's basically a crossbar of recent ALU/Load results being fed into further ALU/Store inputs in parallel. The belt is just some way to represent the set of recent results.)

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#12

Post by trsohmers » Mon, Jul 25, 2016, 8:30 AM UTC

skynetv2 wrote: post #7

trsohmers wrote: post #6

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. We've had some really great progress that we hope to share in the near future, so stay tuned. 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…

have you published any white papers detailing any of the following: architecture, instruction set, software availability, benchmarking / application porting and performance etc. I read a couple of times that you got funding from various govt agencies. Most of these funding agencies publish rfp responses or slide decks unless you insisted on an NDA and was approved. I couldnt find any documents talking in depth about…

We'll be releasing a whitepaper by September covering the architectural basics, which will coincide with a public release of a SDK. We did have a paper[0] at last years Memsys conference that goes over some of the basic ideas of our compiler, though it is pretty vague (due to our reluctance to share prior to having patent protection at that time).

[0]: http://dl.acm.org/citation.cfm?id=2818966

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#13

Post by joshu » Mon, Jul 25, 2016, 8:35 AM UTC

trsohmers wrote: post #10

6d65 wrote: post #8

Earlier quoted context omitted.

Is it possible to get a Developer Kit for it? It would be great if there would be some raspberry pi like distribution with a Chip included. I think this could speed up the adoption.

We'll send an announcement on the mailing list when tools (software based and FPGA based simulation, along with actual silicon) will be available. We will only be getting 200 chips back from this initial test run, so we have to be fairly stringent in who will be getting hardware eval units in the coming months, but if you have a compelling application idea, feel free to send me an email (in my HN profile) and let me…

I am looking forward to hearing how this goes.

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#14

Post by trsohmers » Mon, Jul 25, 2016, 8:37 AM UTC

Nomentatus wrote: post #4

smaddox wrote: post #3

Earlier quoted context omitted.

Yeah, something like this is very much needed, but it's not the hard part. The software is the hard part. The software is the reason we have the multiple levels of cache we have now. Without solving the software challenges, there can be no challenger for the existing architectures. It's interesting to note that convolutional neural nets (CNNs) are one solution to the software challenge. It's an imperfect solution, in…

True. I shoulda added "so to speak", since this is a still more extreme approach and might simply break any compiler/language combination we have, as you say.

While we have been exploring some ideas on how to have better programming approaches to address the unique features of our architecture, we have from the beginning though that we would be required to have some level of portability for existing applications. As of right now, we support standard C/C++ that runs through our Clang+LLVM backend, with the ability to support any language that has a LLVM frontend.

Personally, I find the actor model to be the easiest existing way to take advantage of things like our network on chip and having hard time guarantees on memory movement. That being said, right now our focus is on C and C++ along with our API and custom library ports.

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#15

Post by dnautics » Mon, Jul 25, 2016, 8:38 AM UTC

smaddox wrote: post #3

Nomentatus wrote: post #2

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. http://semiengineering.com/power-centric-chip-architectures/ also a speaking engagement: http://insidehpc.com/2016/01/call-for-papers-supercomputing…

Yeah, something like this is very much needed, but it's not the hard part. The software is the hard part. The software is the reason we have the multiple levels of cache we have now. Without solving the software challenges, there can be no challenger for the existing architectures. It's interesting to note that convolutional neural nets (CNNs) are one solution to the software challenge. It's an imperfect solution, in…

Having written programs for this iteration of the REX Neo architecture, the architecture is not so dramatically different that programming languages will have to be rewritten. I'm not the smartest programmer in the world and I was able to figure out the assembly language fairly easily.

Some concepts, like how to manage concurrent data processing and thread communications, need to be handled carefully, but that's more at the level of 'standard library' than the compiler. There is a clear pathway to getting C working on the architecture, and a reasonable direction (that will need some fleshing out) to getting performance-enhancing optimization of something like LLVM IR.

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#16

Post by trsohmers » Mon, Jul 25, 2016, 8:43 AM UTC

joshu wrote: post #13

trsohmers wrote: post #10

Earlier quoted context omitted.

We'll send an announcement on the mailing list when tools (software based and FPGA based simulation, along with actual silicon) will be available. We will only be getting 200 chips back from this initial test run, so we have to be fairly stringent in who will be getting hardware eval units in the coming months, but if you have a compelling application idea, feel free to send me an email (in my HN profile) and let me…

I am looking forward to hearing how this goes.

I'd be happy to give you an update. Shoot me an email if you want to catch up.

Also: Looking forward to see more in the self driving car racing ;)

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#17

Post by white-flame » Mon, Jul 25, 2016, 8:53 AM UTC

dnautics wrote: post #15

smaddox wrote: post #3

Earlier quoted context omitted.

Yeah, something like this is very much needed, but it's not the hard part. The software is the hard part. The software is the reason we have the multiple levels of cache we have now. Without solving the software challenges, there can be no challenger for the existing architectures. It's interesting to note that convolutional neural nets (CNNs) are one solution to the software challenge. It's an imperfect solution, in…

Having written programs for this iteration of the REX Neo architecture, the architecture is not so dramatically different that programming languages will have to be rewritten. I'm not the smartest programmer in the world and I was able to figure out the assembly language fairly easily. Some concepts, like how to manage concurrent data processing and thread communications, need to be handled carefully, but that's more…

I wouldn't expect the assembly language level to be too far off from the common paradigms. Where I'd expect the software challenges to be would be in managing large amounts of memory, if the application programmer must manage shuffling data between the local scratchpad, specific locations in foreign scratchpads that must be (manually?) DMA'd around, and DRAMs.

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#18

Post by trsohmers » Mon, Jul 25, 2016, 9:02 AM UTC

white-flame wrote: post #17

dnautics wrote: post #15

Earlier quoted context omitted.

Having written programs for this iteration of the REX Neo architecture, the architecture is not so dramatically different that programming languages will have to be rewritten. I'm not the smartest programmer in the world and I was able to figure out the assembly language fairly easily. Some concepts, like how to manage concurrent data processing and thread communications, need to be handled carefully, but that's more…

I wouldn't expect the assembly language level to be too far off from the common paradigms. Where I'd expect the software challenges to be would be in managing large amounts of memory, if the application programmer must manage shuffling data between the local scratchpad, specific locations in foreign scratchpads that must be (manually?) DMA'd around, and DRAMs.

Our whole goal, as talked about in the software section of our website (and the ACM paper linked in it), is to have the scratchpads be entirely automated by our toolchain. While we want to allow for especially adventurous programmers to have full freedom with the scratchpads, existing and future programs written in C/C++/other languages supported in the future will handle memory allocation identically (from the programmers perspective) as existing architectures.

One other thing to point out is that our actually addressing of a cores local scratchpad, as well as "foreign" scratchpads of other cores on the same chip and/or any other attached chip is handled exactly the same. All memory operations are handled through the exact same load/store instructions as part of a global flat address map that is the same for all cores in a system (one or multiple chips interconnected).

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#19

Post by 6d65 » Mon, Jul 25, 2016, 9:23 AM UTC

trsohmers wrote: post #10

6d65 wrote: post #8

Earlier quoted context omitted.

Is it possible to get a Developer Kit for it? It would be great if there would be some raspberry pi like distribution with a Chip included. I think this could speed up the adoption.

We'll send an announcement on the mailing list when tools (software based and FPGA based simulation, along with actual silicon) will be available. We will only be getting 200 chips back from this initial test run, so we have to be fairly stringent in who will be getting hardware eval units in the coming months, but if you have a compelling application idea, feel free to send me an email (in my HN profile) and let me…

This sounds good. One of the big problems with Mill CPUs is there is that they don't have working silicon yet. I would say getting as much people as possible to play with it, is crucial for a new architecture to get traction.

Even better than that would be a open architecture like RISC-V. Though, open architecture has its own drawbacks.

Also, as a side note, what do you think about the possibility of using Genetic Algorithms and Machine Learning to generate more efficient types of interconnect architectures.

Re: A Tiny Chip That Could Disrupt Exascale Computing (2015)

#20

Post by amelius » Mon, Jul 25, 2016, 10:35 AM UTC

> 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.”

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?

Also, I think it is more useful and fair to compare against a GPU than a general purpose CPU.

(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.)