tntn

> Science needs models based on mechanistic understanding of the underlying phenomena. A model that merely predicts is useful for engineers, not scientists

I'm not sure I agree. I'm aware of quite a bit of supercomputing time that is spent doing lattice QCD calculations (which apparently some scientists find useful), and though I'm no quantum physicist I'm pretty sure there is not much of a "mechanistic understanding" in QCD. I think your claim also doesn't apply to a lot of social science - psychology has a lot of functional models, but I don't think there are many mechanisms described.

I'll also state that modern science that doesn't require any engineering is pretty rare nowadays, so if a predictive model helps engineers that can then help scientists, the model has been helpful to scientists.

Ohm's law existed long before there was a mechanistic description behind it, and though it is mostly used for "engineering," I feel confident that a lot of scientists in the 19th century found it useful.

From https://www.olcf.ornl.gov/leadership-science/physics/:

"New Frontiers for Material Modeling via Machine Learning Techniques" - 40,000 hours allocated on Summit

"Large scale deep neural network optimization for neutrino physics" - 58,000,000 hours allocated on Summit.

Supercomputers typically do not allocate 58 million hours to things which are not useful.

> generic programmers

I would argue that most would agree that a "generic programmer" does not have a degree in math or a minor in bioengineering. There are a lot of programmers who never studied any STEM outside of a CS curriculum, which usually has ~no science and rarely requires advanced math (i.e. requires only linear algebra).

Modern GPUs are in a very real sense the spiritual successors of the Connection Machine. So in some sense the "sort of analogue" has already arrived.

BOOM uses the rocketchip ALU, which uses the Chisel `+`, which probably compiles down to the verilog `+`, which probably gets synthesized to the appropriate width adder in the standard cell library of the vendor (e.g. TSMC or Xilinx). So for synthesized microarchitectures, it isn't determined in the RTL.

> actually getting something physically superior

Sometimes, sometimes not. What you are getting is a chip that passed more rigorous tests. That the lower end products have (or would have) failed those tests is not guaranteed. Companies can and do sell identical silicon as less capable products.

What do you find deeply unethical about it? I don't care how it's implemented - if it works as advertised and I decide to buy it for a given cost, seems like an ok deal. Said printer would not be good, I would not buy it.

EDIT: FWIW, there is a metric ton of software and firmware that is crucial to achieve the advertised range. So if it makes you feel better you can think of it as not the mechanical product operating differently, just the software product.

It's comparable to an old school analog computer (like the ones used long ago to simulate differential equations) using optics instead of analog electronics. They build a physical analogue of a neural network that evaluates the desired function.

There are not yet any good (cheap, reliable, composable) optical transistors.

Note that wikichip redirects 12nm to 14nm. TSMC calls their 14nm node 16/12nm. All the 12,14,16 nm nodes from the various fabs are nearly the same.

GPU L1 caches are typically not coherent, so flushing them is necessary on GPU architectures.

As a minor note, LDAR and STLR are poorly named and are documented as providing multicopy atomicity in addition to acquire-release semantics and are the recommended way to implement C11 SeqCst.

Some of the below is almost certainly incorrect, apologies in advance.

Your example is more or less the Independent Read Independent Write (IRIW+syncs) litmus test. The short version is you don't need to flush any caches to get IRIW to always obey sequential consistency.

Originally, ARMv8 was non-multicopy atomic, but AFAIK there was never any non-multicopy atomic implementation, and a revised spec requires multicopy atomicity. This matters in terms of thinking about how sequential consistency for IRIW is implemented, but it works either way.

The core idea is that the DMB ISH ensures that the value that the first reads in threads c and d receive are visible to all threads. With multicopy atomicity this is free - e.g. if Thread C reads true from X, then all other threads will also read true.

(-> below indicates a sequenced before relationship)

So you get

Thread C: read X as true -> dmb ish -> read Y as false

Thread D: read Y as true -> dmb ish -> read X as false

However, you get some extra edges. If either thread reads X as false, then X as true is not visible to any thread. So you get

(Thread C reads y as false) -> (Thread D reads Y as true)

(Thread D reads x as false) -> (thread c reads x as true)

These are enough to produce a cycle that forbids the z=0 case.

Essentially, threads A and B have to make sure that once any thread sees its write, all threads see its write. (Or alternatively the dmb ish on thread C and D have to ensure that future memory accesses from that thread don't proceed until the prior read is consistent to all cores).

> That means the L1 (and probably L2) caches are flushed every time you read or write to them on ARM systems. (x86 has stricter guarantees and almost "natively" implements SeqCst, so you won't have as many flushes on x86). The cache must be flushed on EVERY operation declared SeqCst. Its absurdly slow, the absolute slowest memory model you can have.

SeqCst is definitely the slowest memory model to use, but the bit about flushing caches doesn't sound right. SeqCst on a processor with a relaxed memory consistency model usually 'just' requires core-local operations on the load/store buffers - usually draining the buffers (but that is not strictly necessary). It isn't necessary to flush caches to enforce consistency if the memory system has coherent caches.

Fences for sequential consistency are certainly heavy on ARM and it will show up as poor performance, I'd be very surprised if any aarch64 processor flushed any cache on LDAR/STLR.

I'd appreciate a correction if I've misunderstood or if there are modern ARM processors that do flush L1 on LDAR/STLR/DMB ISH.

Hm, yeah, that seems fair.

I guess I was thinking of the periodic timer reset as part of the watchdog mechanism. Maybe another difference is whether the interaction with the timer is manual.

A watchdog timer is so named because it watches for some undesirable condition (usually a hang) and takes action if the condition lasts too long. This sort of auto-rollback is not that because it doesn't detect if something is bad, just rolls it back unless you tell it not to.

Why didn't the IAU petition the FCC during the comment period for SpaceX's application? Seems sorta weird to wait for the first launch to express concerns when the application was submitted to the FCC many months ago (and I think I recall an earlier version years ago).

(Or if they did, could someone provide the link? I'm not able to find it.)

Certainly increased acceptance rates for domestic students would impact which schools they go to. But do you have any data indicating that a) there are a significant number of domestic students who apply to STEM programs and get rejected from all of them and relatedly b) the demand for grad school positions is sufficiently elastic to match an 80% increase in supply?

I'm not sure what your point was with the casual dismissal of 70 years of research in every field besides lithography. Am I supposed to think that international students only work on lithography? Most lithography research, as far as I'm aware, doesn't even happen in academia.

60-80% of graduate students in STEM fields in the U.S. are international students. It seems like having 60-80% fewer graduates would accelerate the decline of American science.

There goes 3 nines for June and for Q2. I guess everyone gets a 10% discount for the month? https://cloud.google.com/compute/sla

Lol, talk about a straw man with the awful opencl-source-in-c-array.

EDIT: props to the author for working on a language, but using that as an example of "confusing syntax" is comical.

Right, the behavior for "out of bounds" addressing is frequently (ab)used. Tagged pointers have been used in loads of stuff. I think x86_64 prohibits this and the MMU will fault if there are interesting things in the high bits, but it still works on aarch64 systems.

There's no better way to get a recession than to have everyone acting like there is going to be a recession. Yield inversion indicates the market is starting to think there is going to be one.

> I don't think they are hired via red black trees

No, they were hired long ago via red-black trees and got promoted for building google plus.

They aren't "charged with" anything. Some elementary particles happen to interact with one another in a particular and consistent way, and we label them according to how they behave with something we call charge.

Electric charge is fundamental.

> doesn't even apply to chips that don't do speculation in hardware

This is an interesting way to put it. I would have said "applies to pretty much every CPU manufactured in the last decades." Your statement would make sense if speculation in hardware was some niche thing, but I think you would be hard-pressed to find an invulnerable CPU that is used in situations where people care about both performance and security.

That's great for the mill, but isn't relevant to the world outside of mill computing.

> new chips will address [these vulnerabilities]

It doesn't seem likely. The chipmakers will fix the vulnerabilities that break isolation between processes and between user-kernel, but the within-process issues will probably stick around.

But most of the examples in 'fulafel's comment already don't require recompiling for a new architecture. Node, ruby, Python, JVM languages... You just need a runtime for the desired architecture, which is still true for WASM.

(As a sidenote, POWER has supported either endianness for a while, and ~everyone runs Linux in little-endian mode.)

Given that the point of cgo more or less is to enable calling into C code, don't you still need to do a lot to make that work in WASM? Like cross-compile all your C dependencies to WASM, then use cgo to interface between the go things and the c things within the WASM runtime?

Pretty interesting ideas and I'm interested to see how it plays out, but tbh I think I'm too old school for all this newfangled stuff and would just use qemu.

To which the V8 developers say:

> We might consider adjusting the precision of timers or removing them altogether as an attempt cripple the program’s ability to read timing side-channels.

> Unfortunately we now know that this mitigation is not comprehensive. Previous research [30] has shown three problems with timer mitigations: (1) certain techniques to reduce timer resolution are vulnerable to resolution recovery, (2) timers are more pervasive than previously thought and (3) a high resolution timer can be constructed from concurrent shared memory. The Amplification Lemma from Section 2.4 is the final nail in this coffin, as it shows (4) gadgets themselves can be amplified to increase the timing differences to arbitrary levels.

I think moore's law has spoiled a generation on what technology can do. It is extremely ridiculous that lithography has gotten so much better in the last few decades, and IMO it has resulted in a lot of people thinking that exponentials are a) common, and b) automatic. Neither of these are true.

There are few, if any, other exponentials in the history of humanity that worked as consistently for as long with as massive of impacts on technology, and TBH I'm doubtful that we will see anything like it again.

Moore's law worked because loads of engineers and scientists made it their life's work, but everyone watching seems to think it just happened.

There was one magical exponential that changed the world, and it's coming to an end.

There's certainly a lot that can be done in architecture and software, but most applications probably aren't worth the effort.

Fin width is around the same size as the node name, but yeah gate length at 7nm is nowhere near 7nm.

How does this do anything to alleviate spectre and friends? Software isolation doesn't work (https://arxiv.org/abs/1902.05178), so the only protection you get is from process isolation, and I assume this doesn't change the OS mechanisms to enforce that.