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

“We didn't chase the fad of using every Intel CPU feature”

marc.info

Post reply on HN
Print view View original

21–30 of 35 posts

Re: “We didn't chase the fad of using every Intel CPU feature”

#21

Post by yjftsjthsd-h »

stochastic_monk wrote: post #15

Personally, I think it’s valuable to take advantage of new features. AVX512 can be dozens of times faster than scalar operations, and clhash is the fastest strongly universal string hash library. There’s no good reason to pass on these kinds of performance improvements. I know these aren’t the features in question, but casually dismissing the benefits of CPU improvements doesn’t strike me as productive.

I like performance. But. OpenBSD supports hardware versions a long way back. So you either break compatibility, ship more versions, or have to detect features on the fly, which works but has costs. On the other hand, if all x86_64 (amd64) supports a feature then it seems like a better bet.

Re: “We didn't chase the fad of using every Intel CPU feature”

#22

Post by sverige »

GalacticDomin8r wrote: post #13
ahbs66 wrote: post #2

"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol

Since he was right to do so and also right about the underlying meltdown issue, perhaps deserves more than ridicule?

Focusing on correctness and security isn't as popular or sexy as having the latest and greatest bleeding edge superfast stuff, until that stuff breaks and leaves your data vulnerable. But that's unpleasant, so it's easier to deflect than it is to question whether your goals should be adjusted.

Re: “We didn't chase the fad of using every Intel CPU feature”

#23

Post by nottorp »

ahbs66 wrote: post #6
nottorp wrote: post #5

Earlier quoted context omitted.

Question: say you know 5 programming languages and 20 UI libraries. If tasked to write an application, you will attempt to use them all in the project?

That's a strawman. Your question is ridiculous. Features of a certain language/framework/etc != languages/frameworks/etc

Let's try again: would you work on your car using a chainsaw because it happens to be in your tool box?

Re: “We didn't chase the fad of using every Intel CPU feature”

#24

Post by [deleted] »

yjftsjthsd-h wrote: post #21
stochastic_monk wrote: post #15

Personally, I think it’s valuable to take advantage of new features. AVX512 can be dozens of times faster than scalar operations, and clhash is the fastest strongly universal string hash library. There’s no good reason to pass on these kinds of performance improvements. I know these aren’t the features in question, but casually dismissing the benefits of CPU improvements doesn’t strike me as productive.

I like performance. But. OpenBSD supports hardware versions a long way back. So you either break compatibility, ship more versions, or have to detect features on the fly, which works but has costs. On the other hand, if all x86_64 (amd64) supports a feature then it seems like a better bet.

[deleted]

Re: “We didn't chase the fad of using every Intel CPU feature”

#25

Post by hedora »

stochastic_monk wrote: post #15

Personally, I think it’s valuable to take advantage of new features. AVX512 can be dozens of times faster than scalar operations, and clhash is the fastest strongly universal string hash library. There’s no good reason to pass on these kinds of performance improvements. I know these aren’t the features in question, but casually dismissing the benefits of CPU improvements doesn’t strike me as productive.

For performance sensitive deployments, I agree.

On the other hand, I can’t remember the last time any non-interpreted system I deployed for my own use was too slow, even on low-wattage hardware / smallest available cloud instances.

At some point, “rock solid” is more imporant than “N% faster”.

As hardware gets faster, stability is the dominant consideration for a larger percentage of deployments.

Re: “We didn't chase the fad of using every Intel CPU feature”

#26

Post by sremani »

ahbs66 wrote: post #2

"We didn't chase the fad of using every tool that was at our disposal". And he's even proud of it, lol

May be they have lucked out or may that is their ethos, that lets not use some of these optimizations until they have survived test of time.

There is nothing wrong to be proud about esp. given how things have turned out.

Re: “We didn't chase the fad of using every Intel CPU feature”

#27

Post by ahbs66 »

nottorp wrote: post #23
ahbs66 wrote: post #6

Earlier quoted context omitted.

That's a strawman. Your question is ridiculous. Features of a certain language/framework/etc != languages/frameworks/etc

Let's try again: would you work on your car using a chainsaw because it happens to be in your tool box?

No. I would use a more appropriate tool, because I will never refuse to use anything that's in my toolbox, like Theo did. :)

Re: “We didn't chase the fad of using every Intel CPU feature”

#28

Post by jcranmer »

yawaramin wrote: post #20
rhaps0dy wrote: post #18

Earlier quoted context omitted.

Huh, in what way was Theo right about Meltdown? Did he predict it? (just curious)

He predicted similar in 2007: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

That's not anywhere close to a prediction of Meltdown. Meltdown is a side-channel attack that can cross the user/kernel boundary. What Theo was predicting is that all chips are getting complex MMUs to the point that there are bugs in corner cases that could be exploited to create infiltration leaks. Side channel attacks aren't bugs, insofar as no one is really promising that you can't observe side channels.

Re: “We didn't chase the fad of using every Intel CPU feature”

#29

Post by yawaramin »

jcranmer wrote: post #28
yawaramin wrote: post #20

Earlier quoted context omitted.

He predicted similar in 2007: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

That's not anywhere close to a prediction of Meltdown. Meltdown is a side-channel attack that can cross the user/kernel boundary. What Theo was predicting is that all chips are getting complex MMUs to the point that there are bugs in corner cases that could be exploited to create infiltration leaks. Side channel attacks aren't bugs, insofar as no one is really promising that you can't observe side channels.

But the observable out-of-order execution used by these chips that led to Meltdown is a bug. Proof: AMD chips aren't affected by it:

> The Meltdown vulnerability primarily affects Intel microprocessors,[52] but some ARM microprocessors are also affected.[53] The vulnerability does not affect AMD microprocessors.[19][54][55][56] Intel has countered that the flaws affect all processors,[57] but AMD has denied this, saying "we believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture".[58]

https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...

Re: “We didn't chase the fad of using every Intel CPU feature”

#30

Post by guitarbill »

ahbs66 wrote: post #27
nottorp wrote: post #23

Earlier quoted context omitted.

Let's try again: would you work on your car using a chainsaw because it happens to be in your tool box?

No. I would use a more appropriate tool, because I will never refuse to use anything that's in my toolbox, like Theo did. :)

That's fine, but not a great analogy. Because once you ship software, everybody has access to that tool.

No matter if you agree or disagree, Theo/OpenBSD made a engineering choice and did what they thought was the right choice for OpenBSD users. As fellow engineers, we should realize how difficult that is, and that the discussion deserves a bit more nuance, depth and respect.

I still don't full understand the trade-offs.

Post reply on HN