maxwell86

Accessing InfiniBand and GPUs directly become a problem.

I use nvidia containers on HPC systems every day and accessing NICs, doing RDMA to GPUs, etc. "just works" and performs as well as baremetal. Every time we upgrade our container we verify the new container with a set of benchmarks against both the old one and baremetal.

You don’t want to give indirect root access via docker group, too.

I don't know of any HPC center using docker though. It does not sound like a good idea because the docker daemon runs as root..

Yes. They should not have included any adapter at all.

Those with older PSUs should have had to make a decision about whether they want an adapter or not, and then pick an adapter of the appropiate quality.

TBH NVIDIA should just have not included any adapter at all.

Agreed, not sure what other words to use instead.

I think it would have been better for these cards to not have an adapter at all. I've added an EDIT to try to word this differently.

Thanks. I've added an EDIT to clarify that I am not speculating about whether the OP read the article, and that the only point of my comment is to set the record straight for those who often just come to HN for the comments (like myself).

Other commenters are claiming that NVIDIA KNEW the adapter h

Those refer to a PCI Express Forum issue that was opened about the connector drawing too much power, not the adapter.

xactly for how they implemented and supply a 12V solution (which includes both the physical products they supply, and the messaging they've put out around it) which this article yet again underlines as being both real, and even worse than initially thought.

I'd recommend people gloating to read the article. EDIT: (see my edit below).

The conclussions are clear:

- The problem is NOT the new connection; that's fine. New PSUs come with a connection that does not need any adaptor and those are safe and work fine.

- The problem is a poor quality adaptor shipped with 4090s for people that buy a 1600$ GFX but then skimp on a new PSU and want to pair it with an old one (EDIT: skimp is out of place and victim blaming, I'd guess it would be more appropiate to have said here that NVIDIA and partners decided to add an adapter to avoid suggesting that users need a new PSU).

These adaptors are distributed by NVIDIA but build by a supplier. Igor's recommendation is, I quote: "NVIDIA has to take its own supplier to task here, and replacing the adapters in circulation would actually be the least they could do.".

EDIT: This comment can be misunderstood as me speculating whether the OP read the article or not. I am not speculating: the OP did not read the article, which claims the opposite of what the OP claims. The OP claims that 12V solutions are the issue, while the article states that they are fine, and as proof shows that new PSUs implement them correctly. In fact the _goal_ of the article is to set the record straight about this, by precising that the only problem is the quality of the adapter, not 12 V per se. So this comment is not an speculation about whether the OP read the article or not, but a response to set the record straight for those who might read OPs comment only, but not the article (I often come to HN for the comments more than the articles, so I'd find such a comment helpful myself).

That's the opposite of all other traffic rules in the UK.

Cars stop on the left, which allow other cars to overtake them on the right.

Stand on the right of escalators

This surprised me when visiting the UK.

I actually expected people to stand on the "left" of the scalators - just like how they drive on the left and overtake on the right - but they didn't. They stood on the right.

I was left puzzled ???

How likely is it that any given node would be mapping out more than 2^64 bytes worth of virtual pages?

In the Grace Hopper whitepaper, NVIDIA says that they connect multiple nodes with a fabric that allows them to creat a virtual address space across all of them.

Do you have some scientific references on synchronous concurrency?

The Rust module system is radically different from C and C++ and other similar languages in the embedded space.

Every build system that has added support for Rust, which aren't many, had to be radically modified to achieve that.

None of these supports the GCC Rust frontend, but all of them support the Rust frontend.

So if you actually wanted to build any >100 LOC Rust project for embedded targets not supported by LLVM, doing it with the Rust frontend is as easy as just running 1 CLI command to pick its GCC backend.

Doing it with the GCC frontend, would require you to either port one of the build systems to support it, or... give the GCC frontend a CLI API that's 100% compatible with the Rust frontend.

Rust already has a GCC backend that can do all that.

This post is about a new front-end.

The rust compiler can already use GCC as a backend. So I don't see how this opens more platforms than that.

If you only write to the lower 32-bit of the v0 register, which could be 1024 bit wide, that claims that the hardware somehow has to allocate a 1024-bit wide register to back those up, and then makes some "locality" arguments.

The hardware can back up the 1024-bit register with a pool of 32-bit registers, and if you only wrote to the first 32-bits, and all others are zero, it can use a single 32-bit register to back it up, making this "as good" as the single mask register solution, which the author thinks is good.

This is not really a problem.

While it is true that you can only use masks from v0, and this requires moving masks into v0 after calling a vector instruction, those moves don't actually copy data from one register to another. Instead, they just "rename" registers.

So...

    ...generate mask into v2... v2, ....  <- put mask here
    
    mov v0, v2  <- move mask into v0
    vadd ... <- vector instruction, always use v0

Instead, the mov v0, v2 just disappears due to a register rename (e.g. v2 gets renamed as v0 for vadd), and vadd picks the mask directly from the register that was previously called v2 but is now called v0.

Any CPU would implement register renaming before actually even thinking of adding vector registers. So it is fair to assume that every CPU that implemenst the RISC-V V extension, supports it.

The elevation of the room where the rack is installed must be below 9,842 feet (3,000 meters).

Why?

even if you have a PhD many will see you as "less than."

Inside academia and outside of it.

Inside academia you are not on a tenure track or similar, and will have to put up with a lot.

Outside academia, your peers will be making 3x or more than you, working less hours, with less stress, etc.

The reason RSE's jobs are hard to fill and often aren't even opened is that they don't make sense. If you are good enough for an RSE job, you will be good enough for research postions at FAANG. Those pay 10x more, so you also need someone willing to not accept that 10x pay, and also willing to work double the hours.

RSEs making a reasonable pay for the skills they require make no sense either, because that would put your pay at 2x that of professors, etc.

A person that works at Intel.

Four times the price of fully unlimited 4G for a much better connection with more availability than 4G seems fair to me.

If you don't need starlink, then don't get it.

But if you have a cabin in the Italian alps where its either Starlink or else, then 124 / month seems like a much better deal than having no internet at all. Particularly if with those 124 / month then one or more people can live there and work earning multiple thousand euros per month of income (vs zero income living there without Starlink).

I severely doubt that std::for_each_n exists on GPU code.

https://docs.nvidia.com/hpc-sdk/compilers/c++-parallel-algor...

This is 4 years old. Been using it in production for the last 2 years. Works fine.

Pretty much everyone I've talked to using this in production from other research groups was able to remove all their CUDA code and replace it with this without any performance hit.

There are some recent publications about this, but most of them are quite old right now cause this is not new anymore: https://arxiv.org/abs/2010.11751

It's ok to like OpenMP.

What I disagree with is that it should be suggested to beginners as the way to parallelize their C++ programs.

That's like telling a Javascript programmer that they should parallelize their programs by using Python or C.

Show them how to do it in Javascript, or in this case, in C++, so that they don't have to learn a whole new programming model or language to just write parallel code.

Particularly when C++ has supported this for so long now.

The "target" now makes the for-loop discussed a GPU or FPGA algorithm. Now what's strange about this is... you seemed to have known this already? So I've had difficulty making an actual response to you.

The target does not suffice, you need to make sure the memory is manually moved to the GPU or the FPGA, so you need to handle that as well.

BTW: I don't think that C++ platforms like NVidia nvcc or AMD's ROCm support for_each_n. And even if they did, that's not how you really write GPU-parallelism programs.

They do, and performance is pretty much the same as native GPU code in my experience, and according to all peer-reviewed publications about it.

It's normal C++

C++ is an ISO standard, you can use it _everywhere_, in space, in automotive, in aviation, in trains, in medical devices, _everywhere_.

OpenMP is not C++, it is a different programming language than C++.

OpenMP is not an ISO standard, you can't use it in _most_ domains that you can use C++.

Your example:

    #pragma openmp parallel for
    for(int i=0; i<1000000; i++)
        C[i] = A[i] + B[i];

It does not run in parallel on GPUs or on FPGAS (lacking target offload directives), and you can't use it on most domains in which you can use C++.

The following is ISO standard C++:

    std::for_each_n(std::execution::par, std::ranges::iota(0).begin(), 1000000, [](int i) {
        C[i] = A[i] + B[i];
    });

Show me how to sort an array in parallel on _ANY_ hardware (CPUs, GPUs, FPGAs) with OpenMP. With C++ is as simple as:

    std::sort(std::execution::par, array.begin(), array.end());

There is no need to turn your ISO C++ compliant program or libraries into OpenMP. That prevents them from being used by many domains on which C++ runs on. It also adds an external dependency for parallelism, for no good reason.

For any problem that OpenMP can solve, OpenMP is _always_ a worse solution than just using strictly ISO standard and compliant C++.

OpenMP has completely lost a reason to exist. It's not 1990 anymore.

lol please no

If you are using C++, and want to parallelize something, just add "std::execution::par" to your algorithms.

Instead of writing "std::for_each(...)" just write "std::for_each(std::execution::par, ...)".

That's it. It really is that simple. And with the right compilers you can just compile the code to run on FPGAS, GPUs, or whatever.

For someone that knows C++, doing that is the lowest barrier of entry, and gets you most of the way there without having to learn "some other programming language" like OpenMP (or anything else).

So consumption increases about x1.5 from the "best case" to "autobahn speeds"?

Yes, pretty much. I wouldn't say 1.5x is a constant factor.

If I drive at 200+kph (e.g. 240kph) then consumption explodes.

This stuff must be online somewhere, but for me at least it seems that consumption increases exponentially (e.g. x^2), which makes sense since air resistance increases with v^2.

I agree that in general most want to integrate new languages with their existing code bases (rust-bindgen automatically generates C bindings, ABI tests, etc. using libclang to access C and C++ from Rust, and for each language there are tools to generate bindings and ABI tests for Rust code, e.g., the cpp crate generates C++ wrappers around Rust libraries).

The consultancy company developing c2rust specifically helps clients translate their apps to Rust. IIUC these clients want to move from C to a memory and thread safe language without loosing performance.

c2rust is the first step in that process. It mechanically translates C into "C-looking unsafe Rust".

The engineers then go and start migrating from unsafe Rust to safe Rust incrementally.

This is a long process, c2rust speeds up a small fraction of it, but most of the engineers time is spent into translating unsafe Rust into safe Rust, and then refactoring safe Rust into idiomatic Rust.

I do it every day via fzf on the terminal.

That's arguably much better than this because it has full fuzzy searching functionality.

When you are talking about super chargers, are you extrapolating to the whole planet earth? Or have you actually driven your Tesla across all 5 continents ?

You can’t drive in a German motorway at 110kph. You’d be in the truck lane at 80kph for your whole trip, having to over take every single truck, of which there are many. So 130kph+ is the minimum unless you are towing.