mtanski

I'm thinking you might be right.

It's going to be really hard to give up real world gains from branch prediction. Branch prediction can make a lot of real world (read "not the finest code in the world") run at reasonable speeds. Another common pattern to give up would be eliding (branch predicting away) nil reference checks.

> short of entirely preventing speculating code from being able to load things into the cache

Some new server processors allow us to partition cache (to prevent noisy neighbors) [1,2]. I don't have experience working with this technology but everything I read makes me believe this mechanism can works on a per process basis.

If that kind of complexity is already possible in CPU cache hierarchy I wonder if it's possible to implement per process cache encryption. New processors (EPYC) can already use different encryption keys for each VM, so it might be a matter of time till this is extended further.

[1] https://danluu.com/intel-cat/

[2] https://lwn.net/Articles/694800/

After thinking about this I think you may be right. It might be hard (or impossible to do in practice).

> or within the same space as the executing address

That's probably a good place to start from. I'm guessing there still would be issues here with JITed code coming from a untrusted source.

Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.

JIT engines (and compilers) often generate a familiar instruction patterns. Many JIT engines Target specific languages (like JS) and as result have "simpler" optimizers (less time to do this) and possibly more stable instruction patterns. So my money is on somebody fuzzing the required JS code.

Please re-read my above comment. There is no new API. The DAX userspace API is mmap.

This work is experimental but you can mmap a single file on a filesystem on this device using new DAX capabilities. Most access will not longer require a syscall.

This comes with all the usual semantics and trappings of mmap plus some additional caveats as to how the filesystem / DAX / hardware is implemented. Most reads/writes will not require a trip to the kernel using the normal read()/write() syscalls. Additionally, there is no RAM page cache baking this mmap instead the device is mapped directly at a virtual address (like DMA).

Finally, flush for these kinds of devices is at the block level implemented using normal instructions and not fsync. Flush is going to be done using the CLWB instruction. See: https://software.intel.com/en-us/blogs/2016/09/12/deprecate-...

LWN.net has lots of articles and links in their archives from 2016/2017. It's a really good read. Sadly I do not have time to dig more of them up for you. Do a search for site:lwn.net and search for DAX or MAP_DIRECT.

The claim is that it's 2% to 5% in most general uses on systems that have PCID support. If that's the case then I'm willing to bet that databases on fast flash storage are lot more impacted then this and pure CPU bound tasks (such as encoding video) are less impacted.

The reality is that OLTP databases execution time is not dominated by CPU computation but instead of IO time. Most transactions in OLTP systems fetch a handful of tuples. Most time is dedicated to fetching the tuples (and maybe indices) from disk and then sending them over network.

New disk devices lowered the latency significantly while syscall time has barely gotten better.

So in OLTP databases I expect the impact to be closer to 10% to 15%. So up to 3x over the base case.

If you bypass the page cache you do not have read()/write() and mmap you avoid the syscall overhead. This matters a lot for high IOPs devices. Also these new fangled devices claim support word cache line sync using normal cpu flush instructions. Also avoiding fsync syscall.

We're still learning, but it looks like pgbench is 7% to 15% off:

https://www.postgresql.org/message-id/20180102222354.qikjmf7...

I think the model for cloud vendors would be quite complicated. Not every version of the CPU and not every application is impacted as much (new intel processors with PCID will suffer less).

Add on top of that the fact that a lot cloud customers over provision (there's good scientific papers on how much spare CPU capacity there is). Cloud service providers that sell things on a per request / real CPU usage model (vs reserved capacity) prob benefit more.

Also, you can't just separate trading in AWS or GCE from the rest of the core business.

Potentially business units of DELL, HP, IBM, ... should do better as people use this as a justification to upgrade overdue hardware they should cover 5% to 10% lower performance (needing more units to cover that).

This comment further down thread mentions it's 20% in Postgres. https://news.ycombinator.com/item?id=16061926

In the future this possible on Linux with the filesystems that support DAX. Currently this all pretty experimental with lots of work being done in this space in the last two years.

But this will require you to have the right kind of flash storage, right kind of fs, right kind mount options, and probably a different code path in userspace for DAX vs traditional storage.

So we're a little ways away from this.

As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO.

And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.

It sounds like databases on very fast storage will be updated. Tons of syscalls made for disk io and network io.

How's that? Weworks is buying in one market and reselling (with value adds) in a different market and profiting off this difference.

They lease large commercial (multi-story) offices from owners and building management companies and rent out to 100s of small businesses in the same space.

Price controls is a dirty term we refuse to talk about in the good 'ol USA. Most other healthcare systems in the world with low prices have some kind of combination of it when it comes to drugs and procedures performed. The AMA has been fighting any kind of single payer system for 50 years now. They know that a single payer system will result in some kind of price controls. On one hand you understand their point of view (maximizibf their income well being) and on the other hand you understand the issue with that for all of society.

Having said that it's not just the income of doctor. Healthcare administration is expensive in the USA. Many doctors offices spend a non insignificant amount of money on just the billing, collection, insurance administration. The health insurance system as we naturally ended up with sucks up a non insignificant amount of money out of the system. It also leads to these weird distortions where every insured procedure is discounted to the insurance agency like 75%... But not if you deal direct.

Additionally, operational insurance (malpractice indurance) is another non-insignificant contributor. Our culture and our legal system ensure that many doctors practices will pay a multiple of a practitioners salary in malpractice and related salary.

If we want cheaper healthcare all of these need to be addressed one way or another. I am not hopeful that we can escape this local maxima that we're stuck in. Every attempt at change will be meet with fierce opposition from the current status quo.

Their business model is not complicated. They arbitrage office space. Office space is expensive to rent (operationally), takes a long time to find a tenant, and there's a lot of different kinds of leases (short/long term) and most office management companies are not equipped to deal with 100s of tenants in a single space. Similarly there's lots of pain points when you're the trnter, in terms of finding the space which can be time consuming, deposits, contract negotiations, needing to setup utilities (esp internet).

Wework opertionalizes all of things putting them in position of being able to arbitrage this disconnect in the market.

firmware needed by modern nvidia cards is cryptographically signed

In an ideal world poor quality publications regardless of audience size would end up being penalized for poor quality reporting. Sadly, the world is not ideal and markets at best an approximation of efficient markets.

CNBC is prime example of this for me. Nowhere is it more apparent that in Jim Cramer. The hyped-up advice he gives people on investing is terrible. It's worth while watching his interview with John Stewart when they talked about the housing bubble. The whole sorry, not sorry squirm. But this is just the tip of the iceberg for CNBC.

To me the important question is: can we engineer (not just software) a solution that does rewards good journalism and punishes bad journalism?

Talk about a shitty god.

As somebody who’s debugged and inspected machine code generated by expanded templates I can tell you this is not really a problem. At -O2 or -O3 optimization level with GCC or Clang almost all of that get unlined, removed, remerged and just optimized away. At -O0 god help you with single stepping any template code (like unique_ptr) in gdb.

If you have day old bread it's "legacy crust". And, who wants legacy crust.

This was my original model when I came up with the idea; in fact, my v1 hack used recv and MSG_DONTWAIT. For a number of a reasons the kernel community did not want to overload that interface and that flag.

Besides some technical reasons, the big reason was an "impedance mismatch" of the recv API which was working with stream data. In that context you're depending on another party send data. Also, you can wait on this to happen using another API (select et. al) so the buffer will be filled not by your actions. On the other hand preadv2(..., RWF_NOWAIT) is not going to trigger any more read in and theres no wait to wait on the data. Although the previous statement is not a 100% true... preadv2 may or may not trigger readahead (if it's enabled).

Here's the whole thread about it... if you're interested in the history of how this came to be: https://lkml.org/lkml/2014/7/24/787

In really new linux there is a preadv2 sysscall that was merged. preadv2 supports a flag RWF_NOWAIT to tell the kernel to not block if a read requires uncached data.

This lets you play around with policy for blocking reads in user space. Examples: try to make progress on partially read data & queue up the rest on another thread; try performing reads from your network thread and if unavailable queue up the blocking read onto another disk thread & serve a different request.

There's no RWF_NOWAIT support for write in pwritev2. But it's technically possible to implement it and if your write will cause a writeout to disk return EWOULDBLOCK.

LWN description: https://lwn.net/Articles/612483/

LWN summary of my talk: https://lwn.net/Articles/636967/

Final patch set by Christoph: https://lwn.net/Articles/731700/

Disclaimer: I'm the author of the preadv2/pwritev2 syscalls. And the original author of the support for RWF_NOWAIT, which Christoph Hellwig took over. So feel free to consider this to be self congratulatory.

Correction: It looks like there's a patch set floating around for adding support for RWF_NOWAIT in pwritev2 as well. https://patchwork.kernel.org/patch/9787271/ (comment from Christoph)

LWN has had quite a few past articles that went into details of issues with processing network packets at line speeds on modern OSes and machines.

https://lwn.net/Articles/629155/ https://lwn.net/Articles/713918/ https://lwn.net/Articles/719850/

The block layer has gone through somewhat similar issues as some storage devices started approaching RAM speeds.

Not to mention, there's a non-insignificant portion of the population that's allergic. Generally it's not life threatening but most commonly it'll lead to cold like symptoms (nose/head congestion, trouble sleeping).

In principle that's true...

In reality 1. You can be shot by a cop even if you do not pose a real threat (they just need to claim they though you might have a gun, simple) 2. People are routinely kept in jail for unreasonably long time because their families cannot afford bail often on things charges are dropped for later 3. Ever hear of civil forfeiture?

The whole thing is a nice story that we love to repeat to each other. Maybe it was easier to accept that during the cold war when the other guys were worse and news traveled slowly (or didn't). It's pretty apparently that isn't true given the quick news cycle... and opening any US history book.

Sometimes I wish I could myself become a corporation. Seams it's much easier to exercise your rights as a corporation.

> I think one of the best outcomes of a competitive CPU market is that the artificial limitations Intel introduced to segment their CPU market are going to have to die.

Actually, for me following at home ... it seams like they have a whole new segmentation scheme. So not killing it, just changing it.

I understand the mission of the ACLU, including their representation of people I agree with / don't agree with.

But, I'm not quite sure why they are representing Milo... mostly because he can afford and their resources are better spent on cases where people can't. If they just filled a Amicus brief in his defense, i'd be perfectly fine.

If this was a trial then and I believed he was unjustly fired I'd be right there with you. But we're now in the court of public opinion and I'm not really sure it's in his best interest to speak up.

> When the whole episode finally became a giant media controversy

This is a bit self referential.

But seriously who cares. People get fired daily, many of them get fired unjustly... and you know what we don't write tons and tons of articles about them.

At first I felt a bit bad for the guy... socially awkward guy who jumps to some misguided conclusions based on quoted research. Ideally, he would get some kind of training maybe an explanation from a sociology researcher how he incorrectly jumped to conclusions.

But this woe is me shtick, reaching out to the alt-right publications, then continuing on to do an op-ed on the WSJ. I no longer feel bad for him; he got what he deserved.