10 ms·
Not an intuitive thing but the data is fascinating. A couple of notes of people who are confused by it: 1) The 'ns' next to the box is a graph legend not a dat
by ChuckMcM 5y ago
Not an intuitive thing but the data is fascinating. A couple of notes of people who are confused by it:
1) The 'ns' next to the box is a graph legend not a data label (normally that would be in a box labeled legend to distinguish it from graph data)
2) The weird box and rectangle thing on the top is a slider, I didn't notice that until I was looking at the code and said "what slider?"
3) The only changes from 2005 to present are storage and networking speeds.
What item #3 tells you is that any performance gains in the last decade and a half you've experienced have been driven by multi-core, not faster processors. And that means Amdahl's Law is more important than Moore's Law these days.
- ianai 5y ago"And that means Amdahl's Law is more important than Moore's Law these days." idk, sure seems like we could have 1-2 cores (permanently pegged?) at 5 ghz for UI/UX then ($money / $costPerCores) number of cores for showing off/"performance" by now. But the OEMs haven't gone that way.
- ChuckMcM 5y agoWe probably see things differently. As I understand it, this is exactly the use case for "big/little" microarchitectures. Take a number of big fast cores that are running full bore, and a bunch of little cores that can do things for them when they get tasked. So far they've been symmetric but with chiplets they needn't be.
- ianai 5y agoYes, for 'computational' loads. I've read though UI/UX benefits the most from fastest response times. I'm talking about the cores which actually draw the GUI the user sees/uses being optimized for the task at the highest possible rate. Then have a pool of cores for the rest of it.
- moonchild 5y agoUI should be drawn on the GPU. Absent rendering, slow cores are more than sufficient to do layout/etc. interactively.
- ChuckMcM 5y agoYou are talking about the GPU? Okay, really random tidbit here; When I worked at Intel I was a validation engineer for the 82786 (which most people haven't heard about) but was a graphics chip that focused on building responsive, windowed user interfaces by using hardware features to display separate windows (so moving windows moved no actual memory, just updated a couple of registers) to draw the mouse, and to process character font processing for faster updates. Intel killed it but if you find an old "Number9 video card" you might find one to play with. It had an embedded RISC engine that did bitblit and other UI type things on chip. EVERYTHING that chip did, could in fact be done with a GPU today. It isn't, for the most part, because window systems evolved to be CPU driven, although a lot of phones these days do the UI in the GPU, not the CPU for this same reason. There is a fun program for HW engineers called "glscopeclient" which basically renders its UI via the GPU. So I'm wondering if I misread what you said and are advocating for a different GPU micro architecture or perhaps an integrated more general architecture on the chip that could also do UI like APUs?
- bee_rider 5y agoI would rather reserve the thermal headroom for actual computations, rather than having those cores pegged at 5Ghz.
- ddingus 5y agoThe problem is in the, "Pegged at 5ghz" part. 5Ghz is hard! Not sure the OEM's have what it takes to do that without a serious rethink, and that is what an M1 basically is. And say they do... Amdhal's law is still going to be a thing because people are unlikely to believe having two cores running balls out whether essentially idling or pushing high priority interaction... they will see it very poor energy management, and would want tasks moved onto and off those always fast cores at a minimum to reduce what they see as waste.
- hvidgaard 5y agoIf you could have responsive and rich UI/UX 30-40 years ago you don't need anything but a highly efficient core prioritizing the UI. No need to waste energy on a super fast core.
- gameswithgo 5y agoThere is some improvement from processors being faster, as more instructions are done at once and more instructions get down towards that 1ns latency that l1 caches provide. You see it happen in real life but the gains are small.
- deleted 5y ago[deleted]
- stuartmscott 5y ago> And that means Amdahl's Law is more important than Moore's Law these days. 100%, we can no longer rely on faster processors to make our code faster, and must instead write code that can take advantage of the hardware's parallelism. For those interested in learning more about Why Amdahl's Law is Important, my friend wrote an interesting article on this very topic - https://convey.earth/conversation?id=41 https://convey.earth/conversation?id=41
- muh_gradle 5y agoI would never have realized the slider functionality until I read this comment.
- raisedbyninjas 5y agoI noticed the year was an editable field but didn't change the data before I noticed the slider.
- muh_gradle 5y agoI noticed it was editable, changed the data, didn't notice the slider, then all hell broke loose
- pjc50 5y agoIt also tells us that the speed of light has not increased. (well, speed of signal on a PCB track is roughly 2/3 light and determined by the transmission line geometry and the dielectric constant, but you all knew that)
- thfuran 5y agoWhich latency are you suggesting is limited by the speed of light?
- not2b 5y agoIt wasn't the speed of light, it was the size of atoms that was the issue here. As old-style scaling (the kind used up until about 2003) continued, leakage power was increasing rapidly because charge carriers (electrons / holes) would tunnel through gates (I'm simplifying a bit here, other bad effects were also a factor). It was no longer possible to keep increasing clock frequency while scaling down feature size. Further reduction without exploding the power requirement meant that the clock frequency had to be left the same and transistors needed to change shape.
- nightpool 5y ago"Packet roundtrip CA to Netherlands"
- chubot 5y agoWhat item #3 tells you is that any performance gains in the last decade and a half you've experienced have been driven by multi-core, not faster processors. And that means Amdahl's Law is more important than Moore's Law these days. Uh or storage and networking? Not sure why you would leave that out, since they're the bottleneck in many programs. The slowest things are the first things you should optimize
- horsawlarway 5y agoYeah... SSDs are so much faster than spinning disk it's not even funny. I literally refuse to run a machine that boots its main OS from spinning disk anymore. The 60 bucks to throw an SSD into it is so incredibly cheap for what you get. My wife's work gave her a (fairly basic but still fine) thinkpad - except they left the main drive as a fucking 5400rpm hdd. Then acted like assclowns when we repeatedly showed them that the machine is stalling on disk IO, while the rest of the system is doing diddly squat waiting around. I finally got tired of it and we "accidentally" spilled water on it, and somehow just the hdd stopped working (I left out the part where I'd removed it from the laptop first...). Then I just had her expense a new SSD and she no longer hates her work laptop. Long story short - Storage speeds are incredible compared to what they were when I went to school (when 10k rpm was considered exorbitant)
- capitainenemo 5y agoThe living room media/gaming machine at home is an 8 terabyte spinning rust. I didn't bother with a separate SSD boot partition. It's currently been running for 23 days. Booting takes ~15 seconds even on spinning rust for a reasonable linux distro, so I'm not going to stress about those 15 seconds every couple of months. total used free shared buff/cache available Mem: 31Gi 4.6Gi 21Gi 158Mi 5.1Gi 25Gi Swap: 37Gi 617Mi 36Gi 5.1 gigabytes mostly just file cache. As a result, everything opens essentially instantly. For a bit better experience, I did a: find ~/minecraft/world -type f -exec cat {} > /dev/null \; to forcibly cache that, but that was all I did.
- DonHopkins 5y agoAt what point did Joy's Law -- "2^(year-1884) MIPS" -- break with reality? https://medium.com/@donhopkins/bill-joys-law-2-year-1984-million-instructions-per-second-3a8c92165cfe https://medium.com/@donhopkins/bill-joys-law-2-year-1984-mil... https://en.wikipedia.org/wiki/Joy%27s_law_(computing) https://en.wikipedia.org/wiki/Joy%27s_law_(computing)
- IncRnd 5y ago> At what point did Joy's Law -- "2^(year-1884) MIPS" -- break with reality? It was never really true. PS It is formulated as 1984 not 1884, though. 1884 throws off MIPS calculations by 2^100 or 10^30.
- ______-_-______ 5y agoIf you look at single-threaded processor benchmarks, CPUs are still getting faster. The new i9's are 20% faster than the next-fastest chips. It's definitely not doubling every two years but it's still noticeable. https://valid.x86.fr/bench/1 https://valid.x86.fr/bench/1 Can you explain how to square that with the link saying compressing data hasn't gotten any faster since 2005?
- throwaway81523 5y ago> Can you explain how to square that with the link saying compressing data hasn't gotten any faster since 2005? Compression may be bottlenecked by ram (L2 or L3 cache) access speed, or maybe even dram (main memory) access speed.
- gallabytes 5y agoThat wouldn't make sense - compression has very cache-friendly access patterns, and would benefit greatly from the observed improvements in memory bandwidth.
- throwaway81523 5y agoThat surprises me to hear. I would expect it to jump around in ram a lot. And at higher compression settings, some compressors use a lot of ram, more than will fit in cache.
- ______-_-______ 5y agoI have an i7-3770k and an i9-12900k sitting here. Do you know of a benchmark I could run myself that would give me the same results on both CPUs?
- formerly_proven 5y agosleep 1?
- gallabytes 5y ago
- nicoburns 5y ago> What item #3 tells you is that any performance gains in the last decade and a half you've experienced have been driven by multi-core, not faster processors I think there are other effects too. Things like larger caches, smarter branch predictors, wider cores, etc. My 2021 processor (Apple M1 Pro) benches roughly twice as fast as my 2015 processor (Intel Core i5 2.7Ghz) in both synthetic and real-world single-core workloads. That's not as big an improvement as we would have seen over that time period in the 90s, but it's a significant improvement none-the-less.
- crote 5y agoThe interesting part is that it say nothing about performance. Single-core benchmarks have gotten significantly faster over that time period. If anything, the takeaway is that things like memory/cache access, branch prediction failures, and mutexes have gotten more expensive. They didn't scale while the rest of the CPU sped up! But even that isn't really true, because it doesn't tell you anything about branch prediction hit/miss rate, memory prefetching, instruction reordering, hyperthreading, etc. For a fair historic comparison you'd have to look at something like the cumulative time the execution units of a core are stalled due to waiting for something. Honestly, the actual numbers aren't even all that relevant. It isn't really about the time individual operations take, but about the budget you have to avoid a latency penalty.
- ChuckMcM 5y agoThis is a valid point, and this is an overly long response because it distracts me from watching frightening current events. There are two ways to look at these sorts of numbers, "CPU performance" and "Systems performance". To give an example from my history; NetApp was dealing with the Pentium P4 being slower than the Pentium 3 and looking at how that could be. All of the performance numbers said it should be faster. They had an excellent OS group that I was supporting who had top notch engineers and a really great performance analysis team as well, the results of their work was illuminating! Doing a lot of storage (and database btw) code means "chasing pointers." That is where you get a pointer, and then follow it to get the structure it points to and then follow a pointer in that structure to still another structure in memory. That results in a lot of memory access. The Pentium 4 had been "optimized for video streaming" (that was the thing Intel was highlighting about it and benchmarking it with.) in part because videos are sequential memory access and just integer computation when decoding. So good sequential performance and good integer performance gives you good results on benchmarking video playback. The other thing they did was they changed the cache line size from 64 bytes to 128 bytes. The reason they did that is interesting too. We like to think of things a computer does as "operations" and you say "this operation takes 0.x second, I can do 1/x operations per second." And that kind of works except for something I call "Channel semantics" (which may not be the official name for it but it's in queuing theory somewhere :-). Channel semantics have two performance metrics, one is how much bandwidth (in bytes/second) a channel has, and the other is what is the maximum channel operation rate (COR) in terms of transactions per second. Most engineers before 2005 or so, ran into this with disk drives. If you look at a serial ATA, aka SATA, drive it was connected to the computer with a "6 Gb" SATA interface. Serial channels encode both data and control bits into the stream so the actual bytes that go through a 6 gigabit line can be < 600 Mb when the encoding is 10 bits in the channel for every 8 bits sent (called 8b/10b encoding for 8 data bits per 10 channel bits (or bauds)). That means that the channel bandwidth of a SATA drive is 600MB per second. But do you get that? It depends. The other thing about spinning rust is that the data is physically located around the disk, each concentric ring of data is a track, and moving from track to track (seeking) takes time. Further you have to tell the disk what track and sector you want, so you have to send it some context. So, if you take the "average" seek time, say 10mS, then the channel operation rate (COR) 1/.010 or 100 operations per second. So let's say you're reading 512 byte (1/2K) sectors from random places on the disk, then you can read 100 of them per second, but wait 100? That would mean you are only transferring 50 kB per second from the disk, what happened to 600MB? Well as it turns out your disk is slow when randomly accessed, it can be faster if you access everything sequentially because 1) the heads don't have to seek as often, and 2) the disk controller can make guesses about what you are going to ask for next. You can also increase the size of your reads (since you have extra bandwidth available) so if you read, say 4 kb sectors, then 100 x 4 kB is 400 kB/second. And 8 fold increase just by changing the sector size. Of course the reverse is also true, if you were reading 10 Mb per read, at a 100 operations per second that would be 1000 Mb per second which is 400 Mb more than your available bandwidth on the channel! So when your channel request rate is faster than the COR and/or the data size requests are greater than the available bandwidth, you are "channel limited" and you won't get any more out of the disk no matter how much faster the source of requests improves its "performance" in terms of requests/second. So back to our story. Cache lines are read in whenever you attempt to access virtual memory that has not been mapped to the computer's cache. Some entry in the cache is "retired" (which means over written, or written out first if it has been modified, and then overwritten) and the new data is read in. The memory architecture of the P4 has a 64 bit memory bus (in 72 data bits if you have ECC memory) That means every time you fetch a new cache line, the CPU's memory controller would to two memory requests. Guess what? The memory bus on a modern CPU is a channel (they are even called "memory channels in most documentation") that are bound by channel semantics. And while Intel often publishes it's "memory bandwidth" number, it rarely would publish its channel operation limits. The memory controller on the P4 was an improvement over the P3, but it didn't have double the operation rate of the P3. (it was like 20% faster as I recall, but don't quote me on that.) But the micro-architecture of the cache doubled the number of memory transactions for the same workload. This was especially painful on code that was pointer chasing because the next pointer in the chain shows up in the first 64 bytes and that means the second 64 bites the cache fetched for you are worthless, you'll never look at them. As a result, on the same workload, the P3 system was faster than the P4 even though on a spec basis the P4's performance was higher than that of a P3. After doing the analysis some very careful code rewriting and non-portable C code which packed more data in the structures into the 128 byte "chunks" where both 64 byte halves had useful data in them. Improved the performance enough for that release. It also was that analysis that gave me confidence that recommending Opteron (aka Sledgehammer) from AMD with its four memory controllers and thus 4x memory operations per second rate was going to vastly outperform anything Intel could offer. (spoiler alert: it did :-)) Bottom line, there are performance" numbers and there is system performance* which are related, but not as linearly as certainly Intel would like.
- IncRnd 5y agoSomething else to consider is that the data doesn't seem consistent. For example, the top right label, "Read 1,000,000 bytes sequentially from SSD" shows as 31,000ns when I load the page, but when I move the slider to the left and back to 2020, it shows a different value, 49,000ns. This happens for about half of the values for the data labels in chrome, firefox, and safari. The initially shown values are neven shown again once the slider is moved, even when it is moved back to the starting position.
- jcheng 5y agoGood catch. It's because the initial value for year is: var year = new Date().getFullYear(); and 2022 is outside of the range of the slider. If you tweak the HTML to change the slider's max value to 2022, then it works properly.
- ZainRiz 5y agoActually, this data is all false from 2012 onwards. The code was written back in 2012 and is using numbers from back then to _guess_ what future numbers would look like! (I was fooled by it too) See https://github.com/colin-scott/interactive_latencies/issues/17 https://github.com/colin-scott/interactive_latencies/issues/...
- Dylan16807 5y agoEven the 2012 data is suspect. "Seek + rotational delay halves every 10 years" just isn't true. We got rid of the >7200 drives and are basically sitting still on that metric. And hard drives weren't at 400MB/s in 2012 either. (The disk bandwidth section also cites a 2012 presentation with correct numbers, but something went wrong in translation.)
- ChuckMcM 5y agoLooks like a fun project to bring it up to date.
- gurjeet 5y agoWhere would one lookup such data, if one is interested in updating the code.
- ChuckMcM 5y agoI would start by going through the Anandtech reviews of the major processor and storage announcements. They generally do a great job of benchmarking and go into pretty good detail. Datasheets from manufacturers would also be useful although not all data is routinely provided.
- saagarjha 5y agoThis is the kind of thing you’d typically experimentally verify rather than look up.
- marcan_42 5y agoYeah, I was wondering where the heck 2ms disk seek times came from. That's not a thing and will never be a thing; disks only spin so fast, and nobody even uses >7200RPM drives any more (because we've all moved to SSDs instead).
- ksec 5y agoWhile the numbers may not be absolutely correct as stated in other comments, on a relative terms the conclusion from the trend is the same. SSD was the biggest upgrade in performance in the past 15 years. There are still lots of system running on old HDD. And the chart shows why I have been calling attention to latency computing for 10+ years. I hope the next stage is to reduce latency from Input, from keyboard to touch screen, and display input, and the actual display panel itself. On a 120hz screen even if you assume zero latency in everything else you still have a minimal of 8.3ms delay. Which is still quite obvious [1] once you put things in motion. And I think it is so hard there is enough room for at least another 10 years of hardware improvement. [1] Applied Sciences Group: High Performance Touch https://www.youtube.com/watch?v=vOvQCPLkPt4 https://www.youtube.com/watch?v=vOvQCPLkPt4
- Thorrez 5y agoYour definition of "storage" must be including memory, because the page says memory has been speeding up.