maxwell86's comments

> 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

doesn't really put some bits into v2, then copy them to v0, and then call the vector instruction.

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).