yvdriess

Agree, those hangs are especially bad when programming with eglot or project management over a slow Tramp (remote) connection. An auto save hijacking your time for two seconds at random is flow breakingly frustrating. It's something that could perfectly well run in the background.

This is the kind of nerd food I keep hoping to find on HN comments. Thanks!

And now adding to that schip is also the main part of a church building, we can worship in the kerkschip's schip on a schip while it's being shipped.

Yep, it's awesome how Michael keeps crediting collaborators, given how much of the work is his. Good job!

Well yes, the dialects are very distinct linguistically, but what is often referred to as Flemish is the Dutch "tussentaal" aka "verkavelingsvlaams"[1]. That's not really a language per se, it's a regiolect of the official Dutch language, itself a Dutch variant of the Brabant dialects. The Flemish Dutch is usually used a lingua franca because the official Dutch otherwise sounds too formal (and native dialect speakers are foreign language speakers of Dutch). If I was to nominate a regional language for recognition it would more be the regional dialects like Brugs, Gents, Antwerps, Brussels Vloms, Hasselts, etc.

What I find interesting is that the differences in Flemish dialects make them much more distinct than what would normally call dialects. There are significant grammatical difference beyond the usual vocabulary differences. For instance, coastal Flemish conjugates yes and no[1], Limburgisch is a tonal language.

[1] https://nl.wikipedia.org/wiki/Tussentaal

Flemish is more of a political construct than linguistic, it's a grouping of belgian-dutch the coastal, brabant and limburg language groups with each having their own regional dialects.

If ARM's memory tagging is a guide, not much for the general developer. You will be able to run with address sanitizers enabled at a much lower overhead. Perhaps, use some hardened allocators or library variants that rely on the extension.

He was talking about china because that's the subject in this story, not the poster's residence.

My interpretation, going off on the linked integrated GC research: extensions to the ISA and thus compiler backend, no modifications to 'well formed' applications, some changes to the language runtime dealing with memory management.

Unless the CPU hardware becomes some kind of hybrid monster with both OMA and traditional paged MMU, you will need to make changes to the kernel. You may be able to emulate some of the kernel's page table shenanigans with the object-based system, but I don't think that the kernel's C code is typically 'well-formed'. It's probably a lot of engineering effort to make the necessary kernel changes, but so are all those complex kernel hardening efforts that hardware-level memory security like OMA would render moot.

Yep air-gapped security is a thing. But servicing, patching and communicating with air-gapped devices still needs to happen, which involves connecting to them somehow. Likely a manufacturing plant has started to connect everything together to streamline the process and created an attack surface that way.

You can see the appeal for not needing to go through all the issues, complexity and costs that entails.

Related discussions:

- CHERI with a Linux on Top https://news.ycombinator.com/item?id=45487629

- Why not object capability languages? https://news.ycombinator.com/item?id=43956095

- Ask HN: Why isn't capability-based security more common? https://news.ycombinator.com/item?id=45261574

Hands up, the dozens of us pedants that have used a relaxed atomic add in situations like these. Updating the SP in the most paranoid way possible is the reason that sort of thing exists.

(You cannot express relaxed atomics in golang, but you could technically add support in the compiler for use in the runtime code)

Go users can only insert assembly wrapped in a function call. That might be safety related, I am not entirely sure.

(Well technically there is a way to inject assembly without the function call overhead. That's what https://pkg.go.dev/runtime/internal/atomic is doing. But you will need to modify the runtime and compiler toolchain for it.)

Language safety helps get you 80% of the way there, but you are still working from software on top of fundametally unsafe hardware. Companies and agencies are and, increasingly, will pour money into hardware that give certain safety and security guarantees.

Totally agree. I have experienced 'ideal' circumstances of 33% taken/untaken branches where you will be hard pressed to make cmov perform better on real life workloads. Pass along other data inputs that do predict better and your cmov becomes a liability.

It's pretty hard to make modern compilers reliably emit cmovs in my experience. I had to resort to inline asm.

I wouldn't say they contain any model of the world. They're a statistical predictive model, which have proven effective at certain tasks. My take is that the demoware part is not inherent to the NN approach, but rather that the tasks it's unreasonably effective produce very cool demo-able tasks for which the audience readily fills in the blanks. Cool demos make it easier to get further resources, so demoware-prone techniques tend to pull more funding, at least for a while.

Required background music for reading the article: https://www.youtube.com/watch?v=Azsk21MpbUk

And tilera in their DPUs

If anything that would be a boost to Intel. One of their problems is GPU capex sucking the air out of the room.

Something that could help is to use llvm-mca or similar to get an idea of the potential speedup.

One of the key innovations behind the DNN/CNN models was Mechanical Turk. OpenAI used a similar system extensively to improve the early GPT models. I would not be surprised that the practice continues today; NN models needs a lot of quality ground truth training data.

It would be a waste to use this to just make DIMMs. It's only transistors, like SRAM cells, so you can efficiently fab them on the same process technology and the same dies as your logic.

Then again, there is wear, so either you accept a level of performance degeneration (dynamic capacity cache?) or you go to DIMMs anyway servicability.

AFAIK the dark silicon term is specifically those transistors not always powered on. Doping the Si substrate to turn it into transistors is not going to change the heat profile, so I don't think dummy transistors are added on purpose for heat management. Happy to be proven wrong though.

There's tricks to improve the performance of pointer chasing on modern uarchs (cfr go's Greentea GC). You want to batch the address calculation/loading, deref/load and subsequent dependent ops like marking. Reorder buffers and load-store buffers are pretty big these days, so anything that breaks the addr->load->do dependency chain is a huge win, especially if there are any near that traverse loop.

That's most of the work performed by a marking GC.

How much a GC is of total cpu cost totally depends on the application, the GC implementation and the language. It's famously hard to measure what the memory management overhead is, GC in production is anywhere between 7-82% (Cai ISPASS2022). I measured about 19% geomean overhead in accurate simulation by ignoring instructions involved in GC/MM in python's pyperf benchmarks.

The cost of a string array is paid on every GC phase. That array may/contains references so the gc has to check each element every time to check if anything changed. An int array cannot contain references so it can be skipped.

edit: There are tricks to not traverse a compound object every time, but assume that at least one of the 80M objects in that giant array gets modified in between GC activations.

A good opportunity to point people to the paper with my favorite title of all time:

"How to wreck a nice beach you sing calm incense"

https://dl.acm.org/doi/10.1145/1040830.1040898

> With 44GB of SRAM per Cerebras chip, you'd need 45 chips chained together. $3m per chip. $135m total to run this.

That on-chip SRAM memory is purely temporary working memory and does need to hold the entire model weights. The Cerebras chip works on a sparse weights representation, streams non-zero off their external memory server and the cores work in a transport-triggered dataflow manner.

Branch predictors have gotten really good and it often now makes more sense to rely on it rather than working away the branches.

For example, modern compilers will very rarely introduce conditional moves (cmov) x86 because they are nearly always slower than simply branching. It might be counter intuitive, but a branch prediction breaks the dependencies of the micro-ops between the conditional and the clause. So if your cmov's conditional depends on a load, you need to wait for that load complete before it can execute.

Always benchmark with at-scale data and measure.