volta83

> I live only in CUDA land, I’m a bit ignorant of the other platforms, so I’m not sure what granularity of workgroups is here. Generally speaking you can’t rely on individual threads executing in any particular order, no matter how many there are, so yes you can’t have one thread look at data from another thread without some kind of synchronization https://news.ycombinator.com/item?id=29257343

The only thing Raph relies on is, that if and only if a thread ever starts to run, then it will continue to make progress until it completes.

This is something you can rely on, e.g., on NVIDIA GPUs since Turing/Volta, and allows you to use atomics, barriers, semaphores, etc.

This paper ported a CFD application, which had a tuned CUDA implementation, to std::par: https://arxiv.org/pdf/2010.11751.pdf .

In Table 3, first and last columns shows the performance of CUDA and std::par in % of theoretical peak.

The rows show results for different GPU architectures.

On V100, CUDA achieves 62% theoretical peak and std::par 58%.

The amount of developer effort required to achieve over 50% theoretical peak with std::par makes it a no brainer IMO.

If there is one kernel where you need more performance, you can always implement that kernel in CUDA, but for 99% of the kernels in your program your time might be better spent elsewhere.

What are the pros/cons of Alloy over, say, Iris ?

TL;DR: the parent doesn't know what they are talking about and for some reason is burnt over OpenCL which is a horrible ""standard"" (Khronos extension over C and C++, not actual C++ support, in the C++ ISO standard proper). Maybe the reason people like HIP and OneAPI is because they are not aware that you can program GPUs using ISO C++ and ISO Fortran because... Intel and AMD don't support those?

> Absolutely false. [...] If you mean something like `std::par` [...] not really GPU-specific

std::par is the ISO C++ standard feature for parallel programming, this includes multi-core CPUs, SIMD, GPUs, FPGAs, etc.

NVIDIA compilers run std::par on both CPUs and GPUs.

I've been using it for over a year, and so have a lot of people I work with.

You claim that this is false, but this is demonstrably true, and there are many peer-reviewed papers of people using this with NVIDIA compilers already.

The claim that this model of GPU programming is not portable, is false as well, since Intel and AMD claimed that this is portable to their GPUs when they added it to the C++ standard in 2017.

The claim that this does not deliver performance portability is also false, since we have verified performance portability across 3 NVIDIA GPU architectures, and using Kokkos, which exposes a similar programming model, also to Intel and AMD architectures.

Intel and AMD voted to add GPU support to the C++ and Fortran ISO standards.

Are you implying that they did a bad job and added the wrong GPU support to ISO C++?

Or maybe that Intel and AMD don't care about C++, and either added GPU support to it that they could not implement, or don't care about adding C++ support to their GPUs?

Playing devil's advocate here, no matter how you want to frame this, it just does not look good for Intel and AMD.

NVIDIA, Intel and AMD sit on the ISO C++ and ISO Fortran standard committees. They voted GPU support into the C++ 2017 and Fortran 2018 ISO standards. While NVIDIA implemented this YEARS ago, almost 5 years after these ISO standards were voted in, Intel and AMD have not even announced a plan for implementing GPU support for ISO standard languages on their GPUs.

Instead, Intel and AMD strategy is pushing applications to "rewrite CUDA with HIP/OneAPI", which are not real standards and are no more portable than CUDA. The people claiming that they are "open", probably also think that OpenACC is an open standard, even though it mostly only runs on NVIDIA GPUs.

If you care about portable GPU code, unfortunately, NVIDIA is the only vendor that actually delivers.

You can take your standard conforming C++ code _today_, not a single line of CUDA, OpenMP, OpenACC, etc. and the nvidia compiler compiles it and runs it on GPUs and multi-core CPUs. You can also take your normal Python NumPy code and run it on NVIDIA GPUs "as is" without changes.

It doesn't get any more portable than that.

I don't understand how there are so many people in these threads that apparently care about portability happy about AMD and Intel rewriting open source applications in their proprietary vendor-specific technologies, instead of angry about them pushing their proprietary technologies, instead of implementing GPU support for ISO standard languages, just like NVIDIA does.

From the same source two weeks ago: https://www.nextplatform.com/2021/10/26/china-has-already-re...

Do they read their own news?

China won Exascale. Twice. Before anybody else.

Is there an MI200 systems in the Top500 yet?

Supercomputing 2021 is running and the updated November 2021 Top500 list was announced.

There is only one system in the top 10, and that's an NVIDIA A100 system from Microsoft.

The only 2 systems with > 100 PFLOPS are Summit and Fugaku.

What's rust support for structured concurrency ?

C++ appears to be going to use it as its "main"/"most fundamental" asynchronous algorithms model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p230...

Seems quite a bit more flexible at least than Rust futures, but I am not sure I understand how they exactly differ.

Thanks for clarifying.

I enjoyed your post, and the other issues mentioned were easier to follow and understand what you mean.

I'm sorry that this happened.

> Well, no. They didn't 'fight' for that, they complained about it. For a while they decided that LVFS wasn't a right fit and went with their own tool and infrastructure[0].

So why is this a problem ?

If LVFS isn't a right fit, cause its missing a feature, and they prefer to roll their own system instead of submitting a 100 LOC patch, that's kind of up to them ?

> System76 & the LVFS > [...] > Later on the LVFS team put in work to support the use case of System76 so that vendors could use the LVFS without any sort of reporting. > https://archive.is/mH4dO

The goal of the author here is to show how bad System76 behaved. But after reading this, clicking the links, and reading the PR that actually got implemented (link above) my take is that System76 had to fight for years to get an option added to fwupd, to avoid their users from getting tracked when downloading system76 firmware through the tool.

That... doesn't sound like evil to me? I didn't knew that fwupd collects statistics about which firmwares my laptops download, from where, when, etc. and sends them to the hardware vendors. Is there a way for users to disable this tracking for all firmwares from all vendors?

If anything, this actually makes me want to get a System76 laptop.

Sure: TBAA, access to invalid union field (in C++), etc.

Many of them are impossible in theory to check, and many are impossible to efficiently check in practice.

The implementation of the Rust abstract machine - miri - stops execution of Rust programs when they exhibit undefined behavior.

C, C++, etc. don't even have implementations of their abstract machines. They don't have one existing as a goal. And they are happy to make certain operations exhibit undefined behavior even if that implies that it would make an implementation of the abstract machine that traps impossible.

This is why even if you were to combine valgrind with address sanitizer, memory sanitizer, thread sanitizer, undefined-behavior-sanitizer, and other existing C and C++ tools, there is still a lot of classes of undefined behavior that these tools can't detect.

That's fine in C and C++, but not fine in Rust. In Rust, if we add a new type of undefined behavior, the constraint is that it should be (demonstrably) possible to extend miri to detect it, such that if a user doesn't know whether some program exhibits undefined behavior for some inputs, they can just run it under miri, and miri will precisely pinpoint which part of their code exhibited undefined behavior and why, and how their program execution got there.

Your original comment reads like a feature request.

Since now I know that you knew that the feature you were requesting is impossible to implement, and you did not mention that in your feature request, now... i have no idea of what the goal of your comment was.

> I'd kill for a "volatile" with guaranteed semantics in Rust. Possibly more than one person.

The reason people ask for this is because they haven't thought this trough.

Even if the compiler "preserves" all volatile operations, the HW does not.

A trivial example is WASM. Rust can generate WASM code that, when using volatile, has many duplicated loads and stores in some order. Then the browser runs a WASM optimizer on the WASM code, which discovers that these instructions are redundant, and there you go, your program now doesn't do what you wanted anymore (formally, it never did).

x86, ARM, PPC, FPGAs, GPUs, etc. all do this in HW as well. So while you could argue that, e.g., WASM should have volatile loads and stores, the same argument can be made at the next level down below, down to hardware.

You'd need to ask every hardware vendor for some sort of serializing loads and stores, and people have done that, and vendors have implemented that, but then when users finally got what they wanted, they complained that they are too slow, so at that point they just stop using volatile and use atomics which is what they should have done in the first place.

> consume

How do you use the consume ordering in Rust today?

So many thoughts.

* Rust threads run on CPU cores, but also GPU cores, FPGA cores, and a wider range of nastier hardware than Linux kernel threads run on.

* The author implies throughout the text that safe Rust operations might not be allowed in unsafe Rust. This hints at a deep misunderstanding of how Rust works.

* C, C++, and similar languages, do not have as a goal to be "sound". Soundness is, however, core to Rust's value proposition.

* C, C++, and similar languages, do not have the goal that undefined behavior must always trap in their abstract machines. But Rust does.

* C++ and similar languages do not have the goal of forever-backwards-compatibility (e.g. C++ breaks backwardward compatibility on almost every new standard release). Rust, however, guarantees that all programs written for Rust 1.0 in 2015 that have no undefined behavior will build and run correctly _forever_.

* Rust has many compiler backends, e.g., LLVM-IR, GCC, Cranelift, SPIR-V, etc. Rust code is translated to the IR of those toolchains. That is, those IRs would need to be extended with the new semantics as well to be useful.

> But again, this decision rests not with me, but with the Rust communty.

The Rust community needs people working on formalizing the memory model further. So if they are interested, they should jump right in.

They should probably start by understanding Rust as is today, learning about unsafe code, and well the blog post cites https://plv.mpi-sws.org/rustbelt/rbrlx/ , but it is clear from the exposition that the author has not deeply understood that paper, so maybe they should also take a deeper look at that. All the proofs are open-source. So if they think they can extend the soundness proofs with new features that are also sound, that could be a place to start.

Not yet, but new regulation is coming that forces all new chargers from 2023 onwards to sell to all car.

"The right to build a charger comes with responsibility to service electricity to any EV car."

The EU, and in particularly Germany, is strongly nudging Tesla that, if they do it now, then right now at least they can do it in their own terms, and existing experience can flow into legislation.

If they wait, then they will need to complain with whatever is legislated, and without any experience, they won't have a seat at the table (while other EV charger systems with experience will).

I do every day, smaller bakery (no chain), they don't take cash anymore since COVID.

So you take the 0.01% of all university students, that are accepted into a PhD program, and then take the 0.01% of that ?

So 0.0001% of all university students, and then... work three times as hard as them ?

Working harder gets exponentially harder the harder you work. So... 0.0000000000001% of all students then ?

And now, in your application form for a PhD program, you want to convince an employer that they should hire you because you think in you are in that bracket, without any proof that backs it up, even though if for some reason you are not, things catastrophically fail for your employer ?

Yeah good luck with that.

It's a parallelism.

Somebody told them to get an abortion, and they just did. But I know better, I know what's best for them, and I know and I should decide what they should be doing with their body. They should not be getting abortions, nobody should, and I am sad and disappointed that this is happening.

Does this ring a bell?

Replace abortion with Rust, or a spoken language, or ...

Anyone who works in the kernel knows, that somebody dropping an email on the mailing list saying "you should rewrite your kernel in X" is not something that achieves anything.

The OP claims that this somehow happened for Rust. People from the outside managed to somehow "push" us to use Rust in the kernel against our will, they dropped an email and we somehow were fooled by this people and started doing it. The OP is "sad"/"disappointed" that this happened.

If the OP were a kernel developer, (1) it would be accusing itself of getting fooled (yet their comment does not seem to realize this), and (2) it would know that this is not how the Linux kernel community works.

Mostly I/O drivers for network and storage, and let's say "DMA-related" functionality.

Anything more specific than would probably de-anonymize me.

> I personally cannot help but feel like the strong push for rust in the kernel is overstepping some sort of boundary.

As a Linux kernel developer, I feel like non-kernel developers like yourself telling me which language I should use is definetly overstepping a boundary.

I couldn't care less about what non-kernel-developers think about this issue, but "since you mention this": please do mind your own business.

> Why, if C is so bad, wasnt one of the alternatives introduced to slowly replace C in the kernel years ago?

Because we, as in the actual people that spend their whole day developing the Linux kernel *do not want* to write and maintain Linux kernel code written in these languages.

> The only reason there is a push for Rust so much harder than anything else can only be explained by the community and their almost aggressive spirit of "if its not written in Rust, it should be".

This is so wrong. We, Linux kernel developers, are already writing drivers and kernel modules in Rust, *because we want to*. We now want to merge this new code so that other devs and users can use it. Most other devs want this too, so now we added Rust support to the Linux tree.

---

It really is that simple. My code, my body, my rules.

I really don't know what's so hard for people to understand here.

Saying a 10 year old laptop is 2x or 4x slower than a new laptop is just a tiny part of the big picture.

I would say that for a light laptop user, the main reasons to upgrade are:

- displays: make a big difference for watching youtube, reading, etc. You can't really compare a 120 Hz XDR retina display with a 10 year old display.

- webcam: makes a big difference when video conferencing with family, etc.

- battery life: makes a big difference if you are on the go a lot. My 10 year old laptop had new something like 4 hours battery life. Any new laptop has more than 15h, some over 20h.

- fanless: silent laptops that don't overheat are nice, nicer to have on your lap, etc.

- accelerators: some zoom and teams backgrounds use AI a lot, and perform very poorly on old laptops without AI accelerators. Same for webcams.

If you talk about perf, that's obviously workload dependent, but having 4x more cores, that are 2-4x faster each, can make a big difference. I/O, encryption, etc. has improved quite a bit, which can make a difference if you deal with big files.

Still, you can get most of this new stuff for 1000$ in a macbook air with M1. Seems like a no brainer for light users that _need_ or _want_ to upgrade. If you don't want to upgrade, that's ok, but saying that you are only missing 2x better performance is misleading. You are missing a lot more stuff.

> Huge. Only checking array bounds on every access degrades performance considerably.

Citation needed, since all evidence points to the contrary.

Could you please point us to a Rust application (there are hundreds of thousands at this point) that gets noticeably faster when disabling bound checks?

In servo, a whole web browser written in Rust, the cost of doing this was negligible, to the point that it was barely measurable (1-3%, noise levels for such a big app).

Same for Firefox which has a substantial amount of Rust.

Go ahead and give Fuchsia a try. You can enable bound checks for a substantial part of Android's user space and not really notice it.

Same for Redox, or any operating system kernel written in Rust.

You have many large applications to choose from, so please, just point us to 1 for which this is the case.

---

Compared with other mitigations already in the kernel, that can cost you up to 50% perf, and that people seem to be ok with, bound checking all the array accesses seems like a no brainer, given that ~70% of CVE are caused by memory issues.

When most people think about bound checking all array accesses, they think, for some "i can only think inside the box" reason, that this happens on hardware, for every memory access.

But that is not how Rust works. Rust adds bound checks "in Rust", and the Rust compiler and LLVM are really good at removing duplicates, hoisting many bound checks out of a loop into a single bound check at the beginning of the loop, etc.

People also think that this is an all or nothing approach, but Rust allows you to manually access without bound checks and do the hoisting manually. So if you find a function in which this makes a big difference, you can just fix the performance issue there manually.

What nonsense?

Before, children only had to pay for food. If they don't or can't pay, we starve them, that'll teach them.

But now, they also have to pay for this system, and its potential life long consequences.

Like, suppose we offer it to the cheapest contractor, which delivers a crappy insecure system. So somebody "hacks" it and leaks videos of children eating (just because it uploaded all footage to facebook and shared it does not meant we wanted anyone to watch it!).

This allows insurance companies to analyze the data and either charge premiums or just deny health insurance to these children as they become adults because "You had too much sugar as a kid Tommy, here, look, this is footage of you eating 30 years ago!".

So you see, this system is genius and the possibilities are endless. Why can't you get it?

---

In case it isn't clear, this is sarcasm, and I hope that whoever decided that filming children during lunch using facial recognition, and everyone who approved it, to be able to charge children for food, get fired and shamed for life.

Step 0: start driving on the right side of the road

Step 1: adopt the euro

Step 2: improve education for all ages and groups about misinformation, propaganda, etc. to reduce the chances of a bus driving around london from making you change your minds again in 4 years

Step 3: apply to enter as an equal into the EU, instead of trying to cut some half assed deal for half the rights and half the benefits

> You can't even explain how doing something as simple as a binary tree with parent pointer is possible in rust, so my assumption is that it isn't possible

A beginner learns this in the first week:

    struct Node<'a, 'b> {
        left: Option<&'a Node>,
        right: Option<&'b Node>
    }

Many people don't know how to read or write, but you don't hear them every day claiming that "therefore it must be impossible", yet here we are.

> but I don't see why I'd learn a language where I'd be forced to make those work arounds rather than use the version that fits my problem best.

> but it seems everyone is hell bent on just saying "You shouldn't do it!".

The claim was and still is "there are infinitely more effective - as in faster - ways to learn Rust than by starting with how to write doubly-linked lists".

This whole thread is you failing at 3rd grader logic hard and concluding:

- therefore it is impossible to write doubly-linked lists in Rust

- therefore doubly-linked list in Rust are efficient

- therefore it is impossible to learn Rust

- ...and many other things...

I've taught Rust to a 9th year old, but I don't think I could have taught Rust to a 2 year old, so arguably, I think you are right, in that probably _FOR YOU_ it is impossible to learn Rust, you wouldn't be able to grok how to write doubly-linked lists in Rust properly, you wouldn't be able to master Rust to write efficient code in it, etc.

That's ok, don't be frustrated by it, everybody is different.

Just try to stop projecting your limitations to other people. Particularly in this forum, or when talking with Linux kernel developers, were most people are smart experienced programmers that would learn Rust well in a day and master it in a week.

> You're ignoring the case of a list being densely packed and embedded inside another data structure.

No, I am not. This conversation is exclusively about non-intrusive doubly-linked lists.

If you want to have a conversation about intrusive doubly-linked lists we can have it, but it is a very different data-structure.

> You really need to stop assuming what kind of computers other people are programming

Every week I touch x86, arm, ppc64, riscv and gpu assembly.

I write code for apps daily that run from 16-bit micro controllers to the largest super computers in the world, going through phones, desktops, cloud, etc.

I am not assuming what others are programming, but rather talking about what I program for, which include most hardware that anyone can buy today, and quite a bit of hardware that almost no one can even buy, as well as hardware that's not for sale.