Why Intel x86 Must Die: Our Cloud-Centric Future Depends on Open Source Chips

Megalith

Megalith

24-bit/48kHz
Staff member
Joined
Aug 20, 2006
Messages
13,000
Due to all of the recent security fiascos, ZDNet argues that we should drop x86 and transition to an open-source microprocessor architecture as a means of freeing ourselves from legacy baggage. Adopting open-source architectures such as RISC-V would enable correction and improvement of chips through community efforts.

Just as Linux and open source transformed how we view operating systems and application software, we need the equivalent for microprocessors in order to move out of the private datacenter rife with these legacy issues and into the green field of the cloud. This would have more benefits than just providing a systems architecture that can be molded and adapted as we see fit in the evolving cloud.
 
Talk about buzzword bingo.

Useless article.

Bringing up Sun? .. Really?

Open-source is no panacea for the issues (software/hardware) that crop up in your average Fortune 50 (hell, even 100) corporation utilizing technology to deliver their products.
 
1_rick said:
Meltdown and Spectre show us why x86 is bad? How does this genius explain ARM chips having the same vulnerability?
Click to expand...

..because its not an x86 issue. Not at all. Many times I wonder what documents were shown that got a few tech writers their position. It doesnt make any sense. Its about speculative execution and super scaler processors. Its about how getting the best performance above just clock rate makes cpus do more on one clock cycle. An open source cpu that tries to do more than process one 'lemming-at-a-time', would/could be vulnerable. Someone thinks that its a 'closed' source issue. I cant fathom why.
 
Khahhblaab said:
..because its not an x86 issue. Not at all. Many times I wonder what documents were shown that got a few tech writers their position. It doesnt make any sense. Its about speculative execution and super scaler processors. Its about how getting the best performance above just clock rate makes cpus do more on one clock cycle. An open source cpu that tries to do more than process one 'lemming-at-a-time', would/could be vulnerable. Someone thinks that its a 'closed' source issue. I cant fathom why.
Click to expand...

They get these positions because they are fresh out of college with a worthless degree and are paid next to nothing to write shit clickbait articles.

The notion of an open-source chip is laughable and shows a complete lack of understanding of how complex architectures are these days.
 
look at how crowdsource had helped Linux.
Answer : not at all. Major utilization are still done by major companies. Same as major code upgrades.
 
Mchart said:
They get these positions because they are fresh out of college with a worthless degree and are paid next to nothing to write shit clickbait articles.
Click to expand...

Well, what Ben Rhodes said about political reporters (they're ignorant, maybe dumb, and report whatever we spoon-feed them) is true of the non-political ones, too, these days.
 
Mchart said:
They get these positions because they are fresh out of college with a worthless degree and are paid next to nothing to write shit clickbait articles.

The notion of an open-source chip is laughable and shows a complete lack of understanding of how complex architectures are these days.
Click to expand...

I think people are starting to feel the lack of control they have over their own security in computing. It starts with hardware. It's a pipe dream to have control over the hardware and while I think we aren't anywhere near having that, that should be the goal. So, shitting on it is not the right approach.
 
1_rick said:
Well, what Ben Rhodes said about political reporters (they're ignorant, maybe dumb, and report whatever we spoon-feed them) is true of the non-political ones, too, these days.
Click to expand...

The older you get the more you begin to realize that most reporters and what you see in the news/media is written/presented by complete idiots with little understanding of the subject.
 
Wasn't that xperian fiasco based on some open source code vulnerability or somesuch?

I love open source for many things but trying use it as a base for nearly everything(let's face it x86 it big) seems equally unwise.

I do, however, agree that its long overdo for moving on to a new architecture.
 
Yea definitely. Open source means it's impossible to have a vulnerability. /facepalm
 
Sounds like someone wants to break off Brand Names from the CPU so they can be made by Cheap Chinese makers. This worked for ARM because it has a bit of a stewardship model from a former Brand name and the drive of industry that ARM chips feed.

No stewardship to cutting edge consumer CPU's (relatively speaking) would be a cluster and a half.
 
RISC-V (pronounced “risk-five”) is an open, free ISA enabling a new era of processor innovation through open standard collaboration.

riskriskriskrisk

Everyone knows free things are better, just like antivirus. duh.
 
jpm100 said:
Sounds like someone wants to break off Brand Names from the CPU so they can be made by Cheap Chinese makers. This worked for ARM because it has a bit of a stewardship model from a former Brand name and the drive of industry that ARM chips feed.

No stewardship to cutting edge consumer CPU's (relatively speaking) would be a cluster and a half.
Click to expand...

If it was easy, there'd be more than... ...two(ish) companies globally making suitable processors. There used to be a lot more. As things got more complex, more and more of them dropped off. We're left pretty much with the ones that are capable.

There are companies that COULD do it, but they're busy making GPUs, mobile, and other specialized processors.

Also, who knows how much of that was truly because other companies weren't capable, or some kind of collusion, or corruption coming into play, or if the market just naturally settled that way, but I'll leave that for other discussions. :D
 
Last edited by a moderator:
Uvaman2 said:
The cloud:' join us in making the target bigger'.
Click to expand...

This vulnerability is the absolute worse with the cloud. Imagine someone having a VDI running next to a DB server on the same host. Now imagine this bug.. yep... HUGE. Hopefully nobody is running massive DB servers with secure data in a virtual environment... right?
 
VoloxitySF said:
RISC-V (pronounced “risk-five”) is an open, free ISA enabling a new era of processor innovation through open standard collaboration.

riskriskriskrisk

Everyone knows free things are better, just like antivirus. duh.
Click to expand...


Don't most modern x86 chips break down the complex x86 instructions to RISC like instructions internally anyway?
 
Zarathustra[H] said:
Don't most modern x86 chips break down the complex x86 instructions to RISC like instructions internally anyway?
Click to expand...

The "complex" in CISC is practically a misnomer. The only complex part is the hardware involved (and arguably in x86's case, the number of instructions that have accumulated over the years). The x86 instruction set is actually less complex (relative to the compiler) because each instruction wraps several other lower level instructions to achieve the same goal. It's basically like creating a hardware-macro of RISC-like instructions. You write less assembly code with CISC than you otherwise would with a RISC equivalent - each achieving the same thing through different abstracts.

That said, you better get your CISC instruction hardware implementation right because there may not be a way for software to get down into the low level stuff to correct it with a workaround (think optimization). CISCs weakness is pretty much the complexity of the hardware. But since Intel doesn't open that up, it's all "magic" to those who write x86 compilers. Microcode updates can help somewhat "fix" those nasty situations where the hardware design fails to deliver. With RISC, you always have that "fixable" capability because you (software designer) are doing all the "complex" stuff at the assembler level (i.e. software).
 
Last edited:
Absalom said:
The "complex" in CISC is practically a misnomer. The only complex part is the hardware involved (and arguably in x86's case, the number of instructions that have accumulated over the years). The x86 instruction set is actually less complex (relative to the compiler) because each instruction wraps several other lower level instructions to achieve the same goal. It's basically like creating a hardware-macro of RISC-like instructions. You write less assembly code with CISC than you otherwise would with a RISC equivalent - each achieving the same thing through different abstracts.

That said, you better get your CISC instruction hardware implementation right because there may not be a way for software to get down into the low level stuff to correct it with a workaround (think optimization). CISCs weakness is pretty much the complexity of the hardware. But since Intel doesn't open that up, it's all "magic" to those who write x86 compilers. Microcode updates can help somewhat "fix" those nasty situations where the hardware design fails to deliver. With RISC, you always have that "fixable" capability because you (software designer) are doing all the "complex" stuff at the assembler level (i.e. software).
Click to expand...

Based on a true story:

Guy is hired at some firm. They have an issue. They have gone over and over their primary package (their raison d'etre) and if they could streamline it by 5%, more money, more money, more money!

The primary hire'r lets him know that at best he might find some lines in the code that he can concatenate and this may approach 3% in performance gains. But that in itself is a valuable increase. Let's see if you can find some way to increase performance in the many thousands of lines that the program is.

Primary programmer, also a lead: I have gone over this package many times and I doubt if you can find any more efficiencies. But go ahead and lets see if you can find something that I didnt't.

The guy looks over the software and realizes that the entire package never made use of the extensions MME(like) and SSE(like) that the CPU's offered. MME and SSE have been part of intel chips for a long time, nobody made use of them.

So he went to work. The thousand of line's that the program had increased by 100's of lines, against the way that the 'experts' were confident was the only way additional efficiencies could be found.

The program ran 35% faster!

By adding more lines to the program by using the extensions that the CPU offered, he gained an improvement that nobody saw coming.

Good job!

He was fired! (after some weeks)

Because he didnt follow expected protocol, and went on a path that got done what they asked, but in a way they they didnt know about, made them look at his different way of solving their problem feel suspicious. Had he been able to just eliminate lines of code, he would still be working there.

RISC or CISC, apparently you risk something if you are the only one that understands its worth.
 
You must log in or register to reply here.
Back
Top