Tuesday, September 22, 2020

An overview of PC build performance limitations and their resolutions

This post is the follow up to the more philosophical discussion of why 'bottleneck' isn't a terribly helpful concept in understanding and fixing PC build issues. It intends to offer a more sound perspective that isn't fixated on the 'bottleneck' concept and is geared towards new builders.

This article isn't intended as a comprehensive guide to tuning or optimizing every aspect of a PC build. It's more of an overview to help new builders get oriented towards building for and optimizing the total play experience. I'll probably follow up with a final post in the series with more practical, step-by-step build development advice based on the framework I'm laying out here.

The total play experience

Focusing just on statistical performance optimization in building or optimizing a PC is, I think, too narrow a view. Instead, the goal should be to optimize the total play experience: this includes not only what is traditionally thought of a 'performance optimization' (i.e. trying to squeeze every single FPS out of a game), but also elements that are more about 'quality of life' and contribute less directly, if at all, to, e.g., a system's scores on a synthetic benchmark.

Broadly, the 'performance optimization' elements have to do with directly optimizing the system's rendering pipeline, so we'll start that topic with a brief discussion of what this is and the three main components that contribute to it -- CPU, GPU (or graphics card) and the monitor (or display) refresh rate.

But first, we'll start with the more indirect, 'quality of life' elements, because they're easier to understand and summarize.

Quality of life elements

There are many aspects of a system that improve the quality of the play experience. For instance, having a keyboard or mouse that is responsive and 'just feels right' may significantly improve a gamer's experience. The right desk or chair might greatly increase comfort. A reliable, low-latency Internet connection greatly improves the experience of online games. Not to take away from any of these factors, but at the highest level, I think there are three build elements that, when properly considered and set up, greatly contribute to quality of life in a modern gaming PC build: mass storage, RAM and monitor factors other than refresh rate (we'll discuss refresh rate in the performance optimization section).

Mass Storage

Mass storage refers to where your system stores large sets of files, such as your operating system, game downloads, documents and save game files. In a typical Windows system, mass storage devices are assigned drive letters like C, D, E and so on.

Physically, mass storage devices can either be mechanical Hard Disk Drives (HDDs), which store data using magnetic plates or solid state drives (SSDs), which store data using electrical signals in memory chips. HDDs are the older technology, are much cheaper per gigabyte of storage and tend to come in lager capacities (eg 2TB, 4TB and up). SSDs are newer, are more expensive per gigabyte and tend to come in smaller capacities (e.g. up to 2TB, though larger devices are starting to become available). Both HDDs and SSDs come in a variety of form factors. All HDDs and some SSDs need to be mounted to mounting point in your PC case and connected to your motherboard with one cable for data and to your system's power supply with a second cable for power. Some SSDs are cards that are installed directly into a slot on your motherboard and don't require any separate cables. Others are installed and connected just like hard drives.

SSDs are able to store and retrieve data significantly (dozens or hundreds of times) faster than HDDs. This means that if you install your operating system on an SSD, your PC will boot noticeably faster than it will from an HDD. And if you store your games and save game data on an SSD, level and save file load times will be faster.

In my experience of using computers over 30 years, switching to a system with an SSD had the single biggest impact on how 'snappy' I perceived my system to be as compared to any other innovation or evolution of hardware.

RAM

RAM (Random Access Memory) is very fast storage that your system uses for programs that are actively running. For most modern (circa 2020) games will run fine on a system with 8GB of available RAM, with 16GB providing reasonable room for future proofing.

Keep in mind that these are recommendations for available RAM. Your game you're playing isn't going to be the only thing using RAM on your system. The operating system itself has some overhead. And if, like most people, you have several browser tabs, chat programs and utilities running in the background while you game, each of those consumes RAM, leaving less than 100% of your total RAM available to the game.

Running out of RAM while gaming is not fun. It can lead to the game becoming unstable or crashing in the worst case scenario. Short of this, when a typical Windows system runs low on available memory, it attempts to free it up by writing some data from RAM to one of the system's (much slower) mass storage devices in a process known as paging. This process consumes processor and disk resources as it runs, which can end up stealing those resources from the game itself and leading to lag or hitching.

There are other considerations that go into fully optimizing a system's RAM beyond capacity. These include the speed at which the memory operates, the number of memory modules, the fine tuning of memory timings and more. Different systems are more or less sensitive to different aspects of memory performance/optimization: AMD Ryzen processors, for example, have been shown to benefit significantly from fast RAM.

Monitor Factors

First of all, I strongly encourage you to think of your monitor as integral component of your gaming system. It's the thing you're going to spend all your time looking at. If it doesn't deliver a good experience to you, it's going to be a bummer.

Refresh rate (discussed) later is only one factor affecting the quality of the play experience provided by your monitor. Other factors (by no means exhaustive) include
  • How accurately the monitor reproduces color
  • How black its blackest blacks are
  • How big it is physically
  • It's pixel resolution
  • What its pixel response time is (i.e. how fast pixels can change color)

Rendering Pipeline Performance

The elements of a gaming system most traditionally identified with its performance and specs make up its rendering pipeline. Before discussing the components -- CPU, GPU and monitor refresh rate -- let's talk about what the rendering pipeline is.

Frame rendering

As you probably know, moving video and game images are made up of frames: still images that get shown to us very rapidly, one after the other. If the images are presented rapidly enough, this creates the illusion of motion. In games, the rendering pipeline is the process by which these frames get generated in realtime and are presented to the user.

Performance of the rendering pipeline on a given system is traditionally expressed in Frames Per SecondFPS or framerate. As you know from your experience as a player, a game's framerate can vary from moment to moment based on how demanding the rendering work is at that moment. If a game isn't able to consistently generate enough FPS for a given user to perceive continuous motion, the play experience is compromised by stutter, lag, hitching, etc. The more FPS the system can present to the user, the smoother the play experience will seem (up to certain limits).

In order to ultimately 'deliver' a frame to the player, each component of the rending pipeline must perform a specific function before 'shipping' the frame on to the next component. For example, the CPU must finish its work on a given frame before the GPU (the next component in the pipeline) can begin its work on it. The GPU needs the results of the CPU's work in order to do its job (this is a slight oversimplification but its true enough for our purposes).

For a user to play a game at a steady 60 FPS, the system must present him with a new frame every 16.67 milliseconds. If the CPU takes so long to do its work before handing the frame off to the GPU that the entire rendering process can't complete within that 16.67 milliseconds, the frame rate with go down. This is an example of the proper understanding of the concept 'bottleneck.' If the frames take long enough to generate, the user will experience stutter, hitching and the like.

CPU

The Central Processing Unit or CPU is the general-purpose computing 'engine' of your system. In the frame rendering cycle, the CPU is responsible for two main things. The first is computing the state of the game in every frame. You can think of the game's state as the complete set of information about every element of the game and every object in the game world.

Computing the game's state requires the CPU to do many things, for instance processing control inputs, updating the game's physics simulation and processing the behavioral instructions of enemy AI. The more complex the game, the more the CPU has to do each frame. A strategy game with hundreds of AI units on the screen at once will require more CPU resources to update its state than a simple 2D platformer.

Once the game's state has been calculated, the CPU uses that data to create the instructions that the GPU will use in the next step of the frame rendering cycle. These instructions are known as draw calls. The more visually complex the frame is, the more draw calls will be required for the GPU to render it and, therefore, the more draw calls the CPU will first need to make. Factors like how high the game's resolution is, texture quality, number of light sources in the scene and whether any post-processing effects (e.g. fog or blur) are being applied affect the number of draw calls.

As far as performance goes, one CPU can be superior to another in its ability to run more instructions per second. When we speak of one CPU being 'faster' than another, this is essentially what we're referring to. A CPUs clock rate, usually expressed in megahertz or gigahertz (e.g. 4.5Ghz) is a measurement of how many instruction cycles per second the CPU can perform, with higher numbers indicate higher performance. All things being equal, a faster CPU will be able to drive more FPS than a slower one.

Modern CPUs typically contain more than one CPU core. Each core is capable of running instructions independently of the other cores and at the same time, allowing the CPU on whole to do more things at once. Historically -- and still in 2020 -- most games are not coded in a way that takes advantage of lots of processing cores, so games generally benefit more from faster CPU clocks than they do from more cores. This is starting to change though. With the availability of inexpensive, higher core count consumer CPUs like AMD Ryzen and low-level APIs like DirectX 12 and Vulkan that let developers more easily create games that take advantage of and automatically scale to higher core counts, expect more and more games to optimize for multicore performance over pure clock rates in the years to come.

GPU

The GPU is an integrated set of components, including dedicated processors and (usually) memory, that can create visual images very quickly. Because their components are highly optimized for this task, GPUs can create these images much more quickly than general-purpose computing hardware (like a regular CPU) can, which is a necessity for high-FPS gaming: the modern CPUs and system RAM can't both process the game state and render the visuals quickly enough, so the workload gets split between the CPU and GPU.

GPUs use raw visual assets (such as the textures used to create object's appearances) and follow the instructions contained in the draw calls to produce the frame images that the player eventually sees. A draw call might (effectively) contain an instruction that says 'apply this texture to the surface of a triangle with it vertices at the following screen coordinates...' The GPU is the system component that actually executes these instructions and ultimately determines what color each pixel in the frame should be based on that frames total set of draw call instructions.

As GPUs evolve over time, manufacturers increase their capabilities by making their processing units faster, adding more processing units, adding more and faster memory and more. More powerful GPUs are able to process more FPS than less powerful ones. In some cases, new GPUs support entirely new capabilities. Nvidia's RTX GPUs for example, have specialized processing cores that allow them to accurately simulate how light travels and interacts with different surfaces, creating much more realistic lighting effects in a process known as realtime ray tracing (in games where the developer supports it).

If a CPU is consistently able to hand the GPU an acceptable number of FPS but the GPU is unable to do its work quickly enough, then the GPU may be bottlenecking the system (in the legitimate sense of that term).

Monitor Refresh Rate

Once the GPU has finished rendering a frame, it sends that frame to the monitor (or other display device like a TV), which then displays it. Monitors are capable of updating themselves a certain number of times per second. This is known as the monitor's maximum refresh rate, or simply refresh rate, and is measured in cycles per second, or hertz (hz). A 60hz monitor can fully replace the image on the screen 60 times per second.

Like other parts of the rendering pipeline, fully refreshing the display takes some (tiny) finite amount of time: it doesn't happen instantaneously. Modern monitors update themselves by replacing the contents of the screen one line (or row) at a time from top to bottom. On a 1920 by 1080 monitor, there are 1080 rows of pixels on the screen. During each update cycle, the first line is updated, then the second, then the third, and so on. After the 1080-th line is updated, the process starts over again for the next frame.

As mentioned earlier, a monitor with a higher refresh rate (paired with other system components capable of driving it) will result in a gaming experience that feels smoother and more immediate, within the limits of what the player can appreciate. Some people can actually perceive the flicker between frames of a 60hz monitor. Others can't. Most gamers will perceive an improvement in smoothness when moving from a 60hz to a 120 or 144hz display. Elite gamers like esports athletes can benefit from 240hz and even 360hz displays, at least under certain circumstances. At an extreme, it's almost certain that no human being would benefit from a hypothetical 1000hz monitor as opposed to a 500hz one.

If your GPU is not capable of driving more FPS than your monitor's refresh rate, you are leaving performance -- in the form of potential smoothness and immediacy -- on the table, assuming you can personally perceive the difference between the current and potentially higher refresh rates. For me -- a 40+ year-old person (whose vision and reflexes have therefore started to deteriorate with age) who doesn't play a lot of twitch-heavy game titles, I can appreciate the difference between 60 and 144hz in the titles I like to play. But I can't perceive any difference between 144 and 240hz or higher. A younger, elite player of twitch-heavy games might have a different experience, but a system capable of doing 240hz (as opposed to 144) would be wasted on me.

The opposite situation can also be true: your GPU may be capable of providing more FPS than your monitor's refresh rate is capable of displaying. In practice, this usually results in one of two conditions:

  1. If you do nothing else, the system will continue to deliver frames to the monitor as it generates them. This means that the monitor may receive more than one frame per refresh cycle. At whatever point during the refresh cycle the new frame is received, the monitor will pick up refreshing the next display line based on the newer data in the second frame. This results in what players experience as tearing: a visible line on the screen that represents the border between where the monitor drew the frame based on the older vs. the newer frame data.
  2. The GPU/game setting called Vsync forces the GPU to synchronize its refresh rate with that of the monitor. Since a standard monitor is a 'dumb' device in this respect, this is accomplished by the GPU artificially limiting the framerate it outputs to coincide with monitor's refresh rate. This means that even though your GPU and CPU might be able to output 300 FPS on a given game, Vsync will limit that output to 144hz if that's all your monitor will support. This eliminates tearing but leaves frames on the table.
There are also what are known as adaptive refresh rate technologies like GSync and Freesync which make the monitors that support them smarter. These monitors are able to communicate with the GPU and can synchronize their refresh cycles precisely at the arbitrary FPS value the GPU is outputting at a given moment (up to the monitor's maximum refresh rate).

If you are in this scenario (and assuming you don't have an adaptive display), which side of the lower FPS / no tearing vs. higher FPS / with tearing line you fall on is a matter of personal preference.

As noted elsewhere, there are verifiable benefits -- especially for competitive gamers -- to running at the highest FPS possible, even if your monitor's refresh rate is lower. A full discussion of this issue is beyond the scope of this post, but I do want to acknowledge it. But I consider it a specialized issue relevant to certain gaming scenarios, not one of general build advice.

Putting in All Together

This table summarizes the six components of a build that most commonly impact quality of life and rendering performance, along with how the user will perceive a component with sub-optimal performance.


‘Quality of Life’ Components

System Component

Description

What you’ll experience if this component is limiting system performance

Mass Storage

Provides long-term storage for lots of files like your operating system, game files and savegame data

A slow mass storage device (such a traditional HDD) will make loading games and saving/loading savegame seem slow.

RAM

Provides super-fast working memory for running programs (including games)

If the system doesn’t have enough available memory for all running programs, games may hitch, lag or slow down as the operating system pages to use slower mass storage to hold data that would otherwise be in RAM.

Monitor factors (not refresh rate)

Affect the perceived quality of the visuals displayed

·         Inaccurate color reproduction

·         Harsh or jagged edges around objects

·         Motion trails

·         Visual artifacts

·         Overly bright or dim images (even after monitor adjustment)

Rendering Pipeline Components

System Component

Function

What you’ll experience if this component’s performance is being limited by the preceding one

What you’ll experience if this component gates the performance of the preceding one

CPU (or processor)

Provides general-purpose computational power to the system. In games, does computational work to update the game’s state and to create the draw call instructions the GPU will use.

N/A

·         N/A

GPU (or graphics card)

Executes draw call instructions to generate the frame images that will be presented to the user

·         Lower FPS

·         Lag and stutter

·         Lower FPS

·         Lag and stutter

·         Missing out on certain visual effects / visual quality as you lower graphics settings to compensate

Monitor refresh rate

Refers to how many times per second the monitor can update every pixel on the screen

Visuals that seem less smooth than they might otherwise be (difference may not be perceptible to all users)

·         With Vsync disabled, frame tearing

·         With Vsync enabled, lower FPS than you would otherwise achieve


Wednesday, September 16, 2020

Towards a better understanding of 'bottlenecks' in PC building

In PC Building enthusiast communities, the subject of PC builds being 'bottlenecked' comes up quite frequently. It comes up a lot around the time new hardware -- like the recent RTX 3000 series -- is introduced. Or when (often novice) users are looking for build advice (e.g. 'Will a Ryzen 5 3600 bottleneck my build?').

I recently made a long post about how the concept of 'bottleneck' is frequently misused, poorly understood by and generally unhelpful for PC builders on r/buildapc. The original post generated over 1,000 karma and lots of polarizing discussion and criticism. It's still available here and is worth a read if you're interested in the topic, though for reasons that are not clear to me it was removed by the moderators.

Since the original post, I've considered some of the criticisms and have been chewing on the issues more. This post represents me working through some of this in written form.

How is the term 'bottleneck' generally understood?

When people use this term, what do they mean by it, both in general and specifically in the context of PC building? Among inexperienced PC builders, there is a lot confusion and fuzziness, but that is to be expected whenever novices engage with a concept in a new domain. I'll come back to this issue later, but to start I want to focus on the more sophisticated understanding of the term that more experienced folks, often with engineering backgrounds, have.

The sense most experienced folks understand the term, which is nicely encapsulated by this Quora answer, I'm going to call the Informal Engineering Version of the concept. I define it as follows:
bottleneck (Informal Engineering Version): noun. A component of a system, the performance limitations of which limit the overall performance of the system.

This definition struck me as fine in an informal sense, but left me feeling vaguely uneasy. It took me a lot of thinking to get at precisely why, but I think it amounts to two defects of the definition: a major and a minor one.

What's the alternative?

To get at the major one, it helps to ask what the alternative would be to a system where the performance is limited by the performance of a single component. I think there are two.

The first would be a system where performance was unlimited. But this is, of course, impossible. Every system, just like every thing, has some specific nature, including specific limitations. In the realm of PC building, there is obviously no such thing as a PC of unlimited performance.

The second alternative would be that the system performance is limited by the performance of more than one component. There's a sense in which this could be true: in PC building it would be the theoretical 'perfectly balanced system.' And targeting a balanced build is good advice insofar as it goes. For instance, for a given build budget, and all other things being equal, it makes sense to spend it in a 'balanced' way, rather than under-investing in certain components and over-investing in others.

The 'every system has a bottleneck' school

But in practice, it's not possible to achieve the Platonic ideal of a balanced build. In PC builds, and indeed in most systems, there will almost always be some single factor that imposes an upper limit on system performance. The proponents of the Informal Engineering concept of 'bottleneck' in the PC building community often espouse this view, with their mantra being 'Your system will always have a bottleneck.' For instance, they'll say, if your weak GPU is currently gating your build, as soon as you upgrade it, your previously second-weakest component (let's say your monitor with its low refresh rate) will become the new bottleneck.

It's worth examining what this actually amounts to. Because all systems, practically speaking, have some single weakest component, all systems are perpetually bottlenecked. But all this means is that all systems have some limitation on their performance, which is to say that all systems have some definite identity. It reduces the concept of 'bottleneck' to meaning nothing more than a statement of the law of identity; that a system can do what it does and can't do what it can't. Am I 'bottlenecked' in my inability to fly because I don't have wings? Or in my inability to still have my cake after I eat it because the universe doesn't allow for that?

This is why I say this conception of bottleneck is useless. Every system is equally 'bottlenecked.' Your brand new Core i9 10000k series, 256 GB RAM, RTX 3090 and 360hz display system is bottlenecked because it can only output as many FPS as its weakest component (whichever that is) allows it to.

The same system with, e.g. a GTX 700 series card instead would be less performant -- the neck of the bottle at the GPU would be narrower, so to speak. Proponents of the Informal Engineering definition would say that the latter system is more bottlenecked than the former. But I think this view is off. It's like saying that a corpse is 'more dead' than a living person. No it isn't. The living person isn't dead at all.

This wrong conception is common among PC building novices and is reinforced by veteran builders of the 'every system has a bottleneck' variety. Many of the new builder questions on, e.g., PC building Reddit communities ask things like 'Will this graphics card be a bottleneck in my build?' The invariable response from this is crowd is, of course, that every system has a bottleneck. Maybe it's the graphics card right now. But if the graphics card were upgraded, the system would be bottlenecked by some other component. What is the novice builder supposed to do with this perspective? Throw up his hands and resign himself to a system that will forever be hopelessly bottlenecked in one way or another, his performance aspirations always frustrated?

No, not every system is bottlenecked

The way out of this dilemma is to identify that something is a bottleneck only if it, in fact, imposes a significant limitation on the overall performance of the system. This leads to what I'll call the Interim Engineering Version of the concept, which is close to the first definition on the 'bottleneck' Wikipedia page:

bottleneck (Interim Engineering Version): noun. a component of a system, the performance limitations of which impose a significant limit on the overall performance of the system.

On this improved conception, whether something is a bottleneck or not hinges on whether the performance limitation is significant. And what counts as significant is highly dependent on the context of use. If a given component's limitations don't impose a significant limitation on overall system performance in the context in question, than that component is not a bottleneck, even if it happens to be the single component that is limiting overall system performance. Moreover, if the system's overall performance is adequate to its purpose, then the system as a whole is not bottlenecked.

In PC gaming terms, within the context of playing CS Go at 1080p (i.e. 1920 by 1080, 60hz), the following systems are equally not bottlnecked:

  1. Core i9 10900k, RTX 3090, 360hz monitor
  2. Core i9 10900k, GTX 1060, 360hz monitor
  3. Core i9 10900k, GTX 3090, 60hz monitor
  4. Core i5 6500, GTX 1070, 60hz monitor
All of these systems will deliver an acceptable play experience of at least 60fps at the target resolution and high graphics settings. Systems 1 and 4 represent 'balanced' builds. (1) is vastly more performant than (4), but both are not bottlenecked with respect to this task, and neither contains a single component that is markedly weaker than the others. Systems 2 and 3 each have an obvious component that is limiting the overall system performance (the GPU and monitor, respectively), but both will still be adequate to the task. Their limitations are not significant in this context.

In PC building, there is no value, in and of itself, in achieving the Platonic ideal of a system where every component fully saturates the next component downstream at every step of the chain. It doesn't necessarily follow that the 'unbottlenecked' system will outperform a bottlenecked one. System 2 from the list above will offer a better experience than the perfectly balanced, Platonic ideal of a system from say, 10 years ago, in spite of the GPU being a 'bottleneck' because all of the components are better than the best components you could purchase 10 years ago, including the 'bottlenecking' GPU.

Component x does not bottleneck component y

Another subtlety here is that while an individual component may 'be a bottleneck' in a given system, 'being bottlenecked' (or not) is a property of the entire system, not of a component. In other words, it is fine, in principle, to say 'My CPU is a bottleneck' or 'My CPU is bottlenecking my system.' However, the common PC building forum question (and responses to it) of, e.g., 'Will this CPU bottleneck this GPU?' is invalid.

As noted above, it will always be the case, in practice, that some component of a system is not fully saturated by another component. The fact alone that your CPU is not capable of outputting as many FPS as your GPU is capable of processing doesn't tell us anything of practical utility in evaluating your build or whether or not it's 'bottlenecked.' That cannot be assessed without reference to the overall performance of the system against its intended purpose. Even if the CPU is capable of saturating only 25% of the GPU's maximum capacity, if your goal is to play Control at 8K / 60 FPS, then as long as the CPU can consistently deliver 60 FPS to the GPU, the system is not bottlenecked.

More deeply, even when one component really is bottlenecking the overall system, that's the perspective to take on it. By analogy, if your shoes are too small, it's correct to say that they, e.g., limit your ability to walk. It would be weird, on the other hand, to say they limit your feet's ability to walk. Walking is an activity of a person, not of feet, even though it involves feet. Likewise, performance (or lack thereof) against a purpose is an attribute of a system, not of any one of the system's components.

This usage is, by the way, perfectly consistent with how the term is used in practice in engineering contexts. No one regards a system as bottlenecked if its overall performance is adequate to the needs (or anticipated needs) it is meant to serve. When a system is inadequate, it is often good methodology to search for bottlenecks and to fix any ones that are identified. And it would obviously be poor methodology to, e.g., increase the diameter of the base of the bottle while ignoring the diameter of the neck. But once performance is rendered adequate (or adequate to address expected future needs), the hunt usually stops. Engineers generally don't waste time quixotically tilting at 'bottleneck' windmills if the overall performance of the system is acceptable to current and anticipated future needs.

As a side note, this is where the term 'bottleneck' as the source of the analogy is unfortunate, because in actual bottles, the narrowness of the neck is a feature not a bug. It improves the performance of the overall system relative to its purposes. A bottle without a neck is a jar. Bottles offers numerous advantages over jars for the applications we use bottles for. It's cheaper to seal, for example, because the sealing component (e.g. a cork or metal cap) can be smaller, and, historically, cork and metal were expensive materials. Most crucially: the fact that the narrow neck reduces the flow rate makes it easier to pour out of the bottle in a standardized and controlled way.

Other kinds of performance limitations

The minor flaw of the standard definition of bottleneck is the tendency to make it overly broad. Even the Interim Version of the definition suffers from this problem. It is important to recognize that bottlenecks are not the only type of performance-limiting condition of a system, or even of a PC build.

Because PCs -- more than many other kinds of systems -- are inherently modular, with different modules contributing to performance in different ways, there is a tendency to regard any sub-optimally performing component as a bottleneck. But consider some examples of PC build issues:
  1. A CPU that is incapable of delivering enough FPS to the GPU for a given game, leading to perceptible hitching and slow down;
  2. A GPU that is incapable of driving enough frames to saturate a monitor's refresh rate for a given game;
  3. A power supply that is not capable of supplying enough wattage for a given build;
  4. A GPU that does not support realtime ray tracing, meaning that feature is not available for a given game that supports it;
  5. A power supply that is capable of supplying enough wattage for a given build but is failing, delivering inconsistent power output;
  6. A front panel power button with a faulty contact, meaning the PC will not boot when the button is pressed.
Each one of these examples involves some specific component of a PC build not performing as expected (or at all), where that lack of performance impacts the performance of the entire system. I take (6) to be an unambiguous example of something that is not a bottleneck, and I don't expect many people would regard it as one. It's an issue that impacts performance (indeed, this system won't perform at all) and it's isolated to one component, but it isn't a bottleneck. If you think about the corrective pathway, it doesn't involve increasing the capacity of the limiting component: it just involves fixing or replacing it. The issue also doesn't manifest to the user as any sort of delay or slow down in terms of anything 'moving through' the system. To call the faulty power button a bottleneck would be, I think, to torture the term 'bottleneck.'

I consider (5) an exactly parallel example to (6). In this case, the power supply has the capacity to power the system, it's just faulty. This would likely manifest to the user as system instability (e.g. random reboots). Likewise, the corrective pathway doesn't involve increasing the capacity of the power supply (e.g. moving from a 500 to a 600 watt PSU), it just involves replacing the faulty PSU with a working one. Interestingly, however, in the comment thread on the original post, a redditor asserted that this example was not only a bottleneck but an 'obvious' one. Even more interestingly, another user commented on the same thread that no one could possibly consider this to be an example of a bottleneck and that I was criticizing a straw man. That's doubly amusing because the 'straw man' was put forth as an actual argument in the thread he was responding to. Again, I think this is a torturous use of the term bottleneck. A failing or defective component is an example of a system performance issue distinct from a bottleneck.

Likewise, I don't think it's plausible to argue that (4) is a bottleneck. An inability to do realtime ray tracing may indeed result in a sub-optimal play experience, but it seems misguided to say the GPU's lack of ray tracing support 'bottlenecks' the system's performance. Lack of feature support is a distinct type of system limitation, not a type of bottleneck.

(3) is the first example where it becomes plausible to call something a bottleneck, and indeed the first place where I think most people would start applying the term (e.g. 'The PSU's inadequate wattage is bottlenecking the system.') I certainly don't think this is a ridiculous position to take, but I'm going to argue that it isn't a bottleneck. Again, there's no question that the PSU's inadequate wattage is limiting system performance. There's also no question that the performance limitation is one related to capacity: if the PSU could deliver more watts, the performance limitation would be removed. However, as in (5), the limitation would manifest as system instability.

On the literal bottleneck analogy, I think this is more like, say, the glass of the bottle being slightly porous and causing leaks than it is to the neck of the bottle being too narrow to provide adequate flow. Though the porousness of the bottle and the maximum wattage of the PSU are both capacities of their respective components that limit performance of the overall systems, they are capacity limitations of a different kind than those that can lead to bottlenecks. Stated another way: not (even) every limitation in the capacity of  a component that significantly impacts the performance of the system overall is a bottleneck.

(2) Is another example of something that would traditionally be referred to as a bottleneck, and I would go as far as to say it is one that most PC builders would argue is an unambiguous one. I don't think it's quite so unambiguous. The first thing that gives me pause is that we should observe that this condition (GPU delivering less FPS than the monitor's refresh rate) is incredibly common, even among very high-end gaming systems. In fact, it is a potentially desirable state of a high-end gaming system. A builder with a large budget, for example, might purchase the highest refresh rate monitor available (e.g. 360hz) knowing full well that his (also very high-end) GPU is not capable of fully saturating it all the time on all the titles he plays. And it would be perfectly rational for him to do so. Given that the 360hz monitor is (at the time of this writing) the highest-refresh-rate device he can purchase, it makes sense to have the headroom at his disposal. But to say the GPU is bottlenecking if it isn't constantly driving 360 FPS on every single title would be to drop a ton of context about how games work: notably that FPS are variable and that performance will differ from game-to-game and moment-to-moment.

As a side note, another important element here is the market context. At the time of this writing, the most powerful consumer GPU yet announced is an RTX 3090. Though independent benchmarks have not been released, it is clear that even that card is not capable of fully saturating a 360hz display at every reasonable consumer resolution and combination of game settings. So if someone is going to assert that a 3090 is a 'bottleneck' in a given situation, the obvious response is: in comparison to what? That is: in comparison to what possible alternative that would alleviate the 'bottleneck?' As of now, the universe (more specifically the portions of it controlled by Nvidia and AMD) does not provide one. As noted earlier, this is like considering the nature of reality a 'bottleneck' to having your cake and eating it, too.

More deeply, the situation has to be evaluated with reference to the whether the performance impact on the system overall is significant with reference to its intended purpose. The fact is that most people, can't perceive the difference between 120hz and 240hz, let alone 240hz and 360hz. This includes even most gamers, who we would expect to better appreciate the difference than the general population. Perhaps some elite esports athlete would benefit from consistently driving 360hz as opposed to achieving a variable framerate between, say, 250 and 310hz, but for the average gamer, the performance difference is not significant. (I realize there are other reasons why it is desirable for a GPU to drive a higher framerate than a display can refresh at, but I'm ignoring them for the purposes of this example).

Example (1) is, in my opinion, a clear an uncontroversial example of a bottleneck, properly understood. Here, a component (the CPU) is limited in a way that significantly impacts the performance of the entire system. This impact is significant because it is clearly perceptible by the player in the form of an undesirable consequence: noticeable lag and stuttering.

Like example (3), the limitation of the CPU is one of capacity. But it is a specific type of capacity limitation: one in which the capacity limitation has to do with (by analogy) flow through the system. The rate at which the CPU can deliver frames to the GPU causes the GPU to have to wait long enough that the delay results in a play experience that is not smooth. In other words, bottlenecks involve a limit in the throughput of a component limiting the performance of the entire system. Finally, this yields the proper definition of bottleneck, which I'll call the the Rigorous Engineering Version of the concept. It is the one articulated in the second paragraph of the Wikipedia entry:

bottleneck (Rigorous Engineering Version): noun. A component of a system, the throughput limitations of which impose a significant limit on the overall performance of the system.

'Bottleneck,' properly understood in this way and restricted to this usage is a valid concept and is applicable to certain types of PC build situations, as in (1).

So much for the theoretical discussion. In a future post, I'll take on the practical implications for PC building and PC building advice and, in particular, the questions PC builders should be asking (and answering) instead of the various flavors of 'Will component x bottleneck my system?'

Friday, May 1, 2020

COVID-19: The Story So Far


From an overlong Facebook post.

The story so far:

For years, experts had been warning us to prepare for a pandemic respitory disease. We didn’t. Government in particular did not adequately do so, nor did the healthcare industry, since there was no economic incentive for them to do so because healthcare pricing in this country is controlled by the federal government, particularly in the hospital sector where the weight of such a pandemic would fall, which did not incentivize preparedness.

Then a pandemic hit and we squandered many chances to respond promptly (to the extent we could have being unprepared) because the present occupants of the White House and the state houses didn’t heed the early indicators. The former, in particular, attempted his typical routine of trying to create an alternate reality in which the virus went away on its own. The virus didn’t get the memo.

The inadequacy of the preparedness and initial response resulted in tens of thousands of avoidable deaths.

When governments finally started responding, the initial step was to initiate lockdowns of the population to slow the spread of the virus. We were told this was to ‘flatten the curve’: meaning to avoid a surge in people getting the virus all at once if it spread uncontrolled that would exceed the surge capacity of the hospital system. If that surge capacity gets overwhelmed at any point, we were told, more people than necessary will die. It will not reduce the overall number of people infected or needing hospitalization, though: it just spaces them out over time. The area under the curve remains the same (aside from the excess deaths due to overwhelming hospital capacity), it’s just flatter.

We were told this step — and the lives jeopardized and reduced in quality as a result of it — were necessary sacrifices. But this phase was only temporary as we built testing and treatment capacity. Testing capacity lets us more selectively isolate people with the virus and those who may have come in contact with them, allowing healthy people to resume their normal lives. And increasing treatment capacity lets us treat more people at once, reducing the need to flatten the curve.

Now, almost two months later, we’ve made some progress. As a country, we’ve gone from doing only a few thousand tests a day to over 200,000. It’s harder to get numbers about increased hospital capacity, though the number of people in ICUs has come down significantly from the peak a few weeks ago (over 15,000 to around 9,000 on a given day), suggesting the curve flattening is working but also that, in many but by no means all places, there is not, at present, a need for as much curve flattening because excess hospital capacity exists. And though 200,000 tests per day is impressive, it’s still an order of magnitude short of what the experts say we need.

And still 95%+ of the population remains under lockdown. Neither state nor federal government have articulated sufficiently detailed plans for getting the treatment or testing capacity we need to end them.

As a result, the de facto plan is to keep the entire population under indefinite house arrest (without any actual crime, trial or indeed any legal basis) as a form of preemptively rationing access to (allegedly) scarce healthcare resources. We are now told this will continue until the rate of infections or hospitalizations declines significantly, which was never something that curve flattening was supposed to achieve. And the de facto plan for dealing with the massive economic consequences of this is socialism: both rationing access to other necessary resources to deal with disruptions to the supply chain the economic devastation is causing, and engaging in massive, hastily assembled wealth redistribution plans, ignoring the fact that if production isn’t occurring than the wealth to be redistributed isn’t being created.

And, perhaps most shockingly, almost all ‘respectable people’ are willing to tolerate it. They are fine with the government pointing a gun at them and their neighbors and saying ‘Don’t leave your house. Don’t run your business. Don’t have your kids learn. Don’t pursue any value other than the ones inside your four walls. Unless you’re a healthcare or ‘essential’ worker, in which case you are expected to put yourself at risk for the Common Good. Do this indefinitely because we’re in charge and, really, this is all we can do. We can point guns, tell people what not to do and shuffle wealth other people created around. We can’t adequately increase testing capacity. We can’t even have an actual plan or strategy for increasing and managing the treatment capacity we have. We certainly can’t invent a vaccine. So stay inside, because we have calculated (correctly) that you, the voting public, will tolerate lives being destroyed, including your own, if it happens slowly enough, in private, and in the name of the common good; but not if it happens rapidly and all at once with people hooked up to ventilators.’

Apparently, they are absolutely right in that calculation. Most people apparently don’t care whether they live. Not in a meaningful sense. If they’re motivated at all, it’s to avoid death. But living is not avoiding death. They may succeed in that. But it isn’t living. When it comes to actual living, we’ve done more in the last two months to dig our own graves and climb into them than any other generation of Americans.