IRC logs for #openttd on OFTC at 2022-04-24
⏴ go to previous day
02:17:08 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:59:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:00:17 *** WormnestAndroid has joined #openttd
03:01:04 *** Cthulhux has quit IRC (Quit: Cthulhux)
04:19:36 *** snail_UES_ has joined #openttd
05:15:13 *** Wuzzy has quit IRC (Quit: Wuzzy)
05:42:04 *** snail_UES_ has quit IRC (Quit: snail_UES_)
07:12:55 *** andythenorth has joined #openttd
08:10:22 *** HerzogDeXtEr has joined #openttd
08:14:05 *** Gustavo6046 has quit IRC (Quit: Goodbye! Leave messages at my XMPP @ gustavo6046@anonym.im or my Discord Gustavo6046#9009 or possibly my Mastodon gustavo6046@fosstodon.org – I don't ch)
08:49:39 *** WormnestAndroid has quit IRC (Remote host closed the connection)
08:53:00 <TrueBrain> I am afraid ... it is time to install Win11 ... I need WSL features, and they don't provide that for Win10
08:53:05 <TrueBrain> not sure if I am going to enjoy this experience ..
09:10:23 <andythenorth> pls livestream it
09:24:19 <Wolf01> The real problem is if your pc is supported... mine isn't so no w11 for me :(
10:14:19 *** andythenorth has quit IRC (Quit: andythenorth)
10:31:34 *** Alkel_U3 has joined #openttd
12:58:07 <TrueBrain> at least it boots :P
13:24:03 *** Cthulhux has joined #openttd
14:01:54 *** virtualrandomnumber has joined #openttd
14:02:05 <TrueBrain> hihi, WSLg actually works :)
14:03:40 *** virtualrandomnumber has quit IRC ()
14:10:04 <TrueBrain> and not sure if it is Windows 11 or my network, but IPv6 only wants to go to 100mbit/s, and stalls my whole computer
14:10:11 <TrueBrain> while on IPv4 it goes up to 1000mbit/s no problems
14:27:02 *** WormnestAndroid has joined #openttd
14:53:55 *** andythenorth has joined #openttd
14:54:50 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:55:13 *** WormnestAndroid has joined #openttd
15:41:51 *** Wormnest has joined #openttd
15:52:25 *** D-HUND is now known as debdog
16:23:16 *** ChanServ sets mode: +v tokai
16:30:23 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
17:10:19 <michi_cc> Quite applicable to how one could multi-thread OTTD, at least with lots of time :)
17:15:55 *** Gustavo6046 has joined #openttd
17:36:25 *** gelignite has joined #openttd
17:38:22 *** gelignite has quit IRC (Read error: Connection reset by peer)
17:38:35 *** gelignite has joined #openttd
17:55:43 <nielsm> yeah the CK3 model he presents around 45 minutes is more or less the thing I proposed a while ago (and stalled work on)
17:57:04 <nielsm> vehicles having a "prepare tick" and an "execute tick", where the prepare is parallel and must not write any visible data, while "execute" is serial but can also fail if the assumptions made are no longer true (like track it wanted to reserve has been reserved by something else)
18:21:13 *** Flygon has quit IRC (Read error: Connection reset by peer)
18:21:17 *** snail_UES_ has joined #openttd
18:22:15 <michi_cc> nielsm: Indeed, and I think as long as you have a similar kind of simulation (entities/agents), it really seems like the logical progression.
18:22:37 <michi_cc> Also, we even did the very first step already: Render thread, state/command thread with a state lock :)
18:23:25 <nielsm> one of the annoying things I remember running into is a bunch of functions that sound like they inspect/return something (pure functions) actually modify various state
18:23:58 <nielsm> in particular some of the landscape functions (those looked up via tile type)
18:32:01 <FLHerne> looks like a Lego train :p
18:33:52 <andythenorth> looks like the one I need to sell :P
18:36:06 *** gelignite has quit IRC (Quit: Stay safe!)
19:06:24 *** gelignite has joined #openttd
19:13:12 <andythenorth> interesting video
19:16:14 <andythenorth> do we slave days to ticks in the same way?
19:16:28 <andythenorth> round about 23-24minutes in the video
19:18:13 <nielsm> one calendar day is 74 ticks
19:19:26 <andythenorth> ok so the 'there is no in-between' does not apply for us
19:19:32 <andythenorth> we have to move vehicles around and stuff meanwhile?
19:19:53 <nielsm> the tick is the only unit of simulation
19:20:39 * andythenorth going to rewind the video a bit :P
19:20:41 <nielsm> and then some ticks are special where more happens, either because the calendar changes (new day, new month, new year) or because the tick number is divisible by 256 (cargo production, various landscape effects)
19:21:25 <andythenorth> oh they have the time as well, missed that
19:21:31 <andythenorth> probably irrelevant
19:24:07 <michi_cc> Yeah, ticks are our simulation unit. There is nothing that can be at a half-tick or so.
19:24:45 <michi_cc> So referring to the talk, our ticks are most closely to the Stellaris example, as many things do not happen every ticks.
19:25:24 <michi_cc> And we also do the "do some parts each tick" that is mention somewhere in the middle to shard longer/more complex subsystems.
19:26:05 <nielsm> the really odd one out is actually the cargo distribution graph calculation
19:26:24 <nielsm> it collects data into a structure, then launches a thread to process the graph
19:26:50 <nielsm> and that thread has an execution deadline some number of ticks later, if it hasn't finished then the tick execution waits for the thread
19:27:07 <michi_cc> Usually a graph processing cycle takes more than one tick, so it has to be done differently. I'm not sure if I should consider this a good or a bad thing, tough.
19:27:12 <nielsm> and then exactly on the deadline tick, that result from that thread is merged into the game state
19:27:50 <nielsm> yes the deadline is something like 10 or many more ticks later, possibly even more
19:30:17 <michi_cc> From a parallelism perspective, the "best" way is of course to do execution by dataflow only. I.e. each and every entity tracks it's dependencies which is then used to fluidly schedule everything.
19:30:35 <michi_cc> The big problem with that is of course that if you try shard/split e.g. the map and track all dependencies, the amount of overhead will be massive compared to the actual computations.
19:30:54 <nielsm> yeah it would require a ton of auxillary storage
19:31:15 <nielsm> like each piece of track would need a queue, something like that
19:31:18 <michi_cc> And scheduling tasks is not free, either.
19:32:20 <nielsm> dependency tracking is a certain way to hell
19:32:56 <glx> except maybe plane and boats, everything is interdependant
19:33:28 <nielsm> planes also need some ordering, when they're on airports
19:34:01 <glx> but they are only affected by other planes
19:34:02 <nielsm> even boats have some weird interactions with all sorts of things
19:34:30 <nielsm> or well, at least depots and docks (meaning other boats)
19:34:47 <michi_cc> You can separate most things (with maybe some tiny behaviour changes) if you adopt a read/write phase model. E.g. for trains do pathfinding for all and just save the result, then resolve all results in order, maybe re-doing now invalid results. (We just have to ignore YAPF cache for this).
19:35:20 <michi_cc> Actually, you could even queue the cache updates for the write phase, with some additional overhead.
19:36:49 <nielsm> it's basically what I do, put an additional "planned actions" struct (nosave) into each vehicle
19:39:25 <glx> hmm I need to check this CARGO_LONG thing mentioned in eints#67, I'm surprised it could work
19:39:37 <andythenorth> what's the overhead in this sort of threaded model? Does state have to be shifted frequently between threads, or do they all do their own book-keeping and occasionally compare?
19:40:14 <andythenorth> my experience of parallel stuff is very limited, basically hadoop distributed across physical machines, and python multiprocessing pool :P
19:41:07 <andythenorth> the python mp pool can massively increase speed, but there's an overhead to starting each python interpreter, and it uses pickle for state, and we think pickle is slow
19:41:16 <michi_cc> I wouldn't think of explicit threads for this. IMHO the most useful model is the task model, where task (that possibly depend on another task) are put into scheduler queues and processed by a thread pool.
19:42:10 <michi_cc> There are very efficient thread pool implementations which mix local and global queues with work stealing to achieve very low synchronization overhead.
19:42:45 <glx> here we can thread read only stuff for planning, and accept to need to replan some stuff if there was a conflict during the real execution
19:43:26 <glx> for most cases the replan should be very rare
19:43:42 <andythenorth> ok so if parallelisation of e.g. some job means it takes n / 4 instead of n
19:43:49 <andythenorth> and 50% of it conflicts and has to be re-run
19:43:52 <andythenorth> we still get n / 2?
19:44:06 *** Gustavo6046 has quit IRC (Quit: Goodbye! Leave messages at my XMPP @ gustavo6046@anonym.im or my Discord Gustavo6046#9009 or possibly my Mastodon gustavo6046@fosstodon.org – I don't ch)
19:44:06 <andythenorth> but the second run would be fast, so probably more like n / 2.5
19:44:31 <glx> but on a busy network it could also mean planning, then redo for lots of vehicles as they want to cross the same junction
19:44:33 <michi_cc> Probably not, because you might not be able the parallelise the reruns again.
19:44:47 <andythenorth> oh they might have to run sequenced to get a firm resolution?
19:45:16 <glx> of course, we still want determinism in the end
19:45:26 <andythenorth> do we even know where the current slow is?
19:46:04 <michi_cc> OTOH, you might be able to avoid most of this by e.g. triggering train pathfinding not at the exact tick where the train would leave the tile but X ticks beforehand. Then you you get X retries "for free" in the next ticks until you must force a resolve.
19:46:56 <andythenorth> I used to do something like that in Flash games :P
19:47:28 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:47:41 <andythenorth> I remember finding some odd results, like why the train window kills FPS
19:47:49 <andythenorth> which I believe is fixed in JGRPP
19:48:09 <andythenorth> multithreading would be much more the cool and interesting project
19:48:11 <glx> some windows are redrawn too often
19:48:16 <michi_cc> Realtive % numbers are off because e.g. most of UpdateWindows is now in a different thread.
19:48:17 <andythenorth> but there might be low-hanging performance fruit still :P
19:48:37 <andythenorth> but it would be nice to stop repeating 'simulations can only be single-threaded because computing'
19:48:51 <michi_cc> And SwitchToMode is just a profiling artifact.
19:49:11 <andythenorth> catenary is greedy in the call graph
19:50:01 <andythenorth> ha, is that call graph with PBS? :)
19:50:05 <andythenorth> there's a meme for that I think now
19:50:37 <michi_cc> This was from a train-heavy savegame what uses NewGRF. Which can be very clearly seen in the large percentage of Train::GetImage in the StateGameLoop. I think we did improve on that though by only getting the image for visible trains.
19:50:37 *** snail_UES_ has quit IRC (Quit: snail_UES_)
19:50:53 <michi_cc> Yes, the savegame has mostly path signals.
19:51:24 <glx> hmm ok {G} is accepted for {CARGO_LONG}, was not expecting that
19:52:42 <michi_cc> And fore the record, this graph is not complete, I set it to hide nodes below some % value, but I don't remember which number that was anymore.
19:53:03 <michi_cc> Might be 1 %, just from the visible nodes :)
20:00:40 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:06:44 <TrueBrain> Was curious if magictrace would work for OpenTTD .. even installed win11 for it but WSL doesn't support Intel pt ... sadddd
20:07:42 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:08:11 *** WormnestAndroid has joined #openttd
20:25:24 *** gelignite has quit IRC (Quit: Stay safe!)
20:41:30 *** Wormnest has joined #openttd
20:44:26 <glx> ok it seems CARGO_SHORT works fine with genders (if enabled in strgen)
20:57:13 *** FLHerne has quit IRC (Quit: There's a real world out here!)
20:57:52 *** FLHerne has joined #openttd
21:02:52 *** lobstarooo has joined #openttd
21:07:21 *** lobster has quit IRC (Ping timeout: 480 seconds)
21:07:23 *** lobstarooo is now known as lobster
21:13:10 *** andythenorth has quit IRC (Quit: andythenorth)
21:34:29 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:42:12 *** andythenorth has joined #openttd
21:47:14 *** andythenorth has quit IRC (Quit: andythenorth)
22:59:06 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
