Saturday, November 01, 2025

AI Exponential: Moore's Law

Usually Moore's law, a foundation of AI and computing progress,
is represented in logarithmic scale: and that is not intuitive for most people.
It is a challenge even for AI :)

Moore's Law from 1947 (when the transistor was invented)
to 2030 on a linear scale:
doubling every 2 years
By 2020: 2^36.5 ≈ 92 billion transistors
By 2030: 2^41.5 ≈ 3 TRILLION transistors

correct, exponential chart:


first AI chart with bug: “overflow” (wrong chart)


For commercial GPUs: Nvidia's Blackwell-based B100 accelerator has 208 billion transistors, 2024
GB200 = 2xB100

For the absolute largest chip (wafer-scale): Cerebras's Wafer Scale Engine (WSE) has 2.6 trillion transistors with 850,000 cores 

Interestingly, this means the Cerebras chip already exceeds the 2030 projection from Moore's Law that we charted! However, it's a specialized wafer-scale design rather than a conventional chip, which is why the industry still talks about reaching 1 trillion transistors for traditional multi-chiplet GPUs by 2030-2034.

GB200 NVL72 | NVIDIA

The Engine Behind AI Factories | NVIDIA Blackwell Architecture


UUID v4 vs v7: Postgres 18

UUID v4 is a fully random, non-ordered identifier, while UUID v7 is a time-ordered identifier that includes a timestamp and random bits. UUID v4 is good for general use, but UUID v7 is better for database performance because its sequential nature reduces index fragmentation and improves write efficiency.

Why UUID7 is better than UUID4 as clustered index in RDBMS : r/programming


PostgreSQL UUID Performance: Benchmarking Random (v4) and Time-based (v7) UUIDs - DEV Community

UUIDv4: Random

UUIDv4 is the most commonly used version. It sets only two fields:
  • Version = 4 (in the 13th hex digit).
  • Variant = 10xx (in the 17th hex digit).
Everything else is pure randomness. This ensures high entropy but results in non-sequential values.

UUIDv7: Time-based

UUIDv7 was introduced to improve temporal ordering and index performance. It uses the high bits to encode a Unix timestamp in milliseconds, while the remaining bits are random to preserve uniqueness.

Comparing UUIDv4 v.s. UUIDv7 in PostgreSQL - Seven's Blog

UUIDv4 is widly used, but it’s not suitable for database primary key. Because it’s not sequential, and it’s not sortable. UUIDv7 is a new UUID version, it’s sequential and sortable. It looks interesting to use it for database primary keys.

UUIDv7 Comes to PostgreSQL 18

UUIDs were first standardized in RFC 4122 in 2005. This RFC defines 5 variants of UUIDs, of which variant 1 and 4 are the most common. The specification was later revised to add variants 6-8 in RFC 9562 which was published in May 2024 (although the first public working draft was published in 2020).

Until PostgreSQL 18, UUIDv7 was not natively supported. The built-in gen_random_uuid() function generated UUIDv4, and while the popular uuid-ossp extension added support for additional UUID variants, it was limited to the variants specified in RFC 4122.

PostgreSQL 18 adds a new function: uuidv7(), which generates UUIDv7 values. The Postgres implementation includes a 12-bit sub-millisecond timestamp fraction immediately after the timestamp (as allowed but not required by the standard). This guarantees monotonicity for all UUIDv7 values generated by the same Postgres session (same backend process).