kryps

No, you can't do the same thing in Rust, because Rust crates and the standard library generally use the global allocator and not any arena you want to use in your code.

Previously: https://news.ycombinator.com/item?id=45703926

The paper does not make that claim. According to the paper the probability of recovering the correct value of a single bit is 96% for a pristine drive and 56% for a used drive, both better than a coin toss. Of course the probability gets worse if one tries to recover more bits (but still better than n coin tosses for n bits).

Can we have " (2020)" added to the title?

You are not doing a release build.

WSL2, correct.

Yep, see below. With WSL and an ext4 virtual disk it takes only 29 seconds. Still quite a bit more than the 22 seconds on the Macbook.

cargo install on WSL2 uses the non-mapped home directory, which is on an ext4 virtual disk. That is probably one reason why it is six seconds faster.

Nope, pure compile time on a Core i7-10750H with Windows and Rust 1.52.1, antivirus disabled. WSL did not make much of a difference though (29 seconds).

It does not just feel faster, in many cases it is faster.

E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.

As far as I can see it does not use SIMD for UTF8 validation, only likely/unlikely instrinsics, see https://github.com/hsivonen/encoding_rs/blob/e98a2096ab09c92...

Check the benchmarks section (https://github.com/rusticstuff/simdutf8#Benchmarks), second table. simdutf8 is up to 28 % faster on my Comet Lake CPU. However with pure ASCII clang does something magical with simdjson and it beats my implementation by a lot. GCC-compiled simdjson is slower all around except for a few outliers with short byte sequences.

The algorithm is the one from simdjson, the main difference is that it uses an extra step in the beginning to align reads to the SIMD block size.

How is the performance compared with simdjson (https://github.com/simdjson/simdjson)?

Tip: Rust BufReaders default to 8KiB buffers which are way too small for high-performance sequential NVME I/O.

User namespaces remapping is still not supported in Kubernetes, see https://github.com/kubernetes/enhancements/issues/127

Not sure about the speed compared to Genymotion. HAXM is still required but less buggy now.

The guy is no longer working for soundcloud.

Make sure to fix the zippers in place. Otherwise it is very easy to still open the bag by just prying open the zippers and closing them again by moving the tied-together zippers.

https://www.youtube.com/watch?v=G5mvvZl6pLI

For critbit trees the entire string _up to_ the critical bit where the string differs from all others already in the datastructure needs to be scanned.

critbit trees degenerate badly if you store strings and their prefixes, e.g. storing a, aa, aaa, ...

http://en.wikipedia.org/wiki/Steganography

Except for the Glacier retrieval fees which can be insane if you choose to retrieve more than 0.17% of your stored data per day.

https://aws.amazon.com/glacier/faqs/#How_much_data_can_I_ret...

The PoC exploit fails on Android 5.0.1 with latest Google Play Services.

So we won't have a public debate about war anymore because it might cause a PTSD-induced breakdown in veterans?

Everyone cares about armv7 because it is the CPU architecture deployed in over 95% of the mobile devices.

A differing opinion about MIPS helmets from the "helmet advocacy program of the Washington Area Bicyclist Association" (consumer-founded): http://www.helmets.org/mips.htm

Tuned how? By being slow as f..k? That actually makes it much worse for small batteries.

Google's API console is lightyears behind the AWS console. Similarly for features, documentation,support forums and stability. Example re stability: The cloud storage browser fails to display stuff stored in it regularly with backend errors.

So the only way they can compete right now is on price.

Theoretically PNaCL code should be executing much faster than emscripten-generated Javascript. Of course we should do real benchmarks, YMMV and so on.

The second real test. Android Renderscript uses LLVM for portable bytecode already.

This study is from 2010 (Linux kernel 2.6.35-rc5).