6 ms·

This is a really beautiful way to see something we take for granted all the time. The fact that computers can do all this in the blink of an eye (sans network s

by demarq 3y ago

This is a really beautiful way to see something we take for granted all the time. The fact that computers can do all this in the blink of an eye (sans network speed) is just mind blowing.

IanCal 3y ago
One kinda related thing I find constantly amazing is that your processor running at x GHz will have had several more ticks in the time it takes the photons to go from your screen to your eyes. (Light travels at about 30cm/1ft per nanosecond)
- xpil 3y ago
  Not to mention eons required for our optical organics to start registering the photons!
  - IanCal 3y ago
    The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives. Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are. (36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)
    - SamBankmanFried 3y ago
      And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen? Never forget what they took from you.
      - tialaramex 3y ago
        Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways. If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ... And that's a lot of round trips whereas they could have done: Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ... Which is far fewer round trips.
    - Arrath 3y ago
      > The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. And you missed your window to get into BIOS, you need to reboot and try again. /s
      - ByThyGrace 3y ago
        I'm fairly sure this is more than one somebody's recurring nightmare.
        lazide 3y ago
        No lie, my eye twitched.
- p-e-w 3y ago
  My understanding is that this puts a fundamental limit on how fast CPU clocks can be. If the CPU die has a diameter of 3 centimeters, and the clock speed is a hypothetical 20 GHz, light (and electrical signals) can traverse at most half the size of the die in the course of one clock cycle. It's hard to imagine how such a CPU could work, since components at opposite sides of the die cannot communicate within a cycle.
  - HALtheWise 3y ago
    Definitely nitpicking here, but for a modern pipelined CPU there's already lots of components of the die that aren't designed to be able to exchange data within a single clock. I don't see what would be fundamentally different about laying out a CPU die such that operations that need to happen in the same clock are physically nearby, and it seems like it would (at worst) have similar properties to multi-socket and pipelined CPUs today where cache coherency operations and branch mispredictions have multi-cycle penalties associated with them. I'm pretty sure that multi-socket CPUs can't talk in less than one clock cycle anyway.
    - laci37 3y ago
      I only had an intro course in CPU architecture, but AFAIK pipelining depends on parts of the pipeline running on the same clock. I'd say CPU manufacturers already sidestepped this limitation by using multicore dies.
      - foobiekr 3y ago
        No, it doesn’t. Putting aside that there is an entire field of clockless designs, asynchronous logic, free-running clocks, etc. You should think of this as “when the cpu is processing an instruction, what does it need to track to dispatch and retire it?” Designing to a click tick is one version and kind of where things were in the 1970s. It’s an educational model.
      - Dylan16807 3y ago
        That just means you can't have a single simple clock source fan out in a simple way across the entire chip, but that kind of design performs badly anyway. There are lots of ways to have multiple clock sources kept in sync or to alter the clock's phase to compensate for distance, so you can keep the entire CPU synchronized even if crossing it takes multiple clock cycles.
- _x11l 3y ago
  In game development we can abuse this fact with things like client-side prediction in authoritative online environs. The server plays along with the client in a no-graphics mode and plays the inputs from the client, validates said moves on the server, and if all goes well sends back the response allowing for client action all before the blink of an eye. In the case of an invalid move, the server yanks the client back to the state preceeding. Pair that with some lag compensation and you've got yourself a stew.
  - csomar 3y ago
    Do you have more detailed links about that?
    - eXpl0it3r 3y ago
      There's a great article by Valve: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
    - goolz 3y ago
      The Valve paper posted is amazing but huge shoutout to Photon (not affiliated) as their docs break it down really well. Their Bolt and now Fusion offerings are a boon! https://doc.photonengine.com/fusion/current/tutorials/host-mode-basics/3-prediction https://doc.photonengine.com/fusion/current/tutorials/host-m...
  - swyx 3y ago
    what kind of latency budget do you have to do all that? even at like 15fps i cant imagine that you can provide a non janky experience when this “server yanks client back to valid state” move is done. i mean obviously you guys have figured it out, just the math doesnt quite make sense to someone like me not in gaming
    - qingdao99 3y ago
      Not an expert but: The lag compensation is, more intuitively, just allowing the client to move on its own without needing server verification yet. The server maintains the authoritative game state, but (assuming no cheating is going on) the clients are able to move as they think they will. In the background, the client is actually sending its inputs to the server, and they technically haven't happened until the server verifies them (however many milliseconds later), but we allow the client to move on its own regardless. The yanking back only happens if the client's new state (position etc.) don't match the server's state.
- runlaszlorun 3y ago
  Was going to say the same. My mind was fairly blown when I realized that light only travels approx 4 inches in a clock cycle. Then again, every time my computer pauses for multiple seconds, me knowing how many billions of clocks cycles I’m waiting for doesn’t help my already challenged patience… haha.
ByThyGrace 3y ago
And then you factor in the occurrence of different systems running at different clock speeds having to interchange across several interfaces in a way that the entire communication somehow stays afloat and even produces feedback.

by demarq 3y ago

This is a really beautiful way to see something we take for granted all the time. The fact that computers can do all this in the blink of an eye (sans network speed) is just mind blowing.

IanCal 3y ago

One kinda related thing I find constantly amazing is that your processor running at x GHz will have had several more ticks in the time it takes the photons to go from your screen to your eyes. (Light travels at about 30cm/1ft per nanosecond)

xpil 3y ago
Not to mention eons required for our optical organics to start registering the photons!
- IanCal 3y ago
  The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives. Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are. (36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)
  - SamBankmanFried 3y ago
    And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen? Never forget what they took from you.
    - tialaramex 3y ago
      Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways. If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ... And that's a lot of round trips whereas they could have done: Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ... Which is far fewer round trips.
  - Arrath 3y ago
    > The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over. And you missed your window to get into BIOS, you need to reboot and try again. /s
    - ByThyGrace 3y ago
      I'm fairly sure this is more than one somebody's recurring nightmare.
      - lazide 3y ago
        No lie, my eye twitched.
p-e-w 3y ago
My understanding is that this puts a fundamental limit on how fast CPU clocks can be. If the CPU die has a diameter of 3 centimeters, and the clock speed is a hypothetical 20 GHz, light (and electrical signals) can traverse at most half the size of the die in the course of one clock cycle. It's hard to imagine how such a CPU could work, since components at opposite sides of the die cannot communicate within a cycle.
- HALtheWise 3y ago
  Definitely nitpicking here, but for a modern pipelined CPU there's already lots of components of the die that aren't designed to be able to exchange data within a single clock. I don't see what would be fundamentally different about laying out a CPU die such that operations that need to happen in the same clock are physically nearby, and it seems like it would (at worst) have similar properties to multi-socket and pipelined CPUs today where cache coherency operations and branch mispredictions have multi-cycle penalties associated with them. I'm pretty sure that multi-socket CPUs can't talk in less than one clock cycle anyway.
  - laci37 3y ago
    I only had an intro course in CPU architecture, but AFAIK pipelining depends on parts of the pipeline running on the same clock. I'd say CPU manufacturers already sidestepped this limitation by using multicore dies.
    - foobiekr 3y ago
      No, it doesn’t. Putting aside that there is an entire field of clockless designs, asynchronous logic, free-running clocks, etc. You should think of this as “when the cpu is processing an instruction, what does it need to track to dispatch and retire it?” Designing to a click tick is one version and kind of where things were in the 1970s. It’s an educational model.
    - Dylan16807 3y ago
      That just means you can't have a single simple clock source fan out in a simple way across the entire chip, but that kind of design performs badly anyway. There are lots of ways to have multiple clock sources kept in sync or to alter the clock's phase to compensate for distance, so you can keep the entire CPU synchronized even if crossing it takes multiple clock cycles.
_x11l 3y ago
In game development we can abuse this fact with things like client-side prediction in authoritative online environs. The server plays along with the client in a no-graphics mode and plays the inputs from the client, validates said moves on the server, and if all goes well sends back the response allowing for client action all before the blink of an eye. In the case of an invalid move, the server yanks the client back to the state preceeding. Pair that with some lag compensation and you've got yourself a stew.
- csomar 3y ago
  Do you have more detailed links about that?
  - eXpl0it3r 3y ago
    There's a great article by Valve: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
  - goolz 3y ago
    The Valve paper posted is amazing but huge shoutout to Photon (not affiliated) as their docs break it down really well. Their Bolt and now Fusion offerings are a boon! https://doc.photonengine.com/fusion/current/tutorials/host-mode-basics/3-prediction https://doc.photonengine.com/fusion/current/tutorials/host-m...
- swyx 3y ago
  what kind of latency budget do you have to do all that? even at like 15fps i cant imagine that you can provide a non janky experience when this “server yanks client back to valid state” move is done. i mean obviously you guys have figured it out, just the math doesnt quite make sense to someone like me not in gaming
  - qingdao99 3y ago
    Not an expert but: The lag compensation is, more intuitively, just allowing the client to move on its own without needing server verification yet. The server maintains the authoritative game state, but (assuming no cheating is going on) the clients are able to move as they think they will. In the background, the client is actually sending its inputs to the server, and they technically haven't happened until the server verifies them (however many milliseconds later), but we allow the client to move on its own regardless. The yanking back only happens if the client's new state (position etc.) don't match the server's state.
runlaszlorun 3y ago
Was going to say the same. My mind was fairly blown when I realized that light only travels approx 4 inches in a clock cycle. Then again, every time my computer pauses for multiple seconds, me knowing how many billions of clocks cycles I’m waiting for doesn’t help my already challenged patience… haha.

ByThyGrace 3y ago

And then you factor in the occurrence of different systems running at different clock speeds having to interchange across several interfaces in a way that the entire communication somehow stays afloat and even produces feedback.