The problem is less about openness itself and more about quality of auditing. Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us.
But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore or sweep under the rug if it's inconvenient to business.
I'd pay good money for an open and simpler platform to run my security-critical tasks that don't require top performance. Auditing a modern high-end CPU is probably a huge task even if you have access to the HDL because of how complex they are. A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web, send emails and do 99% of my daily tasks except maybe compile C++ or Rust code.
The problem of course is that it's probably a very niche market at the moment. Most people probably don't really understand what's at stake and might not even care either way. As such I don't expect that people could manufacture open CPUs and sell them at a reasonable price. So you'd end up with overpriced, under-powered CPUs which won't drive adoption.
I can't imagine such a project being successful if it's not backed by a big company or a government. I kind of wish the European Union would try its hand at it, after all computing is absolutely critical these days (and it's only going to get more critical as time passes) yet we're completely dependent on american and chinese companies to provide us with CPUs. If the EU thought that Galileo was worthwhile to have our own positioning system certainly it also makes sense to have our own CPUs for critical tasks?
IA-64 (https://en.wikipedia.org/wiki/IA-64#Architecture) already exists, with its explicitly parallel instruction set, which leaves branch prediction and speculative execution up to the software. So you can still get many of the performance benefits, but it's under control of the software, giving a lot more flexibility for being able to mitigate or eliminate these kinds of issues.
I think that it was probably introduced ahead of its time, and targeted at the wrong markets, but it's kind of sad that with the Spectre vulnerabilities, we don't have any way of comprehensively addressing it in software without jumping through a lot of hoops and applying microcode updates.
IA-64 was a dumpster fire. The halting problem is unsolvable. You can't schedule branch prediction absolutely. You have to have information about the current running program. Branch prediction, instruction re-ordering, and speculative execution are to hardware what a JIT is to software (roughly speaking).
Unfortunately, from a security perspective, moving those things to software doesn't make the vulnerability go away. You can have the same vulnerabilities in your software implementation.
From a performance perspective, we have no general solution to parallelizing a serial program. GPUs used to be VLIW. AMD switched from VLIW-5 to VLIW-4 because the average width was only ~3.5 (Nvidia had switched from VLIW to SIMD long before this). Today, Nvidia and AMD both use a MIMD threaded approach to execute on SIMD units.
Later-generation Itanium chips wound up including branch predictors and speculative execution. From what I understand, under the hood, they were normal RISC-style processors (like all the x86 micro-arch are today). Just ignore the VLIW and run one set at a time serially with the ILP hardware optimizing as it goes.
In today's programs, the programmer specifies data-level parallelism where possible (and if necessary, re-adjusts the code so the compiler heuristics recognize it as optimizable). The compiler then tries its best to detect the parallel data and use SIMD and organize instructions so that the parallelizable ones are closer together (so they fit in the CPU reorder buffer). When they hit the CPU, it examines the code as it runs to optimize speculative execution and uses the reorder buffer to make efficient use of its computation units (load, store, ALU, FPU, SIMD, etc). You move from explicit to implicit-ish (you know that putting similar instructions will optimize in all modern processors), but don't have the drawbacks of noop code bloat or having to compile different code when someone changes from VLIW-2 to VLIW-3 code.
The unsolvability of the halting problems means that it is impossible to have a general algorithm that makes non-trivial statements about the behavior of a given program.
In the context of IA-64, that means that generally, the compiler will not be able to determine when it's save to use parallelism. We can only program it to use parallelism in a bunch of special cases for which we think it will be safe.
Given that simias originally asked for a simpler platform that we can trust in more, this seems to be a pretty strong argument that IA-64 is not that architecture.
If you're not only concerned about bugs but also about people inserting backdoors into your hardware it's not enough to have access to the architecture design, you want to be able to publicly audit and review the entire manufacturing process (to make sure that the design you audited is actually the one etched on the silicon). I doubt Intel & friends would open their high-end fabs to public scrutiny so I think you'd have to use older technology available "in the open". For this reason alone I don't think a truly open processor could compete directly performance-wise with the current high-end CPUs regardless of architectural choices.
If you're looking for relatively high and deterministic performance maybe Project Denver, the descendant of the Transmeta's Efficeon, would be a better choice? Of course the binary translation has tons of potential for introducing bugs but since it has an exposed pipeline the translation software would have an easier time guaranteeing you wouldn't run afoul of Specter. NVidia's incarnation seems about as fast as an A57 which isn't great but isn't peanuts either.
I think this is overlooking how unpopular IA64 was.
"Leaves branch prediction and speculative execution up to the software" means that in practice you need to either use the Intel compilers or hand-optimise your software to get the benefits, while simply recompiling your legacy software with GCC or LLVM ends up being disappointingly slow.
Oh, yeah, I'm aware of many of the reasons that IA64 failed.
Intel could have solved this problem by contributing to GCC and LLVM instead of keeping their optimizations proprietary. Then they would also be more easily auditable as well.
> instead of keeping their optimizations proprietary
There were no magic secret optimizations to release. It just straight up did not work. They had to add back dynamic branch prediction, and even then the load store latency was such trash that they had to put ginormous L3 caches on it to get even close to reasonable performance.
That's fair. I have never worked with them, so I don't know the precise details; but one of the big complaints I've heard was that compilers weren't ready for them yet, while these days there's now a larger field of open source compilers and has been a lot more research in parallelism.
Yeah, compilers today are no better. We found the limits of statically scheduled parallelism pretty fast. On code that uses static scheduling, a modern OoO processor can easily duplicate what IA64 was capable of (and a pipelined loop using AVX will utterly smoke it), while being far better at all the stuff IA64 failed at.
One big problem was the epic power consumption of the Itanic CPUs.
I remember going to a corporate presentation by Intel about the revolutionary CPU architecture. They had to turn the machine off because the cooling fan was making so much noise we couldn't hear the speaker.
And this at precisely the wrong moment in history, as mobile devices, with their stringent power consumption constraints, were becoming popular.
You're giving up on a ton of performance by dropping OoOE.
In particular, you end up losing the ability to avoid stalling on cache misses, and the memory wall becomes an increasingly gigantic problem even as Moore's Law progresses.
No, SMT techniques only help with throughput, not single threaded execution latency. Furthermore, if you have no OoO, then it's very likely that both threads will suffer a cache miss. Plus the overhead of SMT is very similar to just having two cores. Modern CPUs reuse much of their OoO circuitry for SMT, removing OoO means that SMT has greater relative overhead. (I can dig up the relevant papers if anyone's interested)
We don't need to give up on performance, even with low-performance RISC-V chips. What we need is a new architecture which takes advantage of low-speed multicore processors. If it is possible to produce thousand-core RISC-V chips [1] then any core could be assigned a single thread - which implies that there is no need for a complex multitasking OS.
[1] Towards Thousand-Core RISC-V Shared Memory Systems (PDF)
To get into trouble you have to be able to resolve one load and launch a new dependent one before the second load is quashed by the branch resolution. There exist in order pipelines that allow that, the Cortex-A8 for example, but they're pretty rare.
I'm just pointing out that Itanium had dynamic/hardware branch prediction and it's not necessarily immune to Spectre type exploits. As you mentioned, there are in-order scoreboarded pipelines that allow things like that, so dodging OoOE is not necessarily a perfect panacea.
I'm not sure exactly what would have been the right markets, but I think that something where legacy compatibility is less important and being open to experimentation and new software designs is more important. So, things like consoles (going up against things like the Cell processor), HPC, or maybe even the embedded space (tablets, etc), rather than trying to use it for the enterprise market as Intel and HP did, where running legacy pre-compiled applications is a really important use case.
Game developers are not at all open to experimentation, only adopting new languages or architectures when vendors force them to move forward.
PS3 with Cell would have been a failure had Sony not eventually caved in, and released a PS3 SDK that made most of the work Sony was initially expecting devs to do, regarding low level programming.
State actors and the EU are not reliable actors insofar as security that goes beyond their own needs is concerned. They will put backdoors and key escrow into the systems.
That's the real problem with an open platform, whether it's about hardware or about software. To get enough funding, support, and manpower an open secure platform initiative would have to get entangled with global players that simply do not have the ultimate privacy and security of all citizens in mind. It's primarily a political issue.
It's not a worthwhile project when 99% of your vulnerabilities are in the software and nearly all of them need you to run untrusted software to be exploited.
"Browsing the web" is not likely to become a task that can satisfy high security requirements ever again. Too much cruft gets added to browsers faster than it can be thoroughly audited.
If you need absolutely no CPU bugs (including bad design decisions "working as intended"), take a well-understood, possibly older design like 680x0 or MIPS and run it on an FPGA.
The approach is helpful, perhaps not very practical (do I maintain N different browser installations in my qube for N different tasks, or is it a single installation where malware can therefore affect all qubes?). But remember that OS and libraries have plenty of bugs too.
I suppose that an OS running transparently on an actual cluster of many independent cores, not linked even by a common L2 cache, could allow to separate security domains much more reliably.
Single-thread performance would suffer, though, unless you're ready to pay quite a lot. And it's still hugely important in many cases.
> A simpler design (RISC, no out-of-order execution, basic branch prediction and prefetching...) ought to be fast enough with modern lithography to browse the web
I used a couple of Single Board Computers as my main computers for a while a couple of years back and it was really quite painful. Especially web browsing.
Yeah I actually considered that while writing my original comment, it's true that even on a low-end smartphone nowadays browsing certain websites is extremely frustrating. That being said is it really reasonable that the modern web requires multi GHz CPUs, GB of RAM and allowing a turing-complete scripting language everywhere to be able to browse most websites? Is it reasonable that the web is so complex now that effectively nobody but a few giant companies can invest the time and resource to write and maintain the millions of lines of code of a modern browser?
Because not all webpages are meant to be applications. HN need not be an application. Google search results need not be an application. GMail and Facebook might be for better interactivity. At least 90% of the websites I browse everyday are static text with a few pictures (who still feature copious amounts of javascript to work around the limitations of HTML/CSS and to track me and serve me ads).
Would you consider installing and running dozens of random untrusted 3rd party applications every day on your real OS even if they were (somewhat poorly) sandboxed? Because that's what the modern web is like.
I wouldn't mind opting-in to additional "interactive" features for webapps that I want to trust but having everybody (including 3rd parties of 3rd parties of the website I'm browsing) run code on my computer when I'm on some random webpage is just insane when you take a minute to think about it.
HN is fast enough on an old 600MHz A8 processor from 8 years ago. In fact, multimedia aside, basically every static site that doesn't overdo the CSS will be fairly fast on fairly old processors.
Gmail or Facebook aren't the problem. People could be convinced to use desktop apps for them fairly easily (just like they do on their phones). The issue is all the other one-off apps. Users can't be bothered to go and download some random app, so the company runs that app in the browser. You simply cannot fight that level of market pressure.
The web (by that I mean most browsers and most web pages) is designed for hi-end devices. Text-based browsing also ought to be possible, but often doesn't work well in practice because it's not a common use case, and so it's not something that developers consider in the design process.
There are many open source processors that are available for synthesis on FPGA's (see opencores.org). The cost/effort of deployment is just much higher.
ARM recently mentioned working on IP that you could turn off features to increase security. Probably will eat little silicon, so could be cheap.Intel may copy.
And since it's ARM, it's at least half-open.
Cloud providers will be interested - slower cpu's = more money, plus selling the cloud as a more secure option to your data center.
And once you have a cpu that with a hardware switch can become more secure but slower, maybe there's a decent enough niche somewhere.
China is invested in almost everything. Phytium or Rockchip for ARM (large and small respectively). FeiTeng Galaxy FT-1500 runs openSPARC. ShenWei Sunway series runs Alpha. Suzhou PowerCore runs openPOWER. I can only imagine they have a bunch of work going into RISCV too.
You used to be able to buy Lemote Yeeloong notebooks, which in addition to having Loongsong processors had completely free software BIOS, making them one of the only RMS approved pieces of hardware. But I'm not seeing those readily available any longer.
AFAIK, Indian govt is supporting research for RISC-V based CPUs, but they are not general purpose, but meant to decrease huge import spending on processors for embedded systems and other specialized requirements.
As you said, 99% people don't care about security. It's hard enough to get people to use ddg over google, making them use open source processor thats likely slower and costlier would be practically impossible.
ARM is a UK company isn't it? Also, minor electronic manufacturers like STM are still around in europe, I think. No big foundries but it seems there is enough competition to survive a shut off of a single partner, unlike the GPS case.
I think this is the first time I've heard advocated that a government should be in the business of chip design. We're a long way from the days of John Locke and enlightenment liberalism.
I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open.
Linux and Windows have drastically different designs, based on how they grew up. Early Mozilla releases were open-source, but still "bore the scars of many rapid cycles of closed-source development" [https://en.wikipedia.org/wiki/History_of_Mozilla_Application...]. From the recent news, it seems that StarOffice is finally becoming somewhat hackable for us mere mortals (who don't speak German). It's the process, more than the license. An open license enables an open process.
"Magic bullet" implies you've got something evil (x86, with bugs!) and want to magically transform it (x86, with no bugs?), but nobody is proposing that. It sounds more like they want to put Conway's Law to work for us (e.g., RISC-V).
> I think there's a huge difference between "take an existing system design, and declare it open" and "design a system in the open". This article isn't suggesting Intel make x86 open to all, for example. You get a completely different design when something is designed behind closed doors as a black-box product, versus designed in the open.
I don't - I believe there are an insufficient number subject matter experts conversant enough in processor design to provide the depth of auditing needed.
I'm not saying openness is good or bad (its usually good) just that its not a panacea here.
Exactly. Being open makes things easier to audit, and to an extent encourages better due diligence (as embarrassments due to silly mistakes or, worse, attempted cover-ups, are more public!), but it doesn't enforce this in any way nor does it guarantee quality or completeness.
The point here should be about responsibility. When I screw up something that I picked up from "out in the open", eg. my server deployments, it more technically makes it my own fault. I am therefore more inclined to study an open circuit design because if it fails on me, I'm only left with myself to blame.
...and if I in fact identify any shortcomings, I can help others not to get hit by them, which makes the concept of openness "safer" in a way that is the sum of collective knowledge.
I just noticed my argument has analogies to Eric S. Raymond's argument about the cathedral and the bazaar.
I'd actually love to see a bazaar on the cpu side of things, be it just for the sake of what community efforts can achieve as opposed to the current mostly proprietary ecosystem.
Fortunately as we saw from the OpenSSL debacle a while back, often deep corporate pockets (like Google) will step up and audit/patch these projects. Being open is obviously a pre-requisite for that to happen.
The risk of speculative updates to branch predictor and page tables was known to the research community for a while. Even if it was initially an unintentional bug, they had plenty of time to take precautions against it by prohibiting speculative updates.
Pretty much. Everything you needed to figure this out was public.
Just publishing stuff doesn't help much in areas this complex and specialized where there are a very small number of people who can really understand what is published.
There is also a major difference between reading a spec and discovering an exploit through an adversarial process.
Nobody who had complete access to confidential data (at Intel or anywhere else) figured this out. People on the outside working with an adversarial process did.
The adversarial process is driven by testing not documentation. There is no reason to think that the people who figured it out would have been aided by having more internal documentation.
As I understand it, according to an article that was posted here a day or two ago, Meltdown was in fact discovered by a young Google engineer poring over the x86 manual.
>Open isn't a magic bullet. As I understand, these latest CPU vulnerabilities were in the spec themselves. You could've found them by reading the manual. See what good that did us.
How about, discovering it? That's one of the points of openness, not somehow being inherently better in a way. At least we have a spec manual in this case.
Also, audits should be peer-reviewed, that's difficult without openness.
>As I understand, these latest CPU vulnerabilities were in the spec themselves.
And yes, 20 years ago Intel was called out for that. In a narrow circle of electronic engineers specialising in CPU designs, this quirk was a know source of worries.
No the vulnerabilities could not have been found by reading the manual. The researchers had to reverse engineer how branch predictor aliasing works for example.
I recommend reading the Google project zero blog post on them - they're easy to follow.
"open isn't a magic bullet" yeah, but closed is a harmful pattern. Open isn't about everything magically getting better, but when you do close development of something that potentially influences billions of people, it's an invitation for disaster. We do not want open because we like open, we want open because we are afraid of closed.
and just to be clear, the least whatever you are doing in a closed format affects people the least i want it to be open.
They work on their collection of processes to produce these things, as to basically have non-proprietary way to produce chips from scratch. The other thing I know is that the guy at least has been involved in other layers of production, namely generation and validation of circuitry.
The website I posted links a few pdfs for more info.
I think the challenge will ultimately be the scale and price at which open processors would be available at for the target market. It isn't just a processor, but will potentially need a motherboard, chipset, and various hardware configurations depending on the customer.
There would need to be significant player buying these processors to make them viable for some smaller entities to be able to piggy back and purchase as well.
Open does not mean better. This is not how our world works. Would be nice to have but I assume every Intel chip I can buy (even with the throtteling) will be more powerful and cheaper than any open processors. There is also much more than only architecture this thing (this works in software but not in hardware)... this would only work if a big player like AMD or Intel jumps on this ship (but it would be like giving away intellectual property).
For me this is an extreme view. If your security demands are that high I'm sure you will find even nowadays CPUs which are in that level of "trustworthyness" you want. One funny example: You can use a Raspberry Pi which is not affected by Meltdown or Spectre ;) https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
I understand that security is difficult, and that one can never be completely secure.
But is wanting to know what my processor is doing, or wanting it to be free of undocumented, obfuscated, proprietary code that runs at a higher priority than any software, really that extreme a view?
We base so much of human progress on these little wafers of silicon, it shouldn't be extreme to want to know what they do.
>We base so much of human progress on these little wafers of silicon, it shouldn't be extreme to want to know what they do.
Well said. I'll add that security is a threshold, and that computer systems are extremely complex. Every bit of openness -and the verifiability such openness affords- brings us closer to that ideal secure system.
Agreed, but for critical applications it might be appropriate.
> If your security demands are that high I'm sure you will find even nowadays CPUs which are in that level of "trustworthyness" you want. One funny example: You can use a Raspberry Pi which is not affected by Meltdown or Spectre ;)
Having the level of verificability the parent asks for is a lot more than "not affected by Spectre", and the Raspberry Pi is not very open in that regard.
> However a processor with verifiable functionality has value. It's more trustworthy. It can be checked for accidental, or deliberate, security flaws.
Is this tractable for a chip with billions of transistors? I would think the people qualified for this already work at chip companies and are doing the work for a stable salary.
What exactly is better, then? Certainly, the idea that "more powerful and cheaper" is better has its basis in a particular use case as much as "open" does. If you read the article instead of soapboxing based on the headline you'll find no argument for that open is somehow better, and acknowledges some of the glaring challenges, including cost and that it's not somehow as simple as building software.
More powerful, probably. Cheaper? Ha ha ha! Intel has huge margins on its desktop processors. Until Ryzen they were basically a monopoly and set their prices to be very high. Look how much they dropped them after Ryzen.
Risc-V is going to allow extremely cheap processors. They will probably not match Intel's single thread performance ever though.
I hope you realize that in the silicium industry scale has a huge impact on price. Unless an open processor sells as much as an Intel or AMD model, it will certainly cost more.
Remember heartbleed... While open cpu is a great idea, it's hard to say that an open cpu would have avoided the meltdown or spectre problem.
The meltdown/spectre vulnerability was there not because people didn't pay attention, it's because nobody thought of these optimization features as potential vulnerabilities. And honestly it's hard to blame anyone, these were really smart hacks!
>Finally, even if we end up with entirely open processors, that will not bring an end to vulnerabilities at that level ... Open hardware may give us more confidence in the long term that we can retain control of our systems, but it is certainly not a magic wand that will wave our problems away.
The author is arguing more from a freedom/control perspective from what I understand. When it comes to these kinds of vulnerabilities, an open CPU might be easier to patch or easier to disable the affected components of.
Apart from that, maybe crowd-sourcing and open-sourcing the eventual fix is faster or better than a private org. That doesn't necessarily seem like something the author is saying, but it seems like a reasonable factor to consider. I can see arguments either way that I'm not really qualified to defend.
Past time, but progress on the riscv front is amazing. If prototype-scale fab got cheaper I expect we'd see a wave of parts focused on security and auditablity in short order.
The problem isn't that you can't fab for mass production, it's that development costs are very high to get there. Working on an fpga only gets you so far.
I was under the impression that for process nodes you would reasonably use for small smart appliances the fab cost is too high, and certainly not high enough that nobody would pick up the tab if the gadget makers would start to require open IP for their IoT / smart appliance offerings.
There are, and have been a few CPU/MCU upstarts that have actually done shorter runs of silicon, and while they are usually quite well funded, the numbers doesn't seem to be prohibitive at all.
If the need was there for it NOW, fabbing something with existing open ip is quite likely to be 'free money' (or free market share), as the semiconductor industry appears to be entrenched with ip licensing so much that I sincerely doubt that they would be quick to follow suit. If only because any open offering from them would be seen as detrimental to market dominance, and lower the value of ip cross licensing deals.
Unfortunately I don't think the market need is there, and won't be for quite some time. I would love to be wrong though.
Shuttle service costs for small runs of silicon are, for most people in most situations, tens of thousands of dollars at a minimum. My argument is that if the price dropped to the point where it was competitive with FPGAs at prototype scale (eg, 10 parts might cost $1000 but not $10000) then you would see parts on the market built that way quite quickly. I think the proof for that is the number of low volume commercial parts (HSMs, LTE base stations, etc) which carry FPGAs today. Seems the market has already spoken?
I know that there are probably a billion technical hurdles for this, but in my perfect universe, CPUs would all be FPGA based; at that point, couldn't updates be almost as simple as a software update?
I know that laws of physics kind of preclude this idea, but a guy can dream.
I appreciate what you're saying, but for devices with long lifetimes things may not be so clear. Consider a wifi device with a >15 year lifetime. Let's say such a device was built with SDR and FPGA, it conformed to 802.11b, and it used twice the power of an equivalent ASIC design. But 15 years later, this device was able to upgrade in software to 802.11ac, and so it was able to take advantage of spatial multiplexing and higher-order modulation to lower its power usage. So now this device uses twice as much power as an equivalent 802.11ac ASIC, but maybe it's more power efficient than that 802.11b ASIC from 15 years earlier.
I guess what I'm saying is that by allowing a device to upgrade in software to more power-efficient designs, you might claw back some of the efficiency lost by using an FPGA when you consider the entire product's lifetime.
> I guess what I'm saying is that by allowing a device to upgrade in software to more power-efficient designs, you might claw back some of the efficiency lost by using an FPGA when you consider the entire product's lifetime.
That presumes you put in a big enough FPGA/CPU or whatever fifteen(!) years in advance that has enough resources to handle the increased processing requirements for a future protocol (expensive and wasteful and there's no guarantee that you didn't guess wrong and it's still too small/slow) and that your RF signal path was designed well enough to handle the new signal requirements (expensive and wasteful even if you were prescient enough to guess what future requirements were). And that's on top of the fact that inexpensive electronic devices simply aren't built with components rated to last 15 years.
Even if all of this works, there is still another issue: a potential rebound effect. If mobile phone software has taught us anything, it is that when updates become cheap, we start getting goodness-knows-how-many patches every other month or even week.
How much bandwidth is wasted on redownloading app "updates" every week that represent a few lines of code change?
... huh, I wonder is that is what happened with DNA and those jumping genes.
Sincere question: how much of that is inherent to FPGA systems, and how much of that is due to them being a niche technology used in contexts where there power consumption is not a big issue, meaning that there has not been a significant drive to reduce power consumption?
I mean, it's not like the other types of electronics are inherently energy-efficient either: before it affected battery life people didn't care that much about energy-efficient CPU's. The current drive for more computation per Watt is largely driven by the explosion in mobile hardware.
It's inherent to how FPGAs work. Logic blocks are necessary but are kind of a heavyweight solution to emulate normal logic (and they'll result in a ton of extra silicon driving leakage up).
Perf/Watt has always been interesting as well, It's a major concern for data centers (worse perf/Watt requires more cooling which drives costs up).
Hardware is whole completely domain as software. Sadly one cannot throw a hardware bug fix to github and expect mass adoption next day. Hardware cycles are way longer and the associated cost (take alone mask set!) is too high. How many users would be capable of reviewing these millions lines verilog code? Integrated circuit openess is an utopia.
Beyond even that you could imagine erlang-model hardware, with lots of independent µCPU with their own completely private memory communicating via message-passing (CM-style? I don't really know what programming model the Connection Machine used).
To an extent. That seems way more coalesced that what I'm talking about, the page seems to talk about low tens of chips as the normal ceiling, with some exceptional cases in the low hundreds.
Even the later "fat processor" (RISC) Connection Machines had several hundreds of CPU (the earlier models had tens of thousands of single-bit processors)
I think the problem have more to do with software, CPU's are just built to meet the demands.
Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO
I think the problems have more to do with economics. Creating new modern CPUs requires a lot of capital investment, making CPU vendors more risk averse. That's why modern CPUs by and large are not built to meet the demands of future software - they're built to meet the demands of Excel 97 (exaggerating slightly for effect).
The programming interface of a modern x86 CPU is best thought of as a virtual machine with a JIT. The JIT performs some optimizations to make old code run more in parallel without the need for recompilation. This is a terrible model for compilers and programmers, since it makes optimizations hit or miss, and of course it's why we're in this whole spectre/meltdown mess at the moment. If we switched to a more reasonable programming model which actually met the needs of software (fine grained interprocessor communication without going through central memory, many more registers, actual software access to pipelines, caches, etc.) then it would make a lot of old software run slower (through emulation), but new software could finally make better use of your hardware...
> I think the problem have more to do with software, CPU's are just built to meet the demands.
> Today most software can only scale if you add a faster processor, that has to stop, before that happens, there is not much the processor manufacturer can do, their hands are tied IMO
These are not recent developments, chip makers could have opted not to use them and software developers would have done otherwise.
The hardware is developed to make the existing software faster, but the software is also developed to run well on the current hardware.
There was those who tried, for example Inmos with the Transputer, which was _the_ next big thing for a couple of years in the 80's, but unfortunately it never got any traction.
I agree, the single, superfast CPU model is outdated. It's a shame that multiprocessor programming is hard (or is it? It might also just be a vicious circle: 'not many people do MPP because the facilities suck because not many people do MPP').
I could right now give you a CPU with a 100,000 ALUs on it. Your CPU with ~4 ALUs is probably going to beat it in performance, because you can easily keep all of your ALUs constantly fed with data, but I'm going to struggle to keep all 100,000 ALUs fed.
We have some idea of how to do massively-parallel programming. That is, after all, what a supercomputer is. But one of the things we've found is that communication doesn't scale. For very low core counts, you can hook up each core to talk to every other one at the same latency--basically, O(N)-degree topology. For slightly higher core counts, you can keep it a hypercube, which is O(lg N) degree. But when you start thinking about a few hundred cores, you end up with a mesh, which is O(1)-degree.
What that means is you struggle to scale problems that have very high communication costs compared to computation. Matrix multiplication is wonderful--you're doing O(N^1.5) computations for each data, so communication goes down as size goes up [1]. But a BFS graph traversal is horrible, because your communication costs go up if average degree is more than O(1).
[1] This is why the TOP500 benchmark is to some degree bullshit. It's measuring performance on applications that are fundamentally computation-bound, not communication bound, so it tends to penalize machines that focus on improving communication bandwidth, which is often helpful for many HPC applications.
Thats what the north/southbridge does, off-loading the CPU from all sorts of tasks (even if some of the tasks moved into the CPU die since the classic definition of north/southbridge was set)
If we see further fragmentation of cpu architectures it's not going to be fun for users and developers. Already the fragmentation of OS makes that cross platform is a big challenge. It would make the equivalent of a .net/java/webassembly/posix critical.
We have a huge monoculture of Intel x86/x64 on the desktop, driven by Intel's fab advantage that smothered all alternative (and often superior) architectures. And recently, a second one has sprung up with ARM on mobile.
And it hasn't really been good for the industry.
Fortunately, the Windows monoculture in OSes has been broken, so much that MS wasn't able to extend it to mobile and has been driven to give away their OS updates.
In terms of porting, CPU architecture is far less of a problem than you might think. Tiny NeXT managed to make its OS available for four CPU architectures: 68K, i386, SPARC and HP-PA, with apparently PPC and MC88K available in-house. Write Once, Run Anywhere™, all with native binaries, no intermediate layer needed.
And these were processors with different endian-ness, RISC, CISC, sliding register windows, sparse register sets etc.
ISA fragmentation isn't much a worry for people who only run open source software. Debian is especially good at maintaining ports of tens of thousands of packages for 10 ISAs [1].
Last decade I'm not so sure. I bought the very first readily available consumer quad core CPU a decade ago (the Q6600), two years ago I upgraded and I had to pay a huge premium because I wanted more than four (I got six!) cores. And that is just starting to change today.
Not that core count is everything but consumer desktop CPUs have stagnated quite a bit. Here's to hoping AMD stirs it up a bit.
Because the compute power for consumer CPU nowadays is good enough, the effort has been in reducing energy consumption. But if you look at the server / workstation side, you can get 20+ cores in a single dice.
If you consider core count desktop CPUs have had massive increases in performance in the last year and will get another massive increase when 7nm arrives.
I would add that today, as opposed to past periods of fragmentation, there are more widely adopted universal formats, standards, and protocols. So much so that as long as different systems can support just a few key pieces of software, they'd be largely useful — no matter what runs underneath.
This is a little hyperbolic. There have been occasional superior alternatives but "often" is kinda silly. By and large, the best products won - and that is despite accepting that Intel acted in anti-competitive ways in the past (Cyrix et al).
Agreed, somewhat, but you are conflating "product" and "architecture". I specifically meant architecture.
Intel was usually at least one process generation ahead of competitors, and often more than that. With Moore's law still going at full tilt, that meant not only more transistors, but also faster transistors, completely overwhelming the architectural deficits.
> occasional superior alternatives but "often" is kinda silly
Hmm...just off the top of my head: Motorola 68K, MicroVAX, LSI-11, SPARC, AMD 29K, Power, RISC, MIPS, Transputer, Alpha, HP-PA, ARM for desktop, Motorola 88K, Fairchild Clipper, etc.
I'd be hard-pressed to name an architecture that wasn't superior to i386. But architecture did not matter. With Moore's law no longer also getting us faster transistors, it might matter again: https://rodneybrooks.com/the-end-of-moores-law/
Perhaps the solution is some form of interoperability across processors. Where they primarily run one ISA but have a dynamic converter that can based on some flag interpret memory as code from a different ISA? As chip fabbers and ISAs compete eventually a clear winner emerges and these compatibility layers are mere curiosities just like 16-bit mode on modern x86 CPUs.
Except wait, maybe this is just my cynicism talking, but I have a feeling intel has the resources to just plough forward with x86 and prevent any competition from gaining a foothold in the markets where they hold dominance (laptop, desktop, server). ARM continues to dominate mobile and perhaps some small portion of servers. POWER and SPARC stay in their little niches. Perhaps RISC-V makes its way into a couple of embedded appliances. And that's it, for the foreseeable future.
The ISA isn’t the biggest problem. The memory model (do I need to use memory fences here? How many different kinds of those are there?) can introduce hard to reproduce bugs.
Also, relative strengths of the OS (if thread creation is relatively slow, it may not be worthwhile to multi-thread a short code fragment; one OS might have three kinds of spin locks, another only two; if there are many registers, you may need larger stacks per thread, and may want to limit the number of threads in memory-constrained devices) are bigger ones.
Interop relies on a single standard as a benchmark and history tells us that people are incapable of being content with a standard that isn't exactly how they imagined it and would rather fragment and live and die on their own hill than play nice.
> Interop relies on a single standard as a benchmark
Not so! Imagine that each processor is made by their own company (to simplify it) and has its own ISA. Thus, processor A can emulate processors B and C, B can emulate A and C, and C can emulate A and B.
The two different clipboards are fantastic! Select then middle click is one of the things I miss most on Windows, and it's really convenient that that preserves the copy-paste clipboard.
I'm running on Wayland at this moment (Gnome 3 on Fedora), and just tested on the terminal. It has two: I can copy something with Ctrl-Shift-C, then select something else, then paste with Ctrl-Shift-V, then paste with middle-click; the selection didn't override what I had copied, and middle-click pasted what was selected.
So you still have two, at least with Gnome 3 on Wayland.
Almost all code today is written in languages that run in vms(java, .net), are interpreted (python, ruby, js), or easily compile across cpu architectures. Operating systems are a different story but changing the underlying ISA is really not a huge deal
IME it’s harder to port to a new os than a new ISA.
It may be, but from a user point of view, unless the developer targeted that architecture, you are out of luck using that software. And then you end up with “I need software 1 but it only works on OS A and cpu X and I also need software 2 that only runs on OS B and cpu Y”. We are back in the 80s!
Except today we have open source that can be recompiled without the author's explicit approval and we have a large collection of software that runs in some VM or other. There is also a variety of services as a software substitute that run on some cloud.
Is this something the distribution maintainers are supposed to track? Let's say package x is available on Debian and decisions is available on the raspberry pi. The package maintainers on Debian side are the people who compile and ship the binaries for raspberry pi, no? Are the authors involved in this at all? Or is it that the package maintainers take a more handsfree approach and only build on platforms that the authors have said the software works on?
I'm interested in the possibility of eventually having FPGA-driven systems where you can load up an ISA and use that. Imagine if every week you could expect an ISA architecture update that came with a power usage or speed improvement.
The problem is that no FPGA-driven system will come close to beating out a modern CPU, so people will have very little incentive to actually use it because it will probably be more expensive and definitely slower.
The same thing could be said for any new open CPU. It would be slow and expensive. Unlike a normal CPU though your FPGA-system could be programmed to run your main CPU, PCIe Bus, USB Bus, video card, etc and it could be updated to add features and run faster.
Somebody needs to take the risks of designing, making, and selling a RISC-V processor/chipset and associated peripherals. Frankly, someone like a Broadcom, who has the expertise, and wants a royalty free rpi, might just work fine. I can't immediately imagine anyone else big enough doing it without upsetting the market too much. Sure, an open foundation could do it if they raised enough cash, but it seems unlikely.
Having the backing of industry/academia/hobbyists is no small feat, and I hope RISC-V can keep pushing further into the consumer market.
perhaps to process the information it is necessary to visualize the phantom environment where all information is transmitted in order to manage and construct as part of the processing the so-called reverse engineering;
understanding the electricity and visualizing the magnetism and diverse waves and its interactivities;
in order to detect as to the example of a bird landing on the high voltage wires and how the properties of the particles can be read as well as stored in plants etc. and how the materials are properly constructed in order to distort the assimilation necessary to start the machine ;
and then destroy the school logic as to algebra titles etc, in which it is part after the experiments to start organizing circuit logic;
maybe something about the quality of the electricity by improving the components including rust and dusting etc.
perhaps thus by sealing the components in the process of initializing the machine to verify the veracity of the circuits;
some degree of upgradeable serial number in order to connect other parts, perhaps identifying a first problem of logic;
- and perhaps the idealization of unique components like the Raspberry system-board? where volatile parts is taken as user Hard-Disk content being the logic of software?
so better focusing on the complexity required than the ultra-fast Quantum Computer processor? can be produced at higher levels for virtual realities; [?] Just Guess;
Of course it is! What is this question? No, man, not yet. Everyone has a thing just for the closed ones. Instead of asking "Is it time...?" you just do it when it's time! Damn those click baits. Although, open as in OpenSSL made a bad name for open source, because without critical audits there is even less security in open, because then it might be wide open instead! In open source, when a thing is made and it works for the most, nobody freakin cares anymore!
They're not asking if it would be nice to have, they're asking if it can be economically feasible now. If there isn't going to be a very large use case for open but inferior processors, a lot of money will be lost by anyone investing. That isn't a problem with software.
However, CPUs are that complex these days and require a lot of equipment around it to be produced. The way is IMO much harder to open IP than to open Source.
Another important piece is being able to verify that the manufactured hardware meets the open specs they claim to (and wasn't tampered with, or contain errors). Something like an md5 check for hardware.
With open software you can read the code, compile it and run it << zero trust. With hardware you can read the spec, but must trust the implementation.
IMO the problem is on the software side, if software was built to harness a distributed architecture the CPU companies job would be much easier, so more could do it, which would increase competition and drive price cuts.
It could add a much needed impetus for the semiconductor industry to consider security perspectives in a much wider sense.
Today we can't know or analyse the security properties of the silicon that essentially runs the entire world. We simply have to trust the producers, and they have been proven to be unreliable at best. They compete on performance and features, and the result is not that different from when there were no safety regulations (and testing) for cars, except that so far bad processor security haven't killed as many people as far as we know.
Open IP is one way to help making sure the above stays true. There are certainly other avenues, but for security it seems to be the case that it's best handled in the open.
If this is true how come that the spectre/meltdown discovery came from external vendors? Black box testing is essential in security and majority of the bugs found with fuzzers and other black box methods. Just because you have visibility into a product it does not mean that you are going to spot the bugs even less, you won't be able to identify security related bugs. Just to give you a really simple example, flying is one of the safest activities for humans yet all of the airplane producers have "closed" development models. It just proves that safety has nothing to do with open or closed development methods. Another angle, do you have documentation of any bridge you use? I don't think so. Yet, it is extremely safe to use bridges. I think people are trying echo the mantra that opensource is safer and testing is the only way to produce reliable products when we know for fact that other engineering disciplines do not use testing and open development, yet produce much safer to use products.
In many of the same ways that open software is usually better than closed software. In particular, greater scrutiny of specifications and microcode ought to lead to better quality outcomes.
This whole debate feels eerily similar to the emergence of open source software into the public eye, back in the 90s.
No - open source is a specific case of the general rule that there is no such thing as a silver bullet :)
But it does make possible a bunch of superior workflows that are impossible with proprietary software, and makes certain types of failure common to propriety software much harder.
I am yet to see any open source project subjected to the same high quality workflows as commercial propriety software targeted for high integrity computing deployment.
Anecdote: open source software has the same rate of flaws as proprietary software but with proprietary software you're at the mercy of the vendor who might decide to not release or delay a patch. Opensource software in my experience usually gets patched quickly.
My anecdata agree with yours :) I remember switching from .NET to Ruby and being able to fix defects instead of submitting bug reports to Microsoft, and waiting _years_.
Do we really know that AMD is immune to Meltdown aside from trusting them?
I mean, I reasonably trust AMD here. I don't see any reason why they'd lie about it. Plus, everyone in AMD seems super-confident that they're immune to the Meltdown issue due to how they implement speculative cache loads.
But such analysis is purely within AMD's circle of engineers. None of us outside of AMD can verify their claims.
Are you suggesting that we open up a government agency dedicated to the testing of CPU chips, and enforcing strict regulations?
The FAA and its set of safety regulations are written into US law. That's why airplanes are trustworthy and safe: more safe than other countries on the average.
Or do you think the US just MAGICALLY gets high safety results through sheer determination? There are systems in place, and I think it is reasonable to suggest that we should start building a system for computer-chip processors.
Open Source is one possible proposal. I'm not sure what other proposals exist to ensure that the internals of chips aren't compromised.
I am suggesting that other engineering disciplines produce much safer products without opensource and open design. How it is achieved is another question. Bridges are not safe because of any government agency but because mechanical engineers design them to be safe.
Every single bridge in the USA is documented, listed, inspected and regulated. There's even an entire division of the US Military that helps out: The Army Corps of Engineers. So its multi-agency, multi-department, and even includes military service members.
Bridge Building might be the only thing more regulated than Airline safety in this country.
> because mechanical engineers design them to be safe.
Civil Engineer btw. Not Mechanical. And Civil Engineers need to pass a strict level of training and licensing to practice in the USA. Granted, this is on a State-by-State basis rather that on a national basis (like Bridge-building).
But its still a government regulation, even if its State-wide instead of Federal.
All 50 states require 4-years of work experience before you earn the title of "Professional Engineer". And that's the title you need before you can lead something like a Bridge-building project.
Not only are bridges highly regulated, but the people who are allowed to build bridges are highly regulated, at both the State and Federal levels.
----------
Now I'm not saying we enforce the highest regulation standards upon our CPU manufacturers. I'm basically saying "Stop coming up with bad examples". The incredibly safe examples you have brought up so far (Airline safety and Bridge Building) are the result of years of Government regulation and laws.
It seems you are really keen on government regulations. You can regulate as much as you want but if we can't build a safe bridge because we don't know the law of physics than legal considerations are pointless.
Yes. Which is why there are government regulations saying "Professional Engineers" (a regulated title btw) must know a certain level of physics before they are allowed to build a bridge.
That's simple enough. Execute meltdown and see if an unknown answer pops up. If it does, then you've accessed something you aren't permitted and some degree of meltdown is possible.
I would love to play with a RISC-V unit. But like one they linked too it was limited on memory and very expensive compared to other modern Aurdino compatible boards.
If you're really just looking to have fun and learn, $60 is nothing. You can burn through that at Dave & Busters in 15 minutes playing games. They also say it's the "fastest Arduino-Compatible dev kit" but I don't know enough about the space to know how accurate that is.
Are you kidding? How many undocumented processor instructions and undocumented processor operating systems do what with your data. Imagine a world with transparent CPUs and you are imagining a world without mass data collection.
There are just so many issues with this it's almost laughable to be honest.
Firstly, let's assume you basically need a big company to opensource their existing IP because opensource is no where near where Intel is today. So let's look at the obvious choice: Intel has traditionally perceived itself to be a manufacturing company. It tries to produce as many chip widgets as possible and producing CPUs or SSDs or network chips is just their way of finding ways to sell their widgets. The core of their business is fabrication.
Now, the only companies they let use their foundries to produce other chips are almost exclusively companies that they end up buying (I'm looking at you Altera).
By open sourcing their CPU designs they are practically guaranteeing that some of the chips they produce today would be produced by Samsung and TSMC. Try explaining to their share holders that you're giving away the crown jewels, damaging the core of the business and hoping for what....?
Secondly, taping out a chip is hundreds of thousands of dollars. Even if you did opensource everything, the only people who could actually produce the chip would be huge corporations, and the process of taping out isn't "Let's save it to a floppy and send it off". All of the tape out process requires proprietary tools from the fab, which are only available to the serious customers. So your source might be open but no one outside the company would be able to actually read them. And this is non-trivial, TSMC consider their tools to be a core part of the IP that differentiates them, they'll never release them under anything but a very strict contract to a client.
Finally, one of the key benefits to opensource is that you can fix something yourself, you can contribute and change things. Well not in hardware. The best you can manage is to fix the problem in the next $X00k production run.
Laying all that aside: No one has actually described what benefits Open Source software has over closed source that we're trying to map to hardware? To me a key benefit of Open Source is that we don't depend on corporations as gatekeepers to fix things, well that isn't solved in hardware open source.
That would be non-free / non-open to be clear. A copyleft license is non-permissive but is still free/open. Just want to be clear, since some people mistakenly think things like that commercial use requires permissive licensing.
We already have some. I know the Arduino CPU is open source (slow) and there are open source MIPS CPUs but again they are slower than ARM and X86 CPUs.
Open Processors is a very bad idea. Look at what's happening to Android. The same thing will happen with CPU's. Every OEM will fork the open design and put all of their stupidity inside it in the name of features and security. Bugs like Spectre and Meltdown will become commonplace.
The entire time of kernel devs will be spent working around the various 'features' of the OEM designs. Then someone will come up with a JVM and docker for the CPU and lead to another round of madness.
There is no harm in having alternate architectures. But putting everything up on GitHub is a recipe for disaster.
What you describe is the current state of affairs for CPUs. Intel, AMD, ARM, and every other company working in this space already "put all of their stupidity inside it in the name of features and security". These companies will continue to "put all of their stupidity inside" their products as long as innovation continues.
As Spectre and Meltdown demonstrated, bugs like these occurred in almost every CPU that allows speculative execution. Open projects will simply address these bugs as they are discovered just as private companies do for their proprietary design. Openness is orthogonal to this class of bugs.
> The entire time of kernel devs will be spent working around the various 'features' of the OEM designs.
No they wont. If a CPU spec is implemented by a large number of vendors, kernel devs will (must?) treat their support as they treat peripherals: They will provide support for the baseline CPU as is described in the open spec. Additional support is supplied either by the manufacturer or by volunteers who want to take advantage of additional features.
> But putting everything up on GitHub is a recipe for disaster.
I'll gladly take fragmentation if it means that we are no longer forced to accept ME, PSP, or TrustZone. Competition and diversity is a good thing. It's having only closed CPUs that's the recipe for disaster.
No you're conflating two different issues here. An open architecture with a copyleft license would be resistant to the abuse you just identified. An open architecture that allows closed changes would do what you're saying, and is the major fault of Android.
This does happen in Linux till some extent. Look at wayland for example. Broken on nvidia hardware because nvidia favors its own implementation.
The reason why this does not happen with Linux kernel is because Redhat and Canonical go to great lengths to backport kernel patches, which by proxy affect all the distos based on them. Also because Linux desktop is not big enough for OEM's of the majority of PC users to care about.
Android is a flavour of linux that went big. The fact that OEM's can clone the kernel and put their own drivers into it without being forced to update is what causes the most grief in Android world.
Linux proper, ie the kernel, allows things like modules and has a powerful userspace. Most purposes are met by taking vanilla Linux and dropping some modules and userspace applications on it. You don't have to do a hard fork of the code.
But if you're talking about distros (or some vauge distro-like prepackaged blob of Linux + userspace), it does happen. There are a lot of specialized Linux distros out there, and they aren't all on long-term support with security backporting.
It is. The kernel is GPL; the copyleft license protects the commons from exploitation without releasing the source code, which allows people to fix these things. It does happen to Linux userspace though because a lot of that is not copyleft (which is fine, people should decide each component themselves).
Nonsense. OEM can buy ARM "IP" and jam it into a SoC with plenty of poorly designed tweaks and additional devices and it's not happening.
Also, open does not mean that random changes are allowed as part of the original design. You can have a license that prevents using the original name of a CPU on modified versions.
Most OEM's do not have the money to buy ARM IP. Those that have money, i.e, Samsung, Huawei and Apple, are doing it.
AFAIK open does mean that I can fork and make whatever changes I want to the original design. I cannot use the name, but i can use everything else.
As I understand it, the ARM IP license that allows companies to customise the actual cores is very expensive, still requires the resulting customisations to comply with the ARM specification, and relatively few companies have the resources to do so.
I don't understand why people feel the need to downvote comments, only because they don't agree or they don't want to hear any critical thoughts about something they like.
Anyway, your points are certainly valid. However, they are not a "will happen", but rather a "may happen". In FOSS, it took some time too, to find a working governing structure for large projects. A respected BDFL seems to help. Who knows what would be the best set-up for hardware.
This is the purpose of the GPL and copyleft licenses: to create a commons that companies can't exploit in the manner you described. The problem with Android is that the parts that aren't the kernel are not copyleft. This allows vendors to shove stupid stuff in there and not release the code. If a chip spec uses copyleft correctly (e.g. no sacrificing to LGPL style things on the edges) this won't happen.
Do you just mean that a popular open architecture will lead to more competition and variation in implementations, which will require more work by kernel developers versus just having a much smaller number of closed-design CPUs?
But I posit that open projects do better with audits than closed because they are more likely to have open audits as well, and an open audit is harder to ignore or sweep under the rug if it's inconvenient to business.