Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RAM is the new disk – and how to measure its performance (2015)

tanelpoder.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: RAM is the new disk – and how to measure its performance (2015)

#41

Post by dragontamer »

tanelpoder wrote: post #28
fctorial wrote: post #22

Earlier quoted context omitted.

They aren't faking the number. A hyperthreaded core is two separate cores that share alu, fpu etc.

I think it's more correct to say that a single core has two "sets of registers" (and I guess instruction decoders/dispatchers perhaps)... so it's a single core with 2 "execution entry points"?

Skylake has 180 registers. "mov rax, [blah]" performs "rax = malloc()" from this pool of 180-registers / "the register file". Eventually, the retirement unit "garbage collects" the registers that aren't used anymore for recycling.

Yeah, out-of-order processors are weird. (https://en.wikipedia.org/wiki/Tomasulo_algorithm)

If you have one thread that doesn't need a lot of registers for some reason (ie: most of its dependency chains are short, and it has very few memory operations), then you can have a 2nd thread eat up the ~180 registers that it wasn't using. "Sharing" the malloc pool of registers.

Re: RAM is the new disk – and how to measure its performance (2015)

#42

Post by jeffbee »

dragontamer wrote: post #40
jeffbee wrote: post #13

Earlier quoted context omitted.

Anything you can do with SMT you can do without SMT using ILP instead. SMT does not grant a CPU extra cache-filling resources.

Depends on the implementation of SMT. I know that POWER9 for example, reserves the superslices for different threads as you go from SMT1 (1-thread per core) up to SMT4 (4-threads per core). Thread#0 and Thread#1 get Slice0, while Thread#2 and Thread#3 get Slice1. -------- For an even more extreme example, Bulldozer's implementation of SMT / Cores / whatever you wanna call it... the L1 cache was split between the two…

Yeah, thanks for adding details. SMT on Skylake and later is quirky, people don't appreciate that the CPU replicates some things, partitions others, and fights over some. The static partitioning in particular means that if you try to disable HT by taking all of the odd core numbers offline[+] you just wasted half of your L1 cache and iTLB entries.

+: I know this sounds like an obviously-wrong approach to the problem, but I came across it at a large, well-known, public company.

Re: RAM is the new disk – and how to measure its performance (2015)

#44

Post by monocasa »

vlovich123 wrote: post #2

I think how DMA operates needs another serious look. Right now we have to fetch everything into the CPU before we can make decisions. What if we had asynchronous HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU. In other words, a linked list would be much faster and simpler to traverse. A lot of the software archite…

There are NICs that more or less run BPF for exactly those reasons.

Re: RAM is the new disk – and how to measure its performance (2015)

#45

Post by monocasa »

jeffbee wrote: post #36
freeone3000 wrote: post #33

Earlier quoted context omitted.

why is that? we need the CPU to handle page fault interrupts, in order to populate the RAM. But assuming the page is already in RAM, there's no reason any of the memory accesses actually need to go through the CPU. (hardware can already raise interrupts; if the MMU can raise a page fault indicator, then you might be able to bypass CPU entirely until a new page needs to be loaded) moreover, if we have support for mmap…

Pointers are virtual addresses but memory is accessed physically. All of the means of translating virtual to physical are in the CPU. If you are proposing throwing out virtual addressing, I imagine you won't get a lot of support for that idea.

Or just have ubiquitous IOMMUs, which we should do for a million other reasons anyway.

Re: RAM is the new disk – and how to measure its performance (2015)

#46

Post by totalZero »

vlovich123 wrote: post #2

I think how DMA operates needs another serious look. Right now we have to fetch everything into the CPU before we can make decisions. What if we had asynchronous HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU. In other words, a linked list would be much faster and simpler to traverse. A lot of the software archite…

Perhaps one problem with that is the modularity with various processors, which would have to know when they are configured with memory to which certain operations can be farmed out, and when they are configured with traditional memory that cannot manage those in-place operations.

Re: RAM is the new disk – and how to measure its performance (2015)

#47

Post by xiphias2 »

WJW wrote: post #31
BenoitP wrote: post #29

Earlier quoted context omitted.

> HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU Well, that seems to be the exact definition of what UPMEM is doing: https://www.upmem.com/upmem-announces-silicon-based-processi... Between the M1, GPUs, TPUs, RISC-V interesting times are coming in hardware. I blame the physical limits, which are putting the Duke N…

You'd hope that the only way to better performance was HW specialisation, but there are SO MANY algorithmic improvements still to be made. Just the other day I found a case someone had rolled their own priority queue with a sorted array instead of a heap. In a fairly popular open source library too. There's still loads of performance to be gained just by being better programmers.

Better abstractions are the solution, not better programmers.

Actually with better abstractions worse programmers are able to achieve the same thing.

Re: RAM is the new disk – and how to measure its performance (2015)

#48

Post by fomine3 »

tanelpoder wrote: post #5
rektide wrote: post #3

meanwhile, disk is potentially getting to be as fast as ram, throughput wise. 128 lanes of pcie 4.0 is 256GBps iirc. epyc's 8 channel ddr4-3200 otoh is good for 208GBps. Let's Encrypt stopped a little short, using 24x nvme disks (it fits in a 2U though so that's nice)[1]. that could be up to 96 of 128 pcie links in use. with the right ssds, working on large data-objects, that'd be somewhere a bit under 192GBps versus…

Author (of the RAM article) here: Indeed, you can go further, but got to plan for other bandwidth needed by other peripherals, data movement and inter-CPU bandwidth (NUMA) and intra-CPU-core bandwidth limitations too (AMD's infinity fabric is point to point between chiplets, but intel has some ring-bus architecture for moving bits between CPU cores). I got my Lenovo ThinkStation P620 workstation (with AMD Zen-2 Threa…

Changing NUMA per socket(NPS) config would be interesting.

EPYC Rome (or equivalent TR) was advertised as unified compared to Naples, but actually it's a bit NUMA / NUPA? (Peripheral Access, anyone knows the correct word?) so it has "Quadrant".

Re: RAM is the new disk – and how to measure its performance (2015)

#49

Post by hinkley »

xiphias2 wrote: post #47
WJW wrote: post #31

Earlier quoted context omitted.

You'd hope that the only way to better performance was HW specialisation, but there are SO MANY algorithmic improvements still to be made. Just the other day I found a case someone had rolled their own priority queue with a sorted array instead of a heap. In a fairly popular open source library too. There's still loads of performance to be gained just by being better programmers.

Better abstractions are the solution, not better programmers. Actually with better abstractions worse programmers are able to achieve the same thing.

Many of my problems at work are due to people in the uncanny valley between using libraries and writing their own.

Re: RAM is the new disk – and how to measure its performance (2015)

#50

Post by hinkley »

monocasa wrote: post #44
vlovich123 wrote: post #2

I think how DMA operates needs another serious look. Right now we have to fetch everything into the CPU before we can make decisions. What if we had asynchronous HW embedded within the memory that could be given a small (safe) executable program to process the memory in-place rather than evaluating it on the CPU. In other words, a linked list would be much faster and simpler to traverse. A lot of the software archite…

There are NICs that more or less run BPF for exactly those reasons.

Give me SQLite running directly on an nvme card.
Post reply on HN