Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Tiny Chip That Could Disrupt Exascale Computing (2015)

nextplatform.com

Post reply on HN
Print view View original

31–40 of 57 posts

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

#31

Post by trsohmers »

Keyframe wrote: post #29
trsohmers wrote: post #25

Earlier quoted context omitted.

I would be just as skeptical as you and everyone else should be of our claims. While I have talked informally about our architecture to many people on and offline, we have not posted much when it comes to the actual architecture that we have proceeded with to silicon (which is very close, but not exactly what we will be eventually bringing to market). I don't honestly believe any random person to take us seriously ba…

I wish you and your project all the best. Hardware, and especially CPUs and alike are tough and rare. We haven't seen much new competitors (any) in that area, especially relevant ones. When you say you rest your high hopes on toolchain, aren't you a bit scared of what happened to Itanium? Intel had toolchain under their r&d and it failed because they couldn't deliver. I'm interested to hear more about "mythical 'suff…

Based on our software results so far, I wouldn't say I'm scared, but am definitely anxious. Since our main focus up to this point has been building the first test chip along with software tool prototyping, our progress in compiling "real" libraries and small applications is fairly early, but we're happy with the results. Now that we've taped out, we can devote more resources, and once we have real hardware, we will be able to test our applications ~1000x faster than the cycle accurate software simulation capabilities we have right now.

All that being said, we have good reason to believe that our approach is valid and won't suffer the flaws of "Itanic" that I've mentioned on this page and many times elsewhere. Unlike any prior VLIW (Intel called their bastardized version implemented in Itanium "EPIC"), our hardware was built with an emphasis on hard real time guarantees and strict determinism at every level of the design, which allows for a level of optimization that is impossible on any other architecture.

Basically, if the compiler has to make worse case assumptions almost all the time to prevent control and data hazards (as did Itanium due to a very convoluted design), how do you expect to have any compiler generated programs to be at all performant/efficient?

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

#32

Post by rbanffy »

6d65 wrote: post #8
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…

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.

From what I understood, a lot of the software stack would require rewriting. As it is, it doesn't look like it would be friendly to a Linux environment running natively on it, but could be more amenable to a coprocessor-like environment where the host would load programs and the Neo would run them.

Did I get it right?

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

#33

Post by trsohmers »

rbanffy wrote: post #32
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.

From what I understood, a lot of the software stack would require rewriting. As it is, it doesn't look like it would be friendly to a Linux environment running natively on it, but could be more amenable to a coprocessor-like environment where the host would load programs and the Neo would run them. Did I get it right?

In the near term, yes, though that is primarily a business reason for us. Supporting Linux is technically possible (old projects such as uCLinux were built around running on MMU-less systems like ours; Mainline Linux 4.2 started to have limited support for a couple of MMU-less systems), though our target areas (HPC and DSP-like tasks) don't necessarily need anything more than a microkernel/RTOS. A full OS like Linux kind of gets in the way if you get the basic stuff like memory allocation, garbage collection, and job scheduling handled separately (by our software tools). Since we are a small startup and focusing on a small area, we want to take off a part of the problem we can easily chew, rather than trying to immediately jump at Linux, so we chose our target applications/market accordingly.

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

#34

Post by dewster »

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.

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.

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

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

#36

Post by gpderetta »

trsohmers wrote: post #31
Keyframe wrote: post #29

Earlier quoted context omitted.

I wish you and your project all the best. Hardware, and especially CPUs and alike are tough and rare. We haven't seen much new competitors (any) in that area, especially relevant ones. When you say you rest your high hopes on toolchain, aren't you a bit scared of what happened to Itanium? Intel had toolchain under their r&d and it failed because they couldn't deliver. I'm interested to hear more about "mythical 'suff…

Based on our software results so far, I wouldn't say I'm scared, but am definitely anxious. Since our main focus up to this point has been building the first test chip along with software tool prototyping, our progress in compiling "real" libraries and small applications is fairly early, but we're happy with the results. Now that we've taped out, we can devote more resources, and once we have real hardware, we will b…

Does this means that users have to recompile the world for every cpu generation because of microarchitectural changes? I.e. is the pipeline exposed? Are you planning a Mill-like intermediate level bytecode?

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

#38

Post by gpderetta »

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…

Itanium failed for the same reason every other VLIW failed as a general purpose CPU: there just isn't enough information a compile time to model the dynamic properties of a program. In fact many of Itanium additions (strange instruction packing, alias disambiguation hardware) were attempts at overcoming this issue.

The only moderately successful general purpose VLIW are Conroe and the related Denver, and they use a runtime translation layer to collect the required dynamic informations.

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

#39

Post by trsohmers »

ridgeguy wrote: post #35

I'm curious about the thermal issues. 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. Is this power density a cooling challenge?

First note: The article is ~16 months old, so is outdated on some measures. I've corrected the numbers below, but in either case, you seem to have been confused between the size of a core and the size (and power) of an entire chip consisting of multiple cores.

After tapeout of our first test chip, the final size for one of our cores is 0.27mm^2 (including the SRAM that makes up the scratchpad memory) on TSMC's 28nm process. We actually came in using less gates than originally anticipated, and our size without SRAM is a little less than 0.01mm^2.

Now, for just going by what is on the linked article: The diagram comparing sizes are for single cores (0.1mm^2 estimate back then for a Neo core, 14.5mm^2 for a single Intel Haswell core). The power numbers in the table below that are for entire chips. You are quoting 65W for a single core, which is incorrect... The 65W Haswell chip I believe you may be referring to is the 4770S, which is 4 cores @ 65 watts, and looks like it has a die size of 177mm^2.

Calculating this out using our current numbers, our planned full 256 core chip has changed a bit (doubled the performance since last year, doubled the power due to adding more stuff) and we estimate the TDP to now be 8 Watts and ~100mm^2, which gives us a power density of 0.08W/mm^2. Intel would then have 65W / 177mm^2 = 0.367W/mm^2.

As would make sense in the case where we are claiming lower power operation, our power density is also lower.

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

#40

Post by trsohmers »

gpderetta wrote: post #38
trsohmers wrote: post #9

Earlier quoted context omitted.

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…

Itanium failed for the same reason every other VLIW failed as a general purpose CPU: there just isn't enough information a compile time to model the dynamic properties of a program. In fact many of Itanium additions (strange instruction packing, alias disambiguation hardware) were attempts at overcoming this issue. The only moderately successful general purpose VLIW are Conroe and the related Denver, and they use a r…

The vast majority of the dynamic parts of program that matter for scheduling (both when it comes to ILP/avoiding hazards within a core and when it comes to handling memory management for our scratchpad based memory system) are due to indeterminate latencies for memory accesses and executing instructions (due to variable length pipelines). Throw in horrible (for determinism) things like out of order execution and and branch prediction and no wonder a compiler can't determine things statically! While we are not really targeting general purpose (though I would say we have the capability to evolve to it in the future) it seems painfully obvious to me where these issues have been in any general-leaning VLIW attempts in the past, and I can't understand the clinging nature to bad architectural decisions in the past by hardware folks 30 years ago that could not imagine the ability of software in the future.

Targeting general purpose from the get go is a bad idea, but it NOT impossible to do efficiently and without sacrificing performance. You just need a well defined and constrained architecture, and a clean way to describe it.

Post reply on HN