diamondlovesyou

Be that as it may, I wasn't talking about C++. Also, the integer operation optimizations require no such flags on either side, and yet the resulting machine code was still very poor for Rust.

You can just pass a reference/mut ref to the first element of the slice. This is actually how the generated kernels in my Rav1e PR do it, just for the aliasing reason you mentioned.

These blocks are non-continuous. It operates over a part of a row, where the start of the next row is the start of the current row + some stride.

I mean maybe? But I probably wouldn't anyway for this case as a slice reference is actually a "fat" pointer (ie twice the size of a normal pointer) and the length of the slice won't be used (the block size is known per kernel); LLVM might delete the length part anyway.

These are automatically generated kernels, so readability isn't the primary concern here.

Not really in this case; Rav1e runs over blocks of image planes (like say a 16x16 block of a specific 720p color channel), so there is no continuous slice to iterate over.

True. I should have explained that better. If you're accessing an array, you'll have to do the pointer offset-ing yourself (otherwise you're using a slice and all the checking that entails). Thus, you can't use a reference type, because reference types don't have `<*const T>::add` like pointers do (also, `&T as usize` is invalid; you have to go through a pointer type first). I suppose I assumed you'd be accessing an array/slice; references otherwise are fine.

I have some experience with this, ie ensuring LLVM optimizes and codegens the "best"! I have been working to generate target independent "kernels" for the Rav1e AV1 encoder and have had to do a lot of unidiomatic things to get LLVM to generate machine code similar in quality to hand written ASM. Granted, this is on integers and not floats, but the same principles should apply.

What I've found is that you need to ignore most of Rust: use/load raw pointers, don't use slices, unroll manually, vectorize manually, and check preconditions manually. You'll still get the amazing type system, but the code will have to be more C-like than Rust-like.

* raw pointers: LLVM is pretty good at optimizing C code. Rust specific optimization needs some work. (edit: I assumed arrays here, so you'll need the pointer for offsets; references are still okay. You'd also use the pointers for iterating instead of the usual slice iteration patterns)

* no slices: index checking is expensive, not to the CPU, the CPU rarely misses the check branches, but to the optimizer. I've found these are mostly left un-elided, even after inlining.

* no slices: slice indexing uses overflow checking. For Rav1e's case, the block/plane sizes mean that doing the index calculation using `u32` will never overflow, so calculating the offsets using u32 is fine (I'll have to switch to using a pseudo u24 integer for GPUs though, because u32 is still expensive on them).

* unroll manually: LLVM would probably do more of this with profiling info, but I've never found it (this is subjective!) to do any unrolling w/o. Maybe if all the other items here are also done...

* vectorize manually: Similar to unrolling. I've observed only limited automatic vectorization.

* And to get safety back: check, check, and check before calling the fast kernel! Ie wrap the kernel function with one that does all the checks elided in the kernel.

Source: Wrote https://github.com/xiph/rav1e/pull/1716, which speeds up the non-asm encodes by over 2x!

Those two sides aren't mutually exclusive. Demand for content creates both.

Privacy implications aside, we're actually not talking about a human being. We're talking about a(n) (abnormal) cluster of non-critical cells in a human. You and I shed millions of these (all-be-it normal) cells everyday, in the form of skin flakes and hair. Similar if your skin is pierced, causing a bleed. Semen if male, mucosal tissue if female (and possibly the egg), feces, urine, all contain human cells. This isn't robbery.

My Fitbit also has a heart monitor. It never confuses "just lying there" with actual sleep, for me at least.

Note that your heart rate slows during sleep, which is useful for detecting sleep cycles etc. Which is why I mentioned the heart monitor.

You are being downvoted because this is not Reddit.

A lot of people play with 144hz (what I play on) and some even higher (240hz). Which is just under 7ms and just over 4ms, respectively.

Not for some games, where low settings are used on purpose. The CPU is the bottleneck in those cases. cough Overwatch cough.

Play, seriously, a competitive shooter/fps and you'll also start noticing the difference. 144hz is buttery smooth compared to 60hz.

Ehhhh, I'd leave it as is. Unless you have business licenses in EU countries, EU laws have no legal authority over you. If you do have such licenses, then you're probably big enough to foot the bill and possibly also can't afford to not foot the bill (due to suspended licenses).

This privacy thing is, like, their option, man. Even if you and I agree with the EU.

No. Considering Chernobyl on its own, treating all radiation exposure cases which are above the statically insignificant cancer rate threshold as deaths, and coal is still more dangerous per kWh. [Source](http://www.the9billion.com/2011/03/24/death-rate-from-nuclea...).

After the accident, Chernobyl continued to provide power to Ukraine, up until it's last reactor was shutdown in 2000.

It's not implementable by local devices: your LAN is much faster than your WAN link, in most cases. Your router/modem does the packet dropping. But only your router/modem knows how much unused throughput is available at any moment, so rsync can't know how much it can use. Sure, rsync can look at TCP packet retransmits, but that will still cause other streams to experience an (assuming a lot of things) "equal" amount of drops too.

So, you get a lot of complexity for not a lot of benefit. However, Fuchsia is destined for mobile devices, which may not have the LAN-WAN bottleneck, so this could see some benefit.

One can't control those that must deploy IPv6 first. That's the problem NAT solves. Developing NAT was likely not easy; consider how many implementations f it up anyway.

As a current user of ECC RAM w/ a Ryzen 7 1800, I can tell you it works.

We need faster ECC RAM though: the external RAM speed affects the internal AMD Infinity Fabric, which provides inter core comms.

What? His success reflects nothing on anyone else and doesn't have anything to do with sympathy. He/her is saying that current real estate rules aren't helping incentivize rational decisions to sell. Why would anyone do something that results in a worse (read: not the best) outcome for them?

Depends. Erlang's scheduler is clever: if the receiver is asleep waiting on its inbox, sending to it will switch the running process to the receiver and back, all without hitting the scheduler logic. This is a great benefit for "thread" (in Erlang it's a process) pools, which are very very widely used in Erlang programs. It's really the best of both worlds: no Erlang context switch and it's completely transparent to one's codebase.

This isn't possible if the receiving process's inbox is non-empty or it's running. Then the cost should be around the same, assuming your C++ implementation is at the same level of quality as the Erlang VM.

I'm working on a same-source MIR to "HSA IR" for Rust, allowing full use of generics and closures. The first target will be for SPIR-V, but it'll be easy enough to leave the door open for other targets, including FPGAs, so I'll be writing code to allow that.

This project is in it's early stages; I've finished the research in the Rustc compiler and figured out how I'm going to provide new "primitive" (ie a 4 by 4 matrix, a 16bit float type, etc) types to the framework (and work closures in), and have started writing code, but I have nothing working as of yet.

Wouldn't that incentivise insurance company treatment exclusivity?

Interesting. I have an AMD card and experience that too.

What I'm about to say may go against what many of the HN community believes. This isn't an attack on anyone's beliefs; I'm merely expressing my thoughts in an attempt to solicit constructive discourse.

I'mma be honest. I don't understand the repulsion at the possibility of corporation X knowing my personal info, (excluding the usual things like bank account info, SSNs, etc) like my location, search history, etc. To be clear, I'm 10000000% against warrantless (FISA court "warrants" excluded) government access to this information. Here's my reasoning:

* Governments

Have the power to arrest and detain on a whim. Not to mention, use drone strikes.

* Corporations

... Don't. These entities have self-interested incentives to provide tools which are economically productive for users. For example, a smarter smartphone, whatever that may be.

Regarding Vizio, my grip is that Vizio's goal (for this product at least) is to make a profit producing TVs. So, after the TV is sold, the product is individually "finished" (not considering support stuff). So, then, what other product is the data collection for, and what does this product give me in return for my data? The answer to both is no, and not just for Vizio.

Maybe I'm naive.

Banning something is a good way to prevent such studies from ever happening.

Also, they aren't banned. The FDA just made it so small businesses wouldn't be able to make the ecig products (basically). Big tabacco, however, is able to take the hit. Take it how you will.

I agree. Most of the HTML I write is to create structure for CSS to use. For example, a `div` is a container, but we put it on the content side.

What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeholders declared in the "CSS". I've omitted programmable considerations cause this is a HN comment and not intended to be formal proposal. Not surprisingly, the web has kinda already shifted towards this, through the use of JSON APIs in JS.

Note to anyone not already familiar: in Elixir, character strings are all binaries from the start. Just to avoid the notion that Elixir follows the mistake of strings-are-linked-lists from Erlang.

Not if an independent organization (think a Corp, not a gov) is the party responsable. They would have no incentive to do such a thing, in fact they would have a negative incentive.

Too bad nuclear tech is basically too regulated for any non governmental organization to experiment inexpensively, not to mention the other nontechnical issues.

What if (full) use of the car is required? Sometimes things break (or rather, a threshold is crossed), but it won't become known to the car and thus the owner until the car is needed. A wife entering labor, for example.

Not sure why you were down voted without refute. Gerrymandering is a known and ignored problem in a lot of states, including my home state of Kansas (where Lawrence is split down the middle).