1) This year, Intel, TSMC, and Samsung announced their latest factories' yields. Intel was the earliest, with 18A, while Samsung was the most recent. TSMC yieled above 60%, Intel below 60%, and Samsung around 50% (but Samsung's tech is basically a generation ahead and technically more precise), and Samsung could improve their yields the most due to the way set up the processes, where 70% is the target. Until last year, Samsung was in the second place, and with the idea that Intel caught up so fast and taking Samsung's position at least for this year, Nvidia bought Intel's stock since it's been getting cheaper since COVID.

2) It's just generally good to diversify into your competitors. Every company does this, especially when the price is cheap.

I was recently looking into 2nm myself, and based on wikipedia article on 2nm, TSMC 2nm is about 50% more dense than the samsung and intel equivalent. They aren’t remotely the same thing. Samsung 2nm and Intel 18A are about as dense as TSMC 3nm, that’s been in production for years.

Since "nm" is meaningless these days, the transistor count/mm2 is below.

As reference: TSMC 3nm is ~290 million transistors/mm2 (MTr/mm2).

             IBM      TSMC   Intel   Samsung
  22nm                       16.50  
  16nm/14nm          28.88   44.67   33.32
  10nm               52.51  100.76   51.82
  7nm                91.20  237.18   95.08
  5nm               171.30    
  3nm               292.21    
  2nm        333.33

https://www.techradar.com/news/ibm-unveils-worlds-first-2nm-...

According to Wikipedia intel 7nm density is ~62 MTr/mm2. I cannot find the source wikichip page mentioned in your reference post.

FWIW, I am not in the semi industry and all my info are from Wikipedia https://en.m.wikipedia.org/wiki/7_nm_process https://en.m.wikipedia.org/wiki/2_nm_process

I did the math on TSMC N2 vs Intel 18A, and the former is 30% denser according to TSMC

This definitely isn't a thing that every company does (or even close to every company).

Microsoft once owned a decent amount of Apple & Facebook for example.

Are you comparing Samsung against Intel here specifically, or also TSMC?

Looking good!

yep, still looks relatively good.

    cargo tree llm v0.1.0 (RustGPT)
    ├── ndarray v0.16.1
    │   ├── matrixmultiply v0.3.9
    │   │   └── rawpointer v0.2.1
    │   │       [build-dependencies]
    │   │       └── autocfg v1.4.
    │   ├── num-complex v0.4.6
    │   │   └── num-traits v0.2.19
    │   │       └── libm v0.2.15
    │   │           [build-dependencies]
    │   │           └── autocfg v1.4.0
    │   ├── num-integer v0.1.46
    │   │   └── num-traits v0.2.19 ()
    │   ├── num-traits v0.2.19 ()
    │   └── rawpointer v0.2.1
    ├── rand v0.9.0
    │   ├── rand_chacha v0.9.0
    │   │   ├── ppv-lite86 v0.2.20
    │   │   │   └── zerocopy v0.7.35
    │   │   │       ├── byteorder v1.5.0
    │   │   │       └── zerocopy-derive v0.7.35 (proc-macro)
    │   │   │           ├── proc-macro2 v1.0.94
    │   │   │           │   └── unicode-ident v1.0.18
    │   │   │           ├── quote v1.0.39
    │   │   │           │   └── proc-macro2 v1.0.94 ()
    │   │   │           └── syn v2.0.99
    │   │   │               ├── proc-macro2 v1.0.94 ()
    │   │   │               ├── quote v1.0.39 ()
    │   │   │               └── unicode-ident v1.0.18
    │   │   └── rand_core v0.9.3
    │   │       └── getrandom v0.3.1
    │   │           ├── cfg-if v1.0.0
    │   │           └── libc v0.2.170
    │   ├── rand_core v0.9.3 ()
    │   └── zerocopy v0.8.23
    └── rand_distr v0.5.1
        ├── num-traits v0.2.19 ()
        └── rand v0.9.0 ()

What if devs don't do a good job of versioning and there is a real incompatibility between 0.9.3 and 0.9.4? Surely there's some way to actually require an exact version?

    "0": ">=0.0.0, <1.0.0"
    "0.9": ">=0.9.0, <1.0.0"
    "0.9.3": ">=0.9.3, <1.0.0"

The reason for this is that unless otherwise specified, the ^ operator is used, so "0.9" is actually "^0.9", which then gets translated into the kind of range specifier I showed above.

There are other operators you can use, these are the common ones:

    (default) ^ Semver compatible, as described above
    >= Inclusive lower bound only
    < Exclusive upper bound only
    = Exact bound

For this reason, if you are writing a library, you should in almost all cases stick to regular semver-compatible dependency specifications.

For binaries, it is more common to want exact control over versions and you don't have downstream consumers for whom your exact constraints would be a nightmare.

> So there's no difference at all between "0", "0.9" and "0.9.3" in cargo.toml

No, there is a difference, in particular, they all specify different minimum bounds.

The trick is that these are using the ^ operator to match, which means that the version "0.9.3" will satisfy all of those constraints, and so Cargo will select 0.9.3 (the latest version at the time I write this comment) as the one version to satisfy all of them.

Cargo will only select multiple versions when it's not compatible, that is, if you had something like "1.0.0" and "0.9.0".

> Surely there's some way to actually require an exact version?

Yes, you'd have to use `=`, like `=0.9.3`. This is heavily discouraged because it would lead to a proliferation of duplication in dependency versions, which aren't necessarily unless you are trying to avoid some sort of specific bugfix. This is sometimes done in applications, but basically should never be done in libraries.

Semver specifies versions. These are the x.y.z (plus other optional stuff) triples you see. Nothing should be complicated there.

Tools that use semver to select versions also define syntax for defining which versions are acceptable. npm calls these “ranges”, cargo calls them “version requirements”, I forget what other tools call them. These are what you actually write in your Cargo.toml or equivalent. These are not defined by the semver specification, but instead, by the tools. They are mostly identical across tools, but not always. Anyway, they often use operators to define the ranges (that’s the name I’m going to use in this post because I think it makes the most sense.) So for example, ‘>3.0.0’ means “any version where x >= 3.” “=3.0.0” means “any version where x is 3, y is 0, and z is 0” which 99% of the time means only one version.

When you write “0.9.3” in a Cargo.toml, you’re writing a range, not a version. When you do not specify an operator, Cargo treats that as if you use the ^ operator. So “0.9.3” is equivalent to “^0.9.3” what does ^ do? It means two things, one if x is 0 and one if x is nonzero. Since “^0.9.3” has x of zero, this range means “any version where x is 0, y is 9, and z is >= 3.” Likewise, “0.9” is equivalent to “^0.9.0” which is “any version where x is 0, y is 9, and z is >=0.”

Putting these two together:

  0.9.0 satisfies the latter, but not the former
  0.9.1 satisfies the latter, but not the former
  0.9.2 satisfies the latter, but not the former
  0.9.3 satisfies both

If we had “0.8” and “0.7.1”, no version could satisfy both simultaneously, as “y must be 8” and “y must be 7” would conflict. Cargo would give you both versions in this case, whichever y=8 and y=7 versions have the highest z at the time.

It is true that, if the change works on z < 3, you are expanding the possible set of versions a bit, so it's not useless; one could argue that you should only depend on z != 1 if there's a bug you want to make sure that you use the versions past when it works, otherwise, no reason to restrict yourself, but it's not a big deal either way :)

I'm over-simplifying a few things here:

1. Semver has special treatment of 0.x versions. For these crates the minor version depends like the major version and the patch version behaves like the minor version. So technically you could have v0.1 and v0.2 of a crate in the same crate graph.

2. I'm assuming all dependencies are specified "the default way", ie. as just a number. When a dependency looks like "1.3", cargo actually treats this as "^1.3", ie. the version must be at least 1.3, but can be any semver compatible version (eg. 1.4). When you specify an exact dependency like "=1.3" instead, the rules above still apply (you still can't have 1.3 and 1.4 in the same crate graph) but cargo will error if no version can be found that satisfies all constraints, instead of just picking a version that's compatible with all dependents.

Rust projects can really go bananas on dependencies, partly because it's so easy to include them