Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serious Intel CPU bugs (2016)

danluu.com

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Serious Intel CPU bugs (2016)

#91

Post by maksimum »

juanmirocks wrote: post #87

Considering the late Intel problems, Apple is going to be even more tempted to design its own CPUs/GPUs for the mac. What do you think, is this realistic?

I'm not an insider, but it seems like Apple's motto is "long-term profit above almost anything else." As a result they certainly are considering designing their own x86-64 or ARM CPUs in hopes of reduced costs down the line from vertically integrating their business. What may stop them is the fact that their PC sales don't enjoy nearly as much volume as their mobile devices.

Re: Serious Intel CPU bugs (2016)

#93

Post by sitharus »

johnflan wrote: post #92

I have seen a lot of talk of AMD benefitting from this but what about ARM - how are their server offerings shaping up?

ARM is interesting because of the customisability of ARM chips. Some companies, such as Apple, license the ISA and spin their own silicon. Others license the whole CPU design from ARM holdings, and ARM produce several lines of designs with different CPU capabilities.

Edit: Looks like ARM64 was affected, but it has an architectural feature that makes the mitigation much easier: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-N...

Re: Serious Intel CPU bugs (2016)

#94

Post by otakucode »

chrisper wrote: post #34
philjohn wrote: post #22

Earlier quoted context omitted.

Which chip to get depends on your usecase. If you absolutely need the best single core performance you can, Intel is the way forward. If multicore performance is important (lots of multitasking, lots of heavy processes running) then one of the 8 core Ryzen 7's will be better, for cheaper.

Thanks. I guess I'll stick to my 8700k then.

Just curious, what do you do that requires a fast single core? I always find it strange when people value that, as most computers nowadays generally run more than 1 process at a time.

Re: Serious Intel CPU bugs (2016)

#95

Post by _0w8t »

walterbell wrote: post #85
_0w8t wrote: post #81

Earlier quoted context omitted.

This bug can be worked around. But the next one may not, making hardware-based virtualization as a secure way to run unprivileged code with max native performance unworkable. I.e. longer term if one wants to run untrusted code, it cannot be native one so any bug can be fixed without replacing hardware.

>if one wants to run untrusted code, it cannot be native one so any bug can be fixed without replacing hardware It's a bit hard to parse that sentence, could you rephrase? Are you saying that untrusted code should only be run on systems which do not use hardware virtualization, because there's a risk of hardware bugs that require hardware replacement? The problem is that there is no single-system equivalent, users wo…

My point is that to run untrusted code it should be delivered in some form of bytecode, not the native code for CPU. This way one can always workaround CPU issues by changing the compiler or the interpreter even for catastrophic bugs in any part of CPU. Moreover, as hardware VM can execute much more instructions than unprivileged user processes, the probability that something unfixable will happen to them is higher then for ordinary processes.

As for statistics, there are strong indications that modern efforts for CPU verification do not keep up with increasing CPU complexity. So number and severity of bugs will grow.

Re: Serious Intel CPU bugs (2016)

#96

Post by drb91 »

otakucode wrote: post #94
chrisper wrote: post #34

Earlier quoted context omitted.

Thanks. I guess I'll stick to my 8700k then.

Just curious, what do you do that requires a fast single core? I always find it strange when people value that, as most computers nowadays generally run more than 1 process at a time.

Computing things serially, obviously!

Re: Serious Intel CPU bugs (2016)

#97

Post by nine_k »

nabla9 wrote: post #51
slivym wrote: post #13

As a former Intel employee this aligns closely with my experience. I didn't work in validation (actually joined as part of Altera) but velocity is an absolute buzzword and the senior management's approach to complex challenges is sheer panic. Slips in schedules are not tolerated at all - so problems in validation are an existential threat, your project can easily just be canned. Also, because of the size of the compa…

I thought that the secret of Intel's success is paranoia. Andy Grove's motto was "Only the paranoid survive" and he wrote a book with the same name.

Andy Grove, sadly, has retired from Intel in 2005, and died in 2016.

I'm afraid the level of paranoia at Intel has decreased since then.

Re: Serious Intel CPU bugs (2016)

#98

Post by chrisper »

otakucode wrote: post #94
chrisper wrote: post #34

Earlier quoted context omitted.

Thanks. I guess I'll stick to my 8700k then.

Just curious, what do you do that requires a fast single core? I always find it strange when people value that, as most computers nowadays generally run more than 1 process at a time.

A lot of games only run single core. Though finally, more modern games do take advantage of more cores!

Re: Serious Intel CPU bugs (2016)

#99

Post by walterbell »

_0w8t wrote: post #95
walterbell wrote: post #85

Earlier quoted context omitted.

>if one wants to run untrusted code, it cannot be native one so any bug can be fixed without replacing hardware It's a bit hard to parse that sentence, could you rephrase? Are you saying that untrusted code should only be run on systems which do not use hardware virtualization, because there's a risk of hardware bugs that require hardware replacement? The problem is that there is no single-system equivalent, users wo…

My point is that to run untrusted code it should be delivered in some form of bytecode, not the native code for CPU. This way one can always workaround CPU issues by changing the compiler or the interpreter even for catastrophic bugs in any part of CPU. Moreover, as hardware VM can execute much more instructions than unprivileged user processes, the probability that something unfixable will happen to them is higher t…

Which bytecode do you recommend? Are you assuming the bytcode interpreter to be bug-free? There have been JVM escapes.

Re: Serious Intel CPU bugs (2016)

#100

Post by _0w8t »

walterbell wrote: post #99
_0w8t wrote: post #95

Earlier quoted context omitted.

My point is that to run untrusted code it should be delivered in some form of bytecode, not the native code for CPU. This way one can always workaround CPU issues by changing the compiler or the interpreter even for catastrophic bugs in any part of CPU. Moreover, as hardware VM can execute much more instructions than unprivileged user processes, the probability that something unfixable will happen to them is higher t…

Which bytecode do you recommend? Are you assuming the bytcode interpreter to be bug-free? There have been JVM escapes.

I do not assume that bytecode interpreter or compiler is bug free. But I assume that the interpreter can be trivially updated, while a bad CPU bug may require hardware replacement or taking terrible performance hit.

As for a particular bytecode format, I have no idea. Webassembly is a possibility, but it is still slower by factor of 2 compared with native code. Perhaps CPU-specific symbolic assembler will be a better choice as long as one can realibly alter it to workaround CPU bugs.

Post reply on HN