Hacker News Reader

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

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.

Most Itanium implementations had hardware branch predictors+predicates.

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

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

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.

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

That work became PhyreEngine.

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

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

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

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.

I don't think you necessarily have to miss it on a threaded CPU, but that isn't as optimal.

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)

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.

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

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

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.

QubesOS is dealing with the problem you describe. It implements security through isolation. But the vulnerabilities in CPU break everything.

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.

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

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.

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?

Why not? The operating system is the device driver/HAL. The Browser is the operating system. The webpage is the application.

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.

Have a look at Risc V [1], in the meantime backed by quite a few biggish companies [2]

[1] https://riscv.org/

[2] http://www.tomshardware.com/news/big-tech-players-risc-v-arc...

CrowdSupply has an ardrino-compatible risc-v board you can order very cheaply. [1]

[1] https://www.crowdsupply.com/sifive/hifive1

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.

I deeply believe that a good set of simple processors (cpu, gpu, apu) could lead to a vastly simpler software layer.

Lots of issues are down to market competition, lies and spec distortion; also double driver games (see the pre vulkan era).

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.

> And since it's ARM, it's at least half-open.

What do you mean by that?

ARM did release a very detailed, machine checkable specification(that they themselves use to verify security with), to everybody:

https://news.ycombinator.com/item?id=14174533

Russia has the Baikal CPU based on MIPS.

China has Loongson also MIPS.

Can either be purchased online by customers outside of those countries?

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.

I believe you can still get them but its not as easy.

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.

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

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.

"modern lithography" is what brought us rowhammer.

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.