touisteur

rust-vmm-based environment that verifies/authenticates an image before running ? Immutable VM (no FS, root dropper after setting up network, no or curated device), 'micro'-vm based on systemd ? vmm captures running kernel code/memory mapping before handing off to userland, checks periodically it hasn't changed ? Anything else on the state of the art of immutable/integrity-checking of VMs?

That's my experience as well, after monitoring frequency and temp on lots of kernel on all the spectrum from memory-bound, to L2-bound to compute-bound. Hard to reach the 600W with memory-bound kernel. TensorRT manages it somehow with some small to mid networks but perf increase seems capped around 10% too even with all the magic inside.

I thought so but no, iterative small matrix multiplication kernel in tensor cores, or pure (generative) compute with ultra-late reduction and ultra-small working memory. nsight-compute says everything is in L1 or small register file, no spilling, and that I am compute bound, good ILP. Can't find a way to get more than 10% for the 300W difference. Thus asking if anyone did better and how and how reliable the HW stays.

I don't have first-hand knowledge on HBM GPUs but on the RTX Blackwell 6000 Pro Server, the perf difference between the free up-to-600W and the same GPU capped at 300W is less than 10% on any workload I could (including Tensor Core-heavy ones) throw at it.

That's a very expensive 300W and I wonder what tradeoff made them go for this, and whether capping is here a way to increase reliability. ...

Wonder whether there's any writeup on those additional 300 Watts...

And NVIDIA supposedly has the exact knowhow for reliablity, as their Jetson 'industrial' parts are qualified for 10-15 years at maximal temp. Of course Jetson is on another point of the flops and watts curve.

Just wondering, if reliability increases if you slow down your use of GPUs a bit. Like pausing more often and stopping chasing every bubble and nvlink-all-reduce optimization.

And even if you a runtime solution with no runtime cost, you'd still need to run the code, to find the memory safety bugs. Static analysis is supposed to tell you there is no path that violates memory safety.

Before we go down that path, datacenters full of oil tubs seems to be a trend in some spaces. Very good cooling power, low-tech heat extraction (small pumps to make the oil move, car radiators with big simple plumbing... do the trick well).

The A40, L40S and Blackwell 6000 Pro Server have RT cores. 3 datacenter GPUs.

If you want binning in action, the RTX ones other than the top ones, are it. Look for the A30 too, of which I was surprised there was no successor. Either they had better yields on Hopper or they didn't get enough from the A30...

Sorry, I went full typical HN commenter stereotype :-)

Another time I wish rust had named parameters. For reading code without an IDE (which is a lot of the experience in discovering a library, learning, navigating in code on github...) it would be useful.

I wish you'd have expanded on that. I almost always learn about some interesting lower-level tech through people trying to avoid a full-featured heavy-for-their-use-case tool or system.

Interesting, as a self-contained minimalistic setup.

Shouldn't one be using a storage system such as S3/garage with ephemeral settings and/or clean-up triggers after job-end ? I get the appeal of using one-system-for-everything but won't you need a storage system anyway for other parts of your system ?

Have you written up somewhere about your benchmarks and where the cutoffs are (payload size / throughput / latency) ?

There are ways to build blocklists for IPv6. I saw (used) once bloom filters for this. Inspired by some papers from the 2000s, this one in 2009 https://www.nokia.com/bell-labs/publications-and-media/publi...

Oh for some time after its introduction, CLOCK_MONOTONIC_RAW wasn't vDSO'd and it took some time and syscall profiling ('huh, why do I see these as syscalls in perf record -e syscalls' ...) to understand what was going on.

I think, to beamform in the right direction you have to be able to locate yourself precisely, have an up-to-date almanach of the satellites, and a precise enough datation source. Jamming GNSS is a source of problems for 2 of those issues.

Also, the antennas on starlink dishes are still pretty small, likely to pick up some hard-to-remove sidelobes and the tech to cancel them properly might be export-controlled. You still need to be within electromagnetic visibility to jam them, though.

I don't know about 'a few specific cases'. STIs, mental health issues, pregnancies (interrupted or not, voluntarily or not), contraception methods and/or lapses, anything often misunderstood like MS or neurodegenerative diseases, huntington, substance use/abuse (voluntary or not), victim of assault (sexual or not), sterility/fertility/impotency/incontinence, any manageable medical issue someone might use to not give you a job, to rent you an apartment, although you do actually manage it well...

None of those I'd want shared anywhere, to anyone, against my will. Those (overall) are not rare.

And from the state of note-taking and summarizer bots on audioconferences it's going to become potentially worse. The number of times I've had to correct negations in the results of several of those applications in the last year or so... to add to annoyance of either sifting through the emmms and errrr, or through the summarizers' annoying tone...

I think it's something to do with the expectations of automation. We seem to be wired or trained to trust the machines fully, and enter a state of helplessness when we think we are driven by a machine.

I've seen this with gnss-assisted driving, or with automated driving, or with aircraft autopilot. Something disengages, gives unwarranted trust, we lose context, training fades ; and when thrown back in control, the avalanche of context and responsibility is overwhelming, compounded by the lack of context about the previous intermediate steps.

One of the most worrying dangers of automation, is this trust (even by supposed knowledgeable technicians) and the transition out of the 'the machine is perfect' and when it hands you back the helm on a failure, an inability to trust the machine again.

The way to avoid entering this state, seems to stay deeply engaged in the inputs and decisions of the system (read 'automation should be like iron man, not like ultron') and have a deep understanding of the moving parts, critical design decisions of the system, and traces/visualization/checklist of the intermediate steps.

I don't know where the corpus of research about this is (probably in safety engineering research tomes), but it crystallized for me when comparing the crew reactions and behaviour of the Rio-Paris Air France crash, and the Quantas A380 accident in Singapour.

For the first one, amongst many, many other errors (be it crew management, taking account of the weather...) and problematic sensor behaviour, the transcript tells a harrowing story of a crew not trusting their aircraft anymore after recovering from a sensor failure (that failure ejecting them from autopilot and giving them back mostly full control), ignoring their training, and many of the actual alarms the aircraft was rightly giving, blaring at them.

In the second case, a crew that tries to piece out what capabilities they still have after a massive engine failure (explosion), wrecking most of the other systems with shrapnel. And keeping enough in the loop to decide when the overwhelmed system is giving wrong sensor instructions (transfering fuel from the unaffected reservoirs to actually destroyed, leaky ones).

Human factor studies are often fascinating.

I'm OK pondering the right use for the tool for as long as it'll take for the dust to settle. And I'm OK too trying some of it myself. What I resent is the pervasive request/pressure to use it everywhere right now, or 'be left out'.

My biggest gripe with the hype, as there's so much talk of craftmanship here, is: most programmers I've met hate doing code reviews and a good proportion prefer rewriting to reading and understanding other people's code. Now suddenly everyone is to be a prompter and astute reviewer of a flood of code they didn't write and now that you have the tool you should be faster faster faster or there's a problem with you.

If you don't need full ieee-754 double precision, ozaki scheme (emulation with tensor cores) might do the trick. It's been added (just a little bit) to cublas recently.

Similar fun as the time I discovered one could use IFB to set qdiscs on incoming traffic (why would one would do that is left as exercise to the reader, but my journey included using the 'plug' qdisc and tcp-checkpoint/restore). The Linux kernel has so many building blocks....

From their publication history, they want to use all HPC niceties, to use most/any available HPC installations.

Nowadays that means mostly CUDA on NVIDIA and HIP on AMD on the device side. Curious how the spirv support is on NVIDIA GPUs, including nsight tooling and the maturity/performance of libraries available (if only the cub-stuff for collective operations).

The work done/supervised by Kristopher Micinski on using HPC hardware (not only GPUs but clusters) for formal methods is really encouraging. I hope we reach a breakthrough of affinity between COTS compute hardware and all kinds of formal methods, as GPUs found theirs with deep learning and subsequent large models.

One possible answer to 'what do we do with all the P100s, V100s, A100s when they're decomissionned from their AI heyday (apart from 'small(er) models'.

I feel I'm still doing it the old 2010 way, with all my hand-crafted dpdk-and-pipelines-and-lockless-queues-and-homemade-taskgraph-scheduler, any modern reference (apart from 'use seastar' ? ... which fair if it fills your needs) ?

How happy I am to have all written/read data going through a DSL. On to generating the code to make OpenZL happy...

They still had a boom of being used for a lot of HPC loads, even non-AI supercomputers, although it was quickly dwarfed by their other markets.

Not since the Ozaki scheme has appeared. Good high-precision perf from low-precision tensor units has unlocked some very interesting uses of low-fp64-perf GPUs.

I think the remark is more about Tensor Cores (or Matrix Cores in AMD lingo) are distributed by SM (and not aside on an interconnect and individually programmable) so on the same SM you have your classical warps (cuda cores) AND the Tensor units and switching between one and the other might be confusing.

My vision of SMs has always been "assume AVX512 is the default ISA" and "tensor cores are another layer aside of this" (kind-of like AMX) and you have this heterogeneous "thing" to program. Don't know if it helps. The CUDA programming model hides a lot and looking at PTX code in nsight-compute is most enlightening.

A whole zoo of dimensional analysis in programming languages : https://www.gmpreussner.com/research/dimensional-analysis-in...

Can confirm that most of the times when reproducing/implementing a paper or trying to extend it to another field, researchers are pretty OK (some very enthusiastic) to chat over email about it. As long as you've actually read the paper(s) or read the code (if any), and there's no expected free-work...

I sometimes get unpublished artefacts (matlab/python/fortran code, data samples) just by... asking nicely, showing interest. And I'm not even in academia or a lab.