Live data from Hacker News

Is it time for open processors?

lwn.net

211–220 of 236 posts

Re: Is it time for open processors?

#211
post #151

Earlier quoted context omitted.

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

>"The halting problem is unsolvable" Can you elaborate on how the halting problem relates to the IA-64 architecture?

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.

Re: Is it time for open processors?

#212
post #106

Earlier quoted context omitted.

Why give up on performance? 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 thin…

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.

Re: Is it time for open processors?

#213
post #162

Earlier quoted context omitted.

>targeted at the wrong markets What would have been the right ones?

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, whe…

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.

That work became PhyreEngine.

https://en.wikipedia.org/wiki/PhyreEngine

http://develop.scee.net/research-technology/phyreengine/

Re: Is it time for open processors?

#214
post #85
post #69

Earlier quoted context omitted.

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.

Good enough relative to the competition perhaps. Nowadays the CPU is the bottle-neck even when surfing the web and using simple (electron) text editors.

Anything built with Electron is the anathema of simple.

Re: Is it time for open processors?

#215

Earlier quoted context omitted.

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.

Which is also a thing in countries where software engineering is a 3 to 5 year degree, and not a made up title.

Re: Is it time for open processors?

#216

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

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.

Google is fixing it (for them) with Fuchsia.

Re: Is it time for open processors?

#217
post #49

Earlier quoted context omitted.

> And it hasn't really been good for the industry. Intel's problems over the past year aside, they have done an amazing job pushing the limits of computation over the past decades.

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.

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.

Re: Is it time for open processors?

#218
post #28

Earlier quoted context omitted.

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.

> In particular, greater scrutiny of specifications and microcode ought to lead to better quality outcomes. Which given the CVE entries per day isn't necessarily true, in spite of pull requests being reviewed.

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.

Re: Is it time for open processors?

#219
post #28

Earlier quoted context omitted.

> In particular, greater scrutiny of specifications and microcode ought to lead to better quality outcomes. Which given the CVE entries per day isn't necessarily true, in spite of pull requests being reviewed.

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

Re: Is it time for open processors?

#220
post #106
post #72

Earlier quoted context omitted.

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…

Why give up on performance? 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 thin…

> Why give up on performance?

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)

https://riscv.org/wp-content/uploads/2016/11/Wed1000-Thousan...

Post reply on HN