Live data from Hacker News

Is it time for open processors?

lwn.net

221–230 of 236 posts

Re: Is it time for open processors?

#221
post #98
post #35

Earlier quoted context omitted.

How?

You just have one. https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection

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.

Re: Is it time for open processors?

#222

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.

Re: Is it time for open processors?

#223
post #72
post #34

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 o…

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 a…

"modern lithography" is what brought us rowhammer.

Re: Is it time for open processors?

#224
post #171

Earlier quoted context omitted.

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.

There is a Linux scheduler option for cpuset accessible via cgroups iirc, that pins execution to a set of cores. I've not used it.

Re: Is it time for open processors?

#225
post #72
post #34

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 o…

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 a…

The J-Core (based on SuperH ISA so already supported by GCC) project http://j-core.org/ specifically called out being able to audit everything up an down being a motivating factor https://www.youtube.com/watch?v=lZGHbMS882w

Re: Is it time for open processors?

#226
post #193

Earlier quoted context omitted.

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

> compilers weren't ready for them yet

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.

Re: Is it time for open processors?

#227
post #34

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 o…

> Open isn't a magic bullet. > more about quality of auditing. 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.

Re: Is it time for open processors?

#228
post #227

Earlier quoted context omitted.

> Open isn't a magic bullet. > more about quality of auditing. 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…

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.

Re: Is it time for open processors?

#229
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;

Re: Is it time for open processors?

#230

Earlier quoted context omitted.

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.

Hyper-threading helps with that.

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)
Post reply on HN