Code center > Darwinbots3
DB3 progress and networking
Numsgil:
--- Quote from: Peter on March 31, 2015, 12:27:57 PM ---
--- Quote from: Numsgil on March 27, 2015, 01:16:39 PM ---(For the record, I doubt the core engine for Darwinbots will be deterministic just because I haven't put any effort towards that.)
--- End quote ---
Why wouldn't it be deterministic?
--- End quote ---
Determinism is one of those hard things that doesn't just happen. There's no such thing as mostly deterministic. If there's even one thing that's not bit-for-bit identical across two different machines, the whole thing is spoiled. I'm not doing anything that shouldn't be deterministic in principle, I'm just not putting any effort in to it, which means almost certainly there's going to be something that is going to differ across machine architectures (maybe there's an acos call somewhere. Those trig functions are notorious). Not to say it couldn't be deterministic, but it's not a priority.
Peter:
Gotcha, I forgot about the floating points of hell. :blush:
spike43884:
Hence why a central machine running one sim with visual accessible by the users, with then bots input via a one way teleporter would be good.
All ports being open (or most) is simply to relieve "port strain"
Its rare that port strain happens, but its best to avoid it. Its basically a port being overloaded, plus it increases compatibility (Everyone loves compatibility <3)
The floating points of hell wont be a problem with the central machine running it.
Numsgil:
--- Quote from: spike43884 on April 01, 2015, 11:35:43 AM ---Hence why a central machine running one sim with visual accessible by the users, with then bots input via a one way teleporter would be good.
--- End quote ---
Hmm, you know I wonder if you have some misconceptions that are driving how you see the program. Do you think DB2 runs real time (30FPS+) for everyone but you, and you're stuck with .1 cyc/sec sims for some reason? Because that's not true. I was running simulations circa 2005 with a P4. My phone has at least 4 times the horsepower I did back then. The simulation just doesn't scale well. That means as you double the size of the sim you need something like 4 times more resources. Or worse, since it's not multithreaded and you can't really find single threaded performance gains anymore in hardware.
DB3 will be multithreaded, but what that gives I'm going to suck up with an even more aggressive simulation. You could run it on some $10k "supercomputer" and a simulation might only run twice as fast as a dinky $500 machine. If we want the sorts of bot-cycles that make a good ALife sim we're going to need to think wide (clusters) instead of tall (servers).
--- Quote ---All ports being open (or most) is simply to relieve "port strain"
Its rare that port strain happens, but its best to avoid it. Its basically a port being overloaded, plus it increases compatibility (Everyone loves compatibility <3)
The floating points of hell wont be a problem with the central machine running it.
--- End quote ---
Hmm, I'm calling BS on this. That's not really a thing. Linux can handle tens of thousands of connections from a single source on a single port. Most webservers for popular websites have something like a "routing" server that accepts all the incoming http connections on port 80 for the entire world (or at least a region) and forwards them on to actual servers to send pages.
I don't understand why ports are such a hobby horse for you. Is there something I'm missing?
spike43884:
--- Quote from: Numsgil on April 01, 2015, 12:24:43 PM ---
--- Quote from: spike43884 on April 01, 2015, 11:35:43 AM ---Hence why a central machine running one sim with visual accessible by the users, with then bots input via a one way teleporter would be good.
--- End quote ---
Hmm, you know I wonder if you have some misconceptions that are driving how you see the program. Do you think DB2 runs real time (30FPS+) for everyone but you, and you're stuck with .1 cyc/sec sims for some reason? Because that's not true. I was running simulations circa 2005 with a P4. My phone has at least 4 times the horsepower I did back then. The simulation just doesn't scale well. That means as you double the size of the sim you need something like 4 times more resources. Or worse, since it's not multithreaded and you can't really find single threaded performance gains anymore in hardware.
DB3 will be multithreaded, but what that gives I'm going to suck up with an even more aggressive simulation. You could run it on some $10k "supercomputer" and a simulation might only run twice as fast as a dinky $500 machine. If we want the sorts of bot-cycles that make a good ALife sim we're going to need to think wide (clusters) instead of tall (servers).
--- End quote ---
I don't have a misconception about this such things like the change in cycles per second. The thing is, we need a way around "floating points of hell" and the differentiating between the computers. In real life when a cell moves an inch, time doesn't slow down 10 times for it, then another inch speed up 5 times. What about thinking wide and tall. Running the simulation on the central machine giving visual feedback, but using the participating terminals (or personal computers) to calculate the bots. Remember, the simulation is split into 3 segments primarily, the area of the simulation, the bots then finally the projectiles etc. If you spread the load of the bots across the computer terminals then it can calculate the DNA triggers, then thats returned to the server which then treats the simulations (and maybe projectiles) then once a projectile has hit a bot it lets the computer terminals handle it as a 'bot event'. Thus because the actual simulation is on one centralised machine it doesn't suffer from differentiation, but the load is spread by the terminals to calculate the bots. Tall and wide. Then a simple little visual output is given to every terminal.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version