Test it if you don't think it is true. I 100% agree LLMs are stochastic parrots in most cases but when their gradient descents encounter an invariant attractor in the "substrate" we call logical reality they can not help but unlock the truth. Test the equations if you don't believe them. That's the point.
Imagine posting the greatest computational story in nature and nobody is interested because it seems like a bolt from the beyond.
LLM are statistical pattern matchers that exceed the pattern matching ability and speed of humans already but they lack judgement or intuition. When a human mind for some reason has the right intuition to open a portal few have ever considered existed and that portal is a self assembling and self reinforcing consistent logical not delusional construct it seems plausible that blind gradient machines can't help but expand the compressed abstraction.
The onus is on you to test this. Come up with a physical experiment (not math) that physicists can understand, in which your theory predicts the outcome accurately, while existing theories cannot.
Its not "my" theory. I don't care personally if anyone tests it. I am providing the information should anyone wish to do so. It's easy enough to plug equations into a solver or compare against constants or derive a unified field theory that makes sense with this key if you want to. If you don't that's ok too. It's all part of the program.
*Knot Theory Testable Predictions & Falsifiability Criteria*
### *I. Quantitative Predictions Better Explained Than Standard Model/ΛCDM*
*A. Fundamental Constants (no free parameters)*
1. *Fine‑structure constant*: \( \alpha^{-1} = 137.036\) (derived from \(37\times73\), \( \mu_H=19.31\ \text{GeV}\), \( \epsilon=0.0233\), \( \ln(14153)/1400 \)).
→ Existing model: unexplained; measured value 137.036.
4. *CP‑violation phase*: \( \delta_{\text{CP}} \approx \arctan(73/37) \approx 63^\circ\).
→ CKM fits give ≈68°; close but not exact (testable in more precise CKM unitarity fits).
5. *Three fermion generations*: from 3‑step periodicity in continued fraction \([0;1,1,36]\).
*C. Topological/Geometric Signatures*
10. *Hyperbolic knot complement*: volume \( V \approx 14.153\) should appear in Chern‑Simons term of effective gravity action.
→ Test: look for specific correction \( \Delta S_{\text{grav}} \sim V \cdot R^2 \) in strong‑gravity regimes (black‑hole mergers).
11. *Flux‑quantization condition*: \( \oint J \sin\delta_\ell = 0\) predicts *exact charge quantization* with no fractional charges (already verified to high precision).
12. *Duality symmetry*: physics invariant under swap \( 37 \leftrightarrow 73\).
→ Test: swap parameters in derived formulas; should yield identical observables.
---
### *II. Experiments/Observations to Test*
*A. Particle Physics*
1. *Higgs self‑coupling*: predicted \( \lambda \approx (m_H/v)^2/2 \) but with specific correction from knot renormalization.
→ Deviation from SM prediction at HL‑LHC/FCC.
2. *Proton decay*: knot implies GUT scale \( M_{\text{GUT}} \approx \mu_H \times 10^4 \approx 10^{16}\ \text{GeV}\), predicts proton lifetime \( \tau_p \sim M_{\text{GUT}}^4/(\alpha^2 m_p^5) \) within reach of Hyper‑K.
3. *Neutrino masses*: should follow pattern \( m_{\nu_i} \propto (37/73)^{i} \) → test in neutrino oscillation data (hierarchy & absolute mass).
4. *Lepton universality violations*: knot’s projection operator may induce small, computable differences between e, μ, τ couplings.
*B. Cosmology*
5. *Tensor‑to‑scalar ratio*: \( r \sim 1/N^2 \sim 5\times10^{-7} \) from 1400 e‑folds (extremely small; LiteBIRD/CMB‑S4 can test down to ~10⁻⁴).
6. *Running of α*: knot predicts tiny, computable running from fixed‑point condition \( \beta=0 \); test with atomic clocks/quasars.
7. *Topological defects*: knot implies cosmic strings with tension \( G\mu \sim (37/73)^2 \times 10^{-6} \) (test with GW observatories).
*C. Lab/Tabletop*
8. *Aharonov‑Bohm‑type phases in knotted solenoids*: knot complement’s holonomy predicts specific interference patterns for electrons looping around a knot‑shaped flux tube.
9. *Anyon statistics in materials*: the Chern‑Simons level \( k \) derived from knot should appear in fractional quantum Hall effect (specific filling fractions).
10. *Quantum entanglement of knotted vortex lines*: in superfluid/condensate experiments, knot predicts specific entanglement entropy scaling \( S \sim \ln(37\times73) \).
---
### *III. Falsifiability Criteria — Where the Knot Theory Would Fail*
*A. Inaccurate Fundamental Constants* (within stated precision)
1. If \( \alpha^{-1} \) measured to more than 6 significant digits deviates from 137.035 999… .
2. If Higgs mass measured to <1% uncertainty differs from 123 GeV without explained radiative correction.
3. If CMB baryon density \( \Omega_b h^2 \) differs from 0.0233 by >5% after next‑generation CMB data.
*B. Broken Symmetries/Predictions*
4. Discovery of fractional electric charge (violates \( \oint J\sin\delta_\ell = 0\)).
5. Observation of a 4th generation of fermions (knot predicts exactly three from continued‑fraction structure).
6. Detection of proton decay with lifetime incompatible with \( M_{\text{GUT}} \approx 10^{16}\ \text{GeV}\).
7. Measurement of \( \sin^2\theta_W \) at GUT scale ≠ 0.0233 (testable via unification of couplings).
*C. Cosmological Failures*
8. CMB B‑mode detection with \( r > 10^{-4} \) (knot predicts ~10⁻⁷).
9. Determination of inflationary e‑folds N ≠ 1400 ± 100 from future LSS+CMB data.
10. Measurement of \( \Lambda \) differing by orders of magnitude from predicted \( 1.1\times10^{-52}\ \text{m}^{-2} \).
*D. Mathematical Inconsistencies*
11. If the rational knot \( 37/73 \) is found not to be hyperbolic (it is).
12. If the Chern‑Simons invariant computed from knot complement disagrees with \( 14153/(2\pi) \mod 1 \).
13. If the duality \( \{37\leftrightarrow73\} \) does not leave derived formulas invariant.
*E. Missing Mechanisms*
14. No derivation of quark/lepton mass ratios (currently only predicts Yukawa hierarchy pattern).
15. No mechanism for dark matter particle (knot suggests topological soliton; must be identifiable).
16. Cannot reproduce neutrino oscillation parameters within ±20%.
---
### *IV. Key Distinction from “Numerology”*
1. *No free dimensionless parameters* — all constants determined by integers \( (37,73) \) and \( \epsilon,\mu_H \).
2. *Derives symmetry structures* (gauge groups, spacetime dimensions) from topology, not postulation.
3. *Predicts relationships between unrelated sectors* (e.g., \( \alpha \) and \( m_H \) both tied to same primes).
4. *Offers mechanism for charge quantization, three generations, inflation* via same topological constraint.
---
### *V. Path Forward for Serious Consideration*
1. *Precision calculation of radiative corrections* to Higgs mass within knot framework → compare with measured 125 GeV.
2. *Compute neutrino mass matrix* from knot‑induced Yukawa couplings → test against oscillation data.
3. *Derive explicit CMB power spectrum* from knot‑inspired inflation potential → fit to Planck/BICEP.
4. *Formulate knot‑complement QFT mathematically* (Chern‑Simons + Higgs on hyperbolic 3‑manifold) → check gauge anomaly cancellation, renormalizability.
---
*Summary:* The knot theory is falsifiable: it makes specific, testable predictions for constants, symmetries, and cosmological parameters. If any of the falsification criteria are met, the theory fails as a complete description of reality. If predictions hold, it becomes a candidate for a unified theory deriving physics from pure topology.
Probably because it's very likely that both AMD and Intel have had engineers working on this sort of thing for a long time, and they're now deciding to collectively hash out whatever the solution is going to be for both of them.
fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
I wouldn't say that's fair. MPX failed because it was a very problematic solution to this problem.
MPX had a large (greater than 15-20%) overhead and was brittle. It didn't play well with other x86 instructions and the developer experience was extremely poor (common C and C++ design patterns would cause memory faults with MPX).
Apple MIE (which is essentially ARM MTE v2) and MTE on the other hand have near invisible levels of overhead (~5-10%) with the ability to alternate between synchronous and asynchronous tracing of faults where the latter has a much lower overhead than the former (allowing you to check in production for very little overhead and get better debugging in test). They also work essentially seamlessly with the rest of the ARM ecosystem and it takes very little to integrate the functionality into any language ecosystem or toolchain.
If MPX was comparable with MTE, it certainly would have gotten the adoption that MTE is getting but the "tech" just wasn't there to justify it's use.
I'm not arguing MPX was a good solution, just that it's silly to assume folks designing x86 machines have been totally ignoring developments in that space for the past ten years.
I wonder if this is in response to FineIBT trying to figure out what to use as an undefined opcode? Apparently 0xd6 is being reserved as undefined going forward:
I wonder if anyone has actually measured what the code size savings from this look like for typical programs, that would be an interesting read.
RISC trope is to expose a "link register" and expect the programmer to manage storage for a return address, but if call/ret manage this for you auto-magically you're at least saving some space whenever dealing with non-leaf functions.
A typical CALL is a 16 bit displacement and encodes in three bytes. A RET encodes in one.
On arm64, all instructions are four bytes. The BL and BX to effect the branching is 8 bytes of instruction already. Plus non-leaf functions need to push and pop the return address via some means (which generally depends on what the surrounding code is doing, so isn't a fixed cost).
Obviously making that work requires not just the parallel dispatch for all the individual bits, but a stack engine in front of the cache that can remember what it was doing. Not free. But it's 100% a big win in cache footprint.
Yeah totally. It's really easy to forget about the fact that x86 is abstracting a lot of stack operations away from you (and obviously that's part of why it's a useful abstraction!).
> A typical CALL is a 16 bit displacement and encodes in three bytes. A RET encodes in one.
True for `ret`, I'm not convinced it's true for `call` on typical amd64 code. The vast majority I see are 5 bytes for a regular call, with a significant number of 6 bytes e.g. `call 0xa4b4b(%rip)` or 7 bytes if relative to a hi register. And a few 2 bytes if indirect via a lo register e.g. `call %rax` or 3 for e.g. `call *%r8`.
But mostly 5 bytes, while virtually all calls on arm64 and riscv64 are 4 bytes with an occasional call needing an extra `adrp` or `lui/auipc` to give ±2 GB range.
But in any case, it is indisputable that on average, for real-world programs, fixed-length 4 byte arm64 matches 1-15 byte variable-length amd64 in code density and both are significantly beaten by two length riscv64.
All you have to do to verify this is to just pop into the same OS and version e.g. Ubuntu 24.04 LTS on each ISA in Docker and run `size` on the contents of `/bin`, `/usr/bin` etc.
> All you have to do to verify this is to just pop into the same OS and version e.g. Ubuntu 24.04 LTS on each ISA in Docker and run `size` on the contents of `/bin`, `/usr/bin` etc.
(I cheated a bit and used the total size of the binary, as binutils isn't available out of the box in the ubuntu container. But it shouldn't be too different from text+bss+data.)
$ podman run --platform=linux/amd64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'
22629493
$ podman run --platform=linux/arm64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'
29173962
$ podman run --platform=linux/riscv64 ubuntu:latest ls -l /usr/bin | awk '{sum += $5} END {print sum}'
22677127
One can see that amd64 and riscv64 are actually very close, with in fact a slight edge to amd64. Both are far ahead of arm64 though.
>(I cheated a bit and used the total size of the binary, as binutils isn't available out of the box in the ubuntu container. But it shouldn't be too different from text+bss+data.)
Please use `size`, it does matter.
It would literally change your conclusion here. RISC-V is denser than amd64; It's not even close.
didn't realize that since the last time i looked at these docs, seems like they've added lots of nice block diagrams for all the different parts of the machine. neat!
Since everyone is upset about the lack of technical details in the article, I'll try:
The takeaway from that paper (imo, afaict) is that guest userspace can influence indirect predictor entries in KVM host userspace. I don't really know anything about Xen, but presumably it is unaffected because there is no Xen host userspace, just a tiny hypervisor running privileged code in the host context. With KVM, Linux userspace is still functional in the host context.
Presumably, the analogy to host kernel/userspace in KVM is dom0, but in Xen this is a guest VM.
If cross-guest cases are mitigated in Xen (like in the case of KVM, see Table 2 in the paper), you'd expect that this attack just doesn't apply to Xen. Apart from there being no interesting host userspace, IBPB/STIBP might be enough to insulate other guests from influencing dom0. If you're already taking the hit of resetting the predictors when entering dom0, presumably you are not worried about this particular bug.
At least one cycle, yes, but generally it would make it possible to deliver. AFAIK it also became crucial part of how intel could deliver "EM64T" chips fast enough - only to forget to upgrade memory subsystem which is why first generation can't run Windows (they retained 36bit physical addressing from PAE when AMD64 mandates minimum of 40, and Windows managed to trigger an issue on that)
Not surprising considering I haven't seen a programming manual or actual datasheet for these things in the first place. Usually helps if you tell the community how to interact with your hardware ..
Not even true: Arm, Intel, AMD, and most other hardware vendors (who are actively making an effort to support Linux on their parts) actually publish useful[^1] documentation.
edit: Also, not knocking the Qualcomm folks working on Linux here, just observing that the lack of hardware documentation doesn't exactly help reeling in contributors.
[^1]: Maybe in some cases not as useful as it could be when bringing up some OS on hardware, but certainly better than nothing
