Hacker News Reader

Comment by throwawayish | Hacker News Reader

It's completely unreasonable to expect some underdog architecture to get anywhere close to the big ones, which have pured dozens of billions of dollars into research over decades to optimize their designs, tooling and fabrication.

A reasonable expectation is to get some low-end-ish CPUs out that might be on the same level (in terms of efficiency) than older, not really optimised ARM designs.

The biggest incentive RISC-V can offer is less legacy bullshit (like AArch64) and the fact that you don't have to pair royalties to ARM. Perhaps better standardisation of peripherals compared to ARM, so less time/money spent on integration, BSPs and stuff like that.

(And even then: Looking at recent POWER one can see that they can outperform related Intel offerings, while being drastically less efficient.)

View on HN

This is a fallacy that I see repeated about the quality of open products all the time.

It's true, Intel spends more money on R&D than RISC-V is likely to ever get. But that means next to nothing. When a huge, monolithic, management-driven company spends billions of dollars on something, a lot of those billions of dollars aren't being used very effectively.

Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev. Does that mean Windows is better than Linux? No; in fact, many people who have to use both would probably say the opposite. Why is Linux the OS of choice for many production applications in tech-savvy industries? It just works better and easier than the high-budget closed competition.

That's not to say that Linux is starved for funding; many large companies volunteer serious man-hours towards Linux development, because they want an open system that competes with (and beats) the crappy license-uncumbered alternative they would have to use otherwise. I expect the same thing to happen with RISC-V.

You also have this phenomenon in the open-source world where you have grad students, researchers, and enthusiasts embarking on ultra-high-risk projects that would never get funded at most companies, but pay off in a big way when they work. Now that we have an open ISA to work with, I fully expect a huge outpouring of automated synthesis software based on clever new ideas that beats the clunky stuff available in industry. We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System)Verilog). Give it some time for the silicon side of things to improve as well.

"We've already seen this happening on the HDL side of things; open-source, research-driven efforts like Clash and Chisel are orders of magnitude better than the crap that industry has been using for years (VHDL and (System) Verilog). "

As someone in the industry, I would have to disagree. I question this every time someone claims it's so awesome. None of those solutions can run simulations on the back annotated netlist . How do you design without a simulation tool that can work at every stage of the design flow?

RTL is a behavioral model. Post synthesis is the physical model. What do you think synthesis engineers do? Just sit around watching the tools run?

> What do you think synthesis engineers do? Just sit around watching the tools run?

Can you explain briefly for someone not in the industry why it's not that simple? This seems like it should be a 100% automatable process.

Things don't just work automatically. Some idiot can throw a design in that doesn't just synthesize.

After synthesis, your RTL becomes a gate level representation. You then place your logic i.e. Your memory logic near your memories, I/O logic near your pins etc. You then make clock trees for your various clocks. You don't want related logic clocked by different parts of the clock tree. Once you have stuff physically located, you back annotate and do your static timing analysis.

You generally run simulation on the different stages of synthesis. Someone has to debug all these simulations. They never just pass.

There is a big difference between RTL and gate level simulation. A test passing in RTL is only the 1st stage. RTL doesn't have any wire models so no delays are in there. Gate level sims can run with delays in there.

Synthesis tools can also tell you it doesn't pass timing through static timing analysis but asynchronous parts of the design can't be analyzed. You need simulation there!

Fully automatic tool flows give lower quality results than tools+trained engineers. Most of the problems are NP-Hard. It's an active area of research.

> Consider Linux versus Windows. My suspicion is that Microsoft has spent more money on Windows dev than has ever been spent on Linux dev.

I'm not so sure about that, if we only consider the kernel (everything else would be a lame comparison). Linux likely has had many more paid devs than the NT kernel for the last 10-15 years, if not more.

> This is a fallacy

I also don't think this is a fallacy. Yes, of course a large company has a big head and spending is generally much less directed and efficient than in smaller companies (big news). But, lots of money also tends to pay great talents.

> that I see repeated about the quality of open products all the time.

... and I didn't mention quality anywhere.

As for open source: Software has near zero initial cost, iterations are extremely fast compared to anything manufactured and software engineering is an abundant skill. Hardware has high initial costs, high manufacturing costs, iterations take a lot of time and HW design encompasses quite some areas with a much smaller pool of people being able to do it.

Also, a massive company like Intel which sucks up talent all the time from the hiring pool has the resources to evaluate multiple avenues of optimization at the same time, pick what looks best, and iterate (which, pretty much, is what Intel has been doing ever since Sandy Bridge). Another example here would be Intel developing P4, a massive and staggering failure comparable to the PowerPC970 debacle (just bigger) -- and then pulling the Core arch out of the hat (which originates, guess what, from a different engineering team in a whole different branch of Intel -- again, resources!).

What I do expect here is that some companies might think they can influence an arch early on by diverting resources to it, to maybe save some money in the future (by not paying ARM anymore and other synergetic effects I mentioned above), and perhaps in the hope of getting a product that outperforms ARM/the competition in some metric(s).

(Also we have seen in the past in quite some instances that CPU design is a very delicate art and even pouring massive monies into it might actually not get you very far - see AIM/PowerPC [although it was quite successful in some niches] - or, on the other hand, that radically new architectures that might theoretically be better don't succeed, because you don't get the fab access, or tooling access, or software, see eg. Transputer and many related examples)

I think you vastly underestimate the amount of money that was spent on Linux by various vendors. All the major companies in that wanted to sell servers or server related software essentially converged on linux as their platform of choice, since then IBM, RedHat, Google, Intel,... probably poured many billions more into Linux than Microsoft spend on the NT kernel.

Do you think a similar series of events are unlikely to play out when you look at the microprocessor field right now? I see similarities in that there essentially are no open source processor options (MIPS is the only one I can think of off the top of my head). Intel, AMD, IBM, TI, ARM, Qualcomm, Oracle, the lot of them are closed source and I would think the same benefits that came with an open source operating system would come with an open source processor architecture.

That said, I think the biggest difference is the parity between OSes in in the 70s vs ARM/Intel's current dominance. That's definitely going to make it more difficult to get people to adopt RISC-V. I'd imagine if there was any likelihood that IBM, RedHat, Google, or Intel could customize a RISC-V chipset to outperform (whether it's TWP, flops/sec, whathaveyou) any current offerings they'd pour dumptrucks of money into it just the same.

> the lot of them are closed source

That's wrong. See OpenSPARC, where you can get the Verilog code for the T1 and T2 (Niagara-based) processors. (IIRC this was only one year after their commercial release).

SPARC in general is perhaps not a bad example, since the ISA is open and royalty-free and there are actually independent implementations (well, today only Fujitsu and ofc. Oracle).

It's quite interesting to see RISC raising again after it died rather harshly in the late 90s -- were literally every year a major manufacturer announced the end of an architecture -- and early 2000s (and remained dead rather firmly throughout the 2000s).

I'd believe this if I hadn't seen Intel pull a magic bunny out of the hat every 5 years for the last 30+ years, and totally decimate the competition.

I've spent my computer hobbyist life betting against Intel and losing -- 6502, 68000, PowerPC.

Well, on the mobile market Intel can't sell a chip if they staple money to it. So its not like Intel can just win everything all the time.

I don't think RISC-V will beat Intel on servers any time soon, I just hope it will establish itself in the market, get a foothold and then hope it openness will help it to grow.

FE310 appears to outperform every state-of-the-art official ARM core (and perhaps every architecture-licensee core) in its class, with maximum stable clock speeds also much higher. BooM could be described as beating Cortex A15 and matching Cortex A53 (granted without a tapeout to prove it, only simulations).

Both of these designs are publicly available and under licenses which allow proprietary derivatives.

In every category; die area, power dissipation, total throughput, licensing cost, lead time, design flexibility, code density, technical debt, academic buy-in; real RISC-V cores which have been made in silicon are right-now beating ARM cores. At this point, ARM has but two things going for it: legacy and design maturity.

Once RISC-V designs are mature enough to be expected to run all general-purpose software correctly; there will be few other axes to compete on. RISC-V has an immense zero-day advantage in its clean, worldly design. I think it would be foolish to downplay the likelihood of great success.

Many of those billions of dollars went into production of chips, which is mostly a generic process where chip architecture is unaffected.

Furthermore, research about architecture of chips has been published and can be used to create faster chips.

But I have to agree that it is not easy. Especially because chip design is partly generated by software and computed by many powerful machines.

What about the architecture/design itself, is any of that open? Could I find a design, send it off to china, and have them print off a couple hundred, even at a much higher price than some other processor?

Uh, well I guess...? But generally speaking IC fabbing doesn't happen in the "couple hundreds". If you really want that, you'd be looking at MPW (multi project wafers), were a bunch of designs are slapped on a single mask to spread yield and reduce per-party costs. (It pretty much works like PCB group manufacturing - a bunch of designs is slapped together 'til the maximum size of the fab, and then that is produced a couple times, e-tested, cut and bad pieces discarded. Everyone gets a couple copies of their design.)

Today it's a bit better, since eg. GF can (in theory) offer recent nodes (eg 22 nm and smaller), which wasn't something you could get ten years ago (back then that'd be 65 nm - most low-volume and custom stuff has been iirc 130 or 180 nm).

Not quite because you have a few more steps in the process after the design phase. For instance, you need to perform testing on the fabricated parts to determine if there are physical defects. That means creating the tests then paying for the testing to be performed at the fabrication place.

Reply on news.ycombinator.com