fluffy87

See my reply to masklin in this thread for why this is incorrect. In release mode, the behavior of integer overflow in Rust is not UB/cannot happen, but modulo two arithmetic.

These two are not the same thing.

That’s unfortunately incorrect. That flag does not turn integer overflow into UB, which is what allows the C++ optimizations that assume it cannot happen, and can be used to prove that loops terminate, etc.

That flag changes the behavior of integer overflow from trapping to “modulo 2 arithmetic”.

If you want to change the behavior of integer overflow in Rust to “always assume it cannot happen”, you need to “hack” the compiler AFAIK.

If you believe this is incorrect, provide the flag that proves that (hint: such a flag makes safe Rust unsound and it therefore does not exist).

Note that Rust also traps on integer overflow, and it is trivial to „hack“ the compiler to disable this, and many have done so.

While on this microbenchmark you see a 3x slowdown with the LLVM backend, on large Rust projects like servo, Firefox, the rust compiler, etc. the slowdown is not even measurable.

Also, Rust provides you with unsafe intrinsics to opt-out of trapping in the particular line of code in which it causes an issue.

Probably whatever motor is Bosch selling to the highest bidder.

You don’t really hear much about Bosch because it’s not on the stock market. But they have a couple of huge research centers worldwide and their tech is used by every auto manufacturer in the industry.

Which threat? NVIDIA already licenses and sells arm cores. Arm is already part of their products.

No you are wrong. People living there have had children or have children. Everybody knows when making an exception is ok or not, or when the allocated trash associated to a household must be increase.

The assumption that people living there are intolerant of babies and families is false.

What was the back of the envelope calculation that suggested this would work?

Unit tests are a bad fit, you need to run a test that is representative for an actual work load.

A unit test that tests code that’s cold in practice would make it look like hot code, and be counter productive.

Rust does support PGO

KDE and Gnome Support Nvidia drivers on wayland.

I’ve used ATS, Idris and Rust, and I find ATS way more cumbersome to use for writing proofs than idris.

I’ve never used ATS to do what the GP is suggesting of incrementally wrapping C with proofs, but I can’t imagine this being simpler than just rewriting the C in Rust. You wouldn’t get the same proofs, but you would get memory and thread safety, which for many apps would be an incremental improvement.

I haven’t taught ATS, but I found it harder to learn than Idris, and I can’t imagine C programmers which have a hard time with Rust learning it quicker than they would learn Idris or Rust.

Can you do an AMA? Why did you create lithium? How long have you been working on it? What do you do professionally? What are your plans for it?

Those who work on these frameworks, and those interested in http framework benchmarking.

Some of the ideas developed in these frameworks percolate down to the PLs that use them and to the libraries they use, which benefits everyone. These frameworks also test new language features.

2x faster than the Actix Rust framework.

Rust, C++ just said “hi” to you again, it’s on. Time to make Actix fast.

Alternatively, just use geometric algebra instead of quaternions.

The actual Modern C++ design book from Alexander’s ci is about custom allocators and performance.

The irony.

Is there a way to make these data structures hardware friendly? So that SIMD instructions can be used, memory is traversed continuously, without multiple pointer indirections, etc?

Are there any blogposts about this?

I don’t even need access. Just need verified MLPerf results.

Which formats are notes exported to? Can they be exported to markdown + latex + images?

GraphCore has been claiming to be a generation further than the comptetition for over 3 years already.

This is easy to do when you don’t have to use any standard benchmarks (MLPerf) and do not allow anybody to verify any claims.

When will GraphCore enter MLPerf and let the industry verify their claims?

Until then, it’s vapor ware. I’d refer to this comment https://news.ycombinator.com/item?id=21530810

Also the A100 is cheaper, and it’s perf is verified by MLPerf.

GraphCore’s claims are just that, claims. Some of these have been debunked already by people with access to the hardware (eg promised 10x speed ups were more like 1x).

They can already do that without having to buy ARM.

I think they would be expending the money to grow their CPU team. The ARM engineers would be working on making Nvidia CPUs better, neglecting “public” ARM cores.

This would hurt small fish, but Apple, Amazon, Google, Tesla, Facebook, etc already have their own in house ARM teams.

GPUs have excellent support for branches. Pascal has divergent thread execution, Volta added forward progress guarantees, Ampere improves on this further.

There is a lot of research about doing databases on GPUs, and Apache Spark runs on GPUs today, with much higher performance than on CPUs.

This is precisely what happens if you have a dynamic array and you grow it with a growth factor of 2.

I wonder how it can auto generate safe bindings for C++.

To do that, it would essentially need to literally prove that the C++ code is thread and memory safe, which is an open research problem at Best, and probably impossible since it requires solving the halting problem.

If it can do that, then the actual binding generation would be the most uninteresting part of this work.

Definitely illegal. This is fraud.

You can use ParaView from Jupiter just fine ? You can even embed its views, pipelines, controls, make interactive notebooks, etc...

This is the scariest part of using machine learning as an engineer on any practical application as well.

Without an error bound, ML can’t be in charge of anything that could put human lives at risk.

This is also why I don’t understand all the hype about FSD / L5 autonomous driving. We don’t even know yet if such error bounds even exist, so we don’t even know if machine learning is even the right tool for FSD yet. All certification entities for control systems that put human lives at risk in aviation, automotive, etc. require those error bounds. So it actually doesn’t really matter if Tesla comes up with a “maybe L5” system, without right error bounds, their cars won’t be certified as L5 and drivers will need to keep hands on the steering wheel.

The claim that CMake is the least worst C++ build system that we have is pure BS.

In my last 3 professional C++ projects I’ve actually used Rust’s cargo tool as my build tool for C++ code. Infinitely better than CMake, plus you use Rust as your scripting language for your build system, which has great libraries for it like the cc crate, and pretty much a crate for whatever it is you want to build (eg ispc? no problem).