That OP just pointed how the provided example would actually work in an OOP project, not their fault to have to work with an example that is indeed an inventory management problem.
Well, at least it was slower a while ago, for the networking code I was working on. Could be outperforming for other use cases. As for perf, when you run it you can see that a lot of cpu is sent on work stealing and other bookkeeping. Which is fine, and the single threaded runtime doesn’t have some of that, so I use that a lot.
For me async is about ergonomics first of all. When you perform parallel tasks on multiple threads it is hard and ugly (in cross platform Rust at least) to implement any sort of intricate cross communication, as communication between threads is asynchronous by nature. And it is very much impossible to stop a thread externally.
Async rust lets you implement different combinators on async tasks and cancel them effortlessly.
As for performance, tokio is not exactly a zero cost abstraction. Just run perf on a tokio program to see how big of overhead it introduces. It has claimed to be zero cost from the start, and since then it has done at least two major performance overhauls, to prove the point. That being said I love tokio and its ecosystem, but it is ergonomics, not speed that I love. That being said async-std was much slower for the networking use case that I had, so overall tokio is as good as it gets.
I'm the co-author of one of the papers referenced in the blogpost, (Fast Quicksort Implementation Using AVX Instructions), we did write the AVX512 code back in 2015, just had nowhere to run it, at least publicly. The paper also very explicitly says that the lookup tables can be instead replaced by the AVX512 compress instructions. The code for that paper is available in https://github.com/vkrasnov/avx_qsort
Maybe, maybe not, since it is a custom configuration can be anything. A coffee lake CPU should be capable of 25Gbps of AES-GCM for a single connection. Not so much for ChaCha20-Poly1305. There is a significant difference.
I don't recall exactly, but at least a day each I would say? They were all performance critical, so had to put some effort. Two of them were for internal nginx patches, but were storing data a bit differently so code couldn't be quite reused. In languages with generics hashmaps are trivial to reuse with zero performance cost.
Ukraine want to punish Russia in whatever way it can, which is totally understandable, but it will leave Russians with only internal propaganda, which will make them even easier to control for the regime. Not sure how is it strange?
When I was working at Intel, Boris Babayan, one of the original creators of Elbrus and an Intel fellow back then, came to visit the team I was working on. He was working very hard to sell the VLIW to us. That was post Sandy Bridge, which turned out to be a great success, and when Intel already realized what a disaster Itanium was. Yet Babayan was still strongly convinced that VLIW is superior if we could just make the compilers a little bit better. Sufficient to say that it is practically impossible to perfectly schedule VLIW at compilation time, and is a very much solved problem for OOO execution. We were all very much bewildered and just ignored him for most of the visit. I really have no clue why Intel is keeping him around.
There is now doubt the M1 is very much cooler, but they also made the laptop much thicker to allow sufficient airflow without hitting the fans. I am pretty confident that this is the main reason to make it so much thicker than the Intel one
Huh? I am
developing natively in macOS for a Linux server using Rust. Everything just runs fine on both. Unless I need to go really low into syscalls I have no reason to be writing and testing my code on Linux.
Awesome, now where do I sign for the free fastly account? Oh right, they only do enterprise, so who the hell cares? Cloudflare OTOH caters for the whole spectrum.
It doesn’t matter. That wasn’t a bash against Graviton 2, I am just really looking toward the next generation, because I think it will be so much better, but sadly no announcements yet.
I mean it was pretty competitive almost two years ago, but AMD made a huge leap since then. Not sure why saying a two year old CPU is outdated is a controversial take.
They describe how they got the info in the original article, and then deduced the rest. They called to confirm the suspcicions, which were already enough by themselves. They got lucky that the details were sufficient to make the killer think he really talks to someone from his office.