Hacker News Reader

Comment by scrollaway | Hacker News Reader

If you have enough resources to lazily simulate the entire observed universe, you probably have enough resources to consistently simulate the entire observable universe.

I haven't kept up with the latest out-of-universe hardware upgrades, so I could be talking out of my ass here.

With that said, why would you simulate something so ridiculously large and detailed if you only had the resources to run a small portion of it at a time? It's like buying an 8K 3D monitor and hoping your 3DFx Voodoo 2 will do the trick.

View on HN

You might do this if you didn't have the computational power to simulate the thing you wanted in real time. Games are hard locked to require the computation to be performed within the frame time of the gameplay, but much more detailed and complex computations are done all the time to pregenerate an animated movie or video that can then be "played" in real time. The generation of the content often takes many times as long as the content actually is, but the purpose of doing it this way is to generate more detail per frame than you would be able to compute in the time between each frame when played at the ideal speed.

What is "real time", though? Time is relative within the universe itself, what hope is there that it even exists outside of it?

Using crude current metaphors: If I build a game, the concept of time within that game is, essentially, each tick of the game (a frame, for example, or a server-side tick). You can even have portions of the game world tick faster or slower relative to others.

But those ticks mean nothing outside of the game. Yes, in "real time" the ticks are constant... but I can pause the game at any point, it stops progressing. I can step it one tick forward, and for the game one tick has passed, but for me, any amount of time can pass.

In other words, there's no relation between time inside and outside the simulation, because it's a simulation.

Sorry if I was unclear, I didn't mean to imply a link between "real time" in the game/simulation and the real world, because you are completely correct in noting that there is no specific relation between game time (ticks) and "real" time (seconds or w/e units you want).

The link in the "time" that I am describing is one where the game graphics are rendered in 60 frames per second. If the computation cannot be completed within 1/60th of a second, the frame is delayed because it took too long to render.

My comment was largely in response to your assertion

"If you have enough resources to lazily simulate the entire observed universe, you probably have enough resources to consistently simulate the entire observable universe."

First, assuming that it requires less resources to "lazily" simulate something than to fully simulate it, then no, I do not believe that just because you can do the first means that you can 'probably' do the second. If you had enough resources for the first and not the second, but the first was good enough, why not do the first?

In response to: "With that said, why would you simulate something so ridiculously large and detailed if you only had the resources to run a small portion of it at a time? It's like buying an 8K 3D monitor and hoping your 3DFx Voodoo 2 will do the trick."

The reference to animation was largely in response to this, because that is exactly what the purpose of animation is. They have enough resources to render the animation in whatever length of time it takes to render, but they can't do it quickly enough to just render it frame by frame for the viewer.

I just realized I wanted to address this additional point:

> If you had enough resources for the first and not the second, but the first was good enough, why not do the first?

Why would you build something that is so immensely large, if you can only simulate a portion of it at a time? This hypothesis suggests that you would have to make the universe at least this large, or that lazy simulation is simpler.

Again thinking in terms of occam's razor and path of least resistance. It seems silly to make the unprovable theory even more complex and even harder to prove.

With that said I like Razengan's take on it; that is, c would be the speed at which the simulation computes new results (it also assumes the simulation isn't paused during computation).

Remember, even in simulation theory, there's nothing that suggests we humans are the intended product or object of observation; just like an ant farm that happens to be somewhere in some house in GTA5 isn't specifically the point of GTA5. So I wouldn't conflate "lazy loading" with "there are humans in this tiny corner of space, so we only need to simulate this tiny corner of space, and that makes a big difference in terms of computing power".

Re: lazy simulation

Would the fact that our “observable universe” is limited by the speed of light and time since “creation”, be a kind of a “lazy” simulation?

i.e. the “servers” that process us would never need to know about anything in the region that will never interact with us.

Ah, yes, I see where you're coming from.

My take on it is that it just fails occam's razor. As in, it turns the theory "The universe is a simulation", into "The universe is a simulation, and the simulation is imperfect and lazy-loaded". It's adding even more requirements to an unprovable theory.

Essentially, it turns "God exists" into "God exists, and he has a beard".

Ahhhh this makes more sense with your previous objections and I wasn't understanding it as well before. I always took little tidbits of the scenario that pointed to "lazy-eval" to be indicative of it being more likely to be a simulation because lazy eval is popular among programmers. Obviously when I write it out like that I can see where I lean on the same logic I argue against in other scenarios which is that we can't make any assumptions about intentions/motivations/etc. of the simulation creators, and the assertion that they would have similar programming paradigms is a pretty big assertion for sure.

Reply on news.ycombinator.com