3 ms·

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

by wyager 10y ago

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.

throwawayish 10y ago
> 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)
cmrdporcupine 10y ago
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.
- nickik 10y ago
  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.
orbifold 10y ago
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.
- roninb 10y ago
  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.
  - throwawayish 10y ago
    > 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).
gluggymug 10y ago
"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?
- kmicklas 10y ago
  > 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.
  - zerohp 10y ago
    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.
  - gluggymug 10y ago
    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!

by wyager 10y ago

throwawayish 10y ago

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

cmrdporcupine 10y ago

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.

nickik 10y ago
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.

orbifold 10y ago

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.

roninb 10y ago
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.
- throwawayish 10y ago
  > 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).

gluggymug 10y ago

"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?

kmicklas 10y ago
> 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.
- zerohp 10y ago
  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.
- gluggymug 10y ago
  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!