maxwell86
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..
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.
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.
Those refer to a PCI Express Forum issue that was opened about the connector drawing too much power, not the adapter.
I'd recommend people gloating to read the article.
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 skim on a new PSU and want to pair it with an old one.
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.".
Cars stop on the left, which allow other cars to overtake them on the right.
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 ???
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.
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.
This post is about a new front-end.
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.
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.
Why?
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.
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).
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
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 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.
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.
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).
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.
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.
That's arguably much better than this because it has full fuzzy searching functionality.