In this context (budget consumer gear), Optane is pretty clearly just referring to a small/fast NVMe-connected SSD using 3D XPoint memory (instead of NAND flash), giving it a very high write endurance. (So it won't wear out if used as swap space).
This is still going to suck for many workloads, because it still takes a page-fault and many microseconds to access, vs. ~70 nanoseconds for a DRAM access (cache miss); it's not directly memory-mapped on the CPUs memory bus. Also, out-of-order execution / HW prefetch / other memory-parallelism can keep ~10 cache misses in flight per physical core, but a page fault is serializing. No useful work can be happening (in this thread) while the OS is servicing a page fault, so there's no opportunity for OoO exec to hide any of that hard page fault latency. (But even 70ns is too long to fully hide anyway. Still, having multiple misses in flight to different lines goes a long way toward mitigating it for some workloads.)
Using a cripplingly-small amount of RAM and depending on a fast SSD for swap space / pagefile is not the only use-case for this kind of Optane. (And probably not even a good use-case). As https://www.tweaktown.com/articles/8119/intel-optane-memory-matters/index.html describes, it's main use-case is as a transparent cache for a magnetic hard drive. I think Intel provides Windows drivers to make this happen. You can buy SATA hard
drives that have rotational magnetic storage with some flash built-in as a buffer / cache for frequently-accessed parts of the disk. Optane HW + drivers can do this for any disk.
Optane NVMe apparently has very good random read performance at low queue depth (wait for one read to finish before starting another, which unfortunately does happen when a program has to read one block before it can figure out what to do next, and software prefetching isn't helping). So it should be great at speeding up program start times, and bootup.
Not particularly amazing for large contiguous writes of big files; hopefully the driver software knows to bypass the Optane cache and go straight to the underlying magnetic disk for that. Intel's main Optane page links to https://www.intel.ca/content/www/ca/en/products/memory-storage/optane-memory/optane-16gb-m-2-80mm.html which shows their 16GB M.2 Optane has 900MB/s sequential read, but only 145MB/s sequential write. The 32GB version is faster, at 1350 MB/s read, 290 MB/s write. But again, those aren't what Optane is best at. It's sequential and random read IOPS are both 240k IOPS, with 7 µs read latency.
Intel has something called IMDT (Intel Memory Drive Technology) which might involve actually mapping the PCIe NVMe storage into memory address space, perhaps for direct access as RAM-like memory. (I'm not sure if this is correct.)
http://www.lmdb.tech/bench/optanessd/imdt.html has some benchmarks with an Optane DC P4800X SSD. (The high-end data-centre version, not consumer stuff. Much higher sustained write capability.)
I haven't looking into this, so I'm not sure if it's relevant at all for how Windows could take advantage of a consumer Optane SSD.
The Optane brand name is (somewhat confusingly) also used for a much more interesting exotic thing:
3D XPoint Non-volatile DIMMs, aka Apache Pass, aka "Optane DC Persistent Memory". https://www.anandtech.com/show/12828/intel-launches-optane-dimms-up-to-512gb-apache-pass-is-here.
Intel has their own mostly-marketing page for it here, with some links to tech details. The "DC" stands for Data-Centric, apparently.
This is non-volatile storage that plugs in to a DDR4 DIMM slot, and appears as actual physical memory. Apparently it's only fully supported by next-generation Xeons (not the current Skylake-X aka Skylake Scalable Processor series).
There are other kinds of NVDIMM, e.g. battery-backed regular DRAM (optionally with flash to dump the data to for long-term power off, so they only need a supercapacitor instead of a chemical battery). https://en.wikipedia.org/wiki/NVDIMM has some details.
https://www.electronicdesign.com/industrial-automation/why-are-nvdimms-suddenly-hot has some more general info on NVDIMMs (and JEDEC standardization of them, and how OS + applications can cooperate to let applications talk directly to a region of memory mapped NV storage, ensuring commit ordering and so on). The main point is that they actually blur the line between RAM and storage (in a computer-architecture sense, not in the strictly-marketing sense of the deceptive laptop ad you saw that claimed 4+16GB.)
The OS can let a process map this non-volatile physical memory into their own virtual address space so they can access storage directly with user-space loads and stores to memory addresses, without any system calls, letting the CPU hardware continue out-of-order execution while there are outstanding reads/writes. (There are software libraries to let developers take advantage of this, including the ability to
flush() and make sure that data is actually written to persistent storage.
This mapping can even be write-back cacheable, so usage of the data benefits fully from L3/L2/L1d cache until it's time to write it back (if modified). For read-mostly data, this kind of Optane really could justifiably be called 4+16GB of RAM. (Of course, the current data-centre use-case for Optane NVDIMMs would use much larger DIMMs, like 512GB.)
(It's not like an
mmaped file on a normal disk where you just map the OS's page-cache for the file, and the OS takes care of doing I/O in the background to sync dirty RAM pages with the storage device.)
Making sure some data has actually reached NV storage before others (to allow crash recovery like a filesystem or database journal) is essential. With system calls, this is where you'd use POSIX
fdatasync. But since the application has the storage truly memory-mapped, this is where library function calls come in.
In x86 asm, we're accessing storage with normal loads/stores, but we care about when data is actually written back to the NVDIMM (where it's safe from power loss), not when it's visible to other cores or to cache-coherent DMA (as soon as it commits from the store buffer to L1d cache), so x86's normal memory-ordering rules don't completely take care of everything. We need special instructions to flush selected cache-lines from the CPU's cache. (For use by the NV storage libraries.)
clflush asm instruction has existed for a while, but NV storage is a major reason why Intel added
clflushopt in Skylake (although it has other use-cases, too), and is adding
clwb in Ice Lake (write-back without eviction).
Dan Luu wrote an interesting article a while ago about the benefits of taking the OS out of the way for access to storage, detailing Intel's plans at that point for
clwb and their memory-ordering semantics. It was written while Intel was still planning to require an instruction called
pcommit (persistent commit) as part of this process, but Intel later decided to remove that instruction: Deprecating the PCOMMIT Instruction has some interesting info about why, and how things work under the hood.
(This got way off topic into x86 NV storage low level details. I should find somewhere else to post most of this section, but I think it )
There are also Optane DC SSDs, as a PCIe x4 card or 2.5". The 750GB version does up to 2500 MB/s sequential read, 2200 MB/s sequential write, and 550000 IOPS random read or write. Read latency is slightly worse than the M.2 NVMe, at 10 µs.
This is what you want if you for a database server or something (if you can't use NVDIMM), but it wouldn't make your 4GB laptop much faster (for most typical use cases) than the 16GB Optane they sell it with. Swap space thrashing often produces a lot of dependent reads as a page has to be paged in and accessed before the code that page-faulted can continue on to whatever it was going to do next. If memory is really tight, the OS doesn't have spare pages to aggressively prefetch into, so you'd expect low queue depths which the consumer Optane is optimized for. (Low latency.)