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 is a hypervisor that creates the illusion of a larger main memory address space for the operating system. Some pages will be mapped to the actual DRAM main memory while others are mapped to the SSD memory. When a page mapped to the SSD is accessed, a page fault occurs caught by IMDT, which will cause the page to be brought from the SSD to main memory (potentially evicting a page from memory to the SSD). IMDT will try to prefetch pages into DRAM to alleviate the inferior bandwidth and latency of the SSD. It will also try to keep the hottest pages in main memory so that they can be accessed with minimal penalty (the only penalty may come from the additional paging layers due to virtualization.) The OS is mostly oblivious to this mapping and works normally. This kind of memory system is called software-defined memory (SDM). The nice paper titled "Evaluation of Intel Memory Drive Technology Performance for Scientific Applications" provides a performance evaluation of IMDT and compares it against a system that has the same amount of DRAM main memory. I've not thoroughly read the paper, but it appears that IMDT can migrate pages between NUMA nodes to get them closer to the node where they are mostly needed.
That said, IMDT is only supported on server-grade Intel processors. It's intended to create cost-effective, power-efficient servers with a potentially small impact on performance.
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 "Optane DC Persistent Memory". https://www.anandtech.com/show/12828/intel-launches-optane-dimms-up-to-512gb-apache-pass-is-here. Apache Pass is the name of the first-generation Optane DC PM. Refer to this for information on future generations.
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 fsync or 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.)
The 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 clflush / 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.)
The Intel Optane SSD offers a nice performance-power-cost trade-off. SSDs basically don't consume power when not accessed. In contrast, the static power consumption (mostly due to refresh) in DRAM chips is significant. So the amount of DRAM in a system should ideally match the working set of the typical workload. The system you've purchased was designed for a typical workload that requires about 4GB of main memory or less. In this case, if the system had 8GB of main memory instead, it will unnecessary consume more power, which would reduce the battery life. However, the Optane SSD allows you to occasionally run workloads that require slightly more main memory with minimal performance degradation (compared to NAND-based SSDs or HDDs).
DRAM memory currently costs about USD 4.5$ per 1GB while Intel Optane SSD costs about USD 2$ per 1GB. So a 16GB Optane SSD is more expensive than a 4GB DRAM module, but cheaper than an 8GB DRAM module. So if you take out the Optane SSD and add 4GB more memory, you'll get a cheaper system, which is also faster on average for typical workloads with larger than 4GB working sets. But hard page fault handling, page prefetching, and page swapping would be slower from the HDD. That's why the 8GB system will probably be slower than the 4GB DRAM + 16GB Optane SSD system if the typical workload requires less than (or about) 4GB of memory.
Your laptop is great if you're just going to use it for Internet browsing or text editing. The Optane SSD helps with boot-time, provides quick access to the most frequently accessed files, and can be used as an additional secondary storage. So although you're paying more 16GB Optane SSD than 4GB of DRAM, you're getting certain, unique benefits for that. But some of the other applications you mentioned, such as RStudio, require a minimum of 4GB memory. If you'll typically use a browser and RStudio at the same time (and maybe other apps), then you should a get a system with at least 8GB of memory. Optane SSD is till good to have though.
What kind of harddrive do your laptops have, SSD? Optane does wonders for older drives, but a lot less for SSD systems. – Mast – 2019-01-07T09:20:04.070
@Mast, The laptop has a HDD. – N4v – 2019-01-10T14:42:26.923