Log for #openttd on 10th February 2022:
Times are UTC Toggle Colours
10:37:07  <peter1138> Mum, I'm staaaaaaarving!
11:07:22  <DorpsGek> [OpenTTD/OpenTTD] RailwAI opened issue #9813: [Bug]: After removing 'full load any cargo', trains sometimes keep waiting for a full load
11:11:03  * Gustavo6046 throws a NaN sandwich at peter1138 
11:41:04  <Eddi|zuHause> you misspelled "nand switch"
12:00:15  *** WormnestAndroid has quit IRC
12:01:15  <peter1138> Nearly lunch time.
12:01:15  *** WormnestAndroid has joined #openttd
12:04:10  <LordAro> A text: "You've been in close contact with someone who has recently tested positive. Please order a test kit: https://test-kit-<linkbreak>"
12:04:13  <LordAro> i am sus
12:18:20  <peter1138> Avoided so far, to my knowledge.
12:36:22  <peter1138> Yay, lunch :D
12:37:36  <peter1138> I wonder if my phone warns me about sus texts. I had a phoney (hah) phone call that it warned me about once.
13:36:23  *** Gustavo6046 has quit IRC
14:28:09  *** D-HUND is now known as debdog
14:33:57  *** nielsm has joined #openttd
14:42:11  <supermop_work> LordAro: here they just started sending everyone the tests
15:07:12  <nielsm> so I had a thought... which may not be new... but would it be possible to parallelise vehicle ticks (pathfinding etc) if the vehicle ticks were split into two: planning and execution. the planning step is only allowed to examine the world, and only allowed to touch some designated "planned action" fields on the vehicle being planned. the planning runs in parallel. the execution then runs in
15:07:12  <nielsm> serial, well-defined order, and performs the actions calculated for each vehicle
15:09:46  <nielsm> there might then be some cases where a vehicle might not executed the planned action, maybe? like trains crossing a signal will only do it if the planned action is still safe, and road vehicles on a level crossing that become reserved by a train just as the RV is about to enter the tile
15:10:47  <nielsm> like, track reservations for path signals, the train would plan which track it wants to reserve, and then in execution the trains get to actually reserve the track in order, and if a train can't execute the reservation it instead waits
15:11:21  <nielsm> I _think_ that would make it possible to run all the heavy work in parallel
15:16:08  <nielsm> it would probably change the simulation outcome in some situations, but it should still be deterministic as long as the planning step of a vehicle tick does not modify any world state
15:18:19  <Rubidium> I'm quite not sure waiting is the right solution. Why would two trains entering a (big) station and planning to use the same platform block one from entering another free platform? You would get sporadic bug reports of trains that, for no apparant reason, stop
15:19:10  <nielsm> yeah I'm thinking that maybe vehicles that fail their planned action should be put back in a queue for a second (and third etc) run at planning and execution
15:19:27  <nielsm> so it repeats until all vehicles are satisfied
15:22:29  <Rubidium> if you got the time and energy to try, it's definitely worth a try
15:23:22  <Rubidium> I'm quite interested to see how much the improvement you can get with that would be, but don't have the spare time to invest in such a project
15:47:37  *** Gustavo6046 has joined #openttd
16:00:54  <DorpsGek> [OpenTTD/OpenTTD] nielsmh opened pull request #9814: Fix: Original music playback rate was slightly too fast
16:01:13  *** dP has joined #openttd
16:01:13  *** dP is now known as _dp_
16:22:58  *** Smedles has joined #openttd
16:24:10  *** frosch123 has joined #openttd
16:29:25  <frosch123> nielsm: my assumption is: the pathfinder is not that important, it uses a lot of caching, so parallized access is probably a nightmare. however stuff like "vehicle acceleraton" could be parallelized and runs way more often than pathfinders
16:30:02  <frosch123> also, newgrf stuff can be mostly parallelized, if you get rid of some global state that does not need to be global
16:30:29  <frosch123> hmm, i think tb has a roadmap somewhere for parallizing viewport draing
16:34:23  <TrueBrain> Did some attempts, gave lovely speeds up.. but also requires lot of refactoring to make it sane :D
16:45:10  <nielsm> ah right... newgrf is a danger point yeah
16:45:36  *** gelignite has joined #openttd
16:45:51  <frosch123> only the ottd implementation
16:46:07  <frosch123> it has some "static" in places that should be "thread_local"
16:49:30  *** glx has joined #openttd
16:49:30  *** ChanServ sets mode: +v glx
16:56:49  *** Wormnest has joined #openttd
17:00:50  *** Gustavo6046 has quit IRC
17:00:57  *** Gustavo6046 has joined #openttd
17:01:49  *** Gustavo6046 has quit IRC
17:34:37  *** Flygon has quit IRC
17:57:48  *** Kitrana1 has quit IRC
18:00:38  *** Kitrana has joined #openttd
18:09:47  *** andythenorth has quit IRC
18:12:17  <nielsm> hmm, the newgrf execution stuff mostly isn't so bad actually, the big joker is persistent storage and its usage of a Pool type
18:15:56  <nielsm> and I'm thinking _current_company should be thread local too
18:20:10  <frosch123> there are very few places which are actually allowed to modify persistent storage
18:20:25  <frosch123> drawing certainly is not :)
18:20:36  *** Kitrana1 has joined #openttd
18:21:10  <frosch123> nor is vehicle movement
18:21:36  <TrueBrain> now I am curious what was up with viewport again .. hmm
18:21:58  *** jottyfan has joined #openttd
18:22:08  *** andythenorth has joined #openttd
18:22:29  <TrueBrain> I have too many local branches :D
18:22:33  <TrueBrain> 338 ..
18:23:31  <TrueBrain> ah, yes, I just added a massive queue in the viewport .. :D
18:26:42  *** Kitrana has quit IRC
18:27:33  <nielsm>   that's all the suspicious things I found
18:30:22  <TrueBrain> ah, and yes, it needed classification, as _vd is just an ugly hack ..
18:32:29  <frosch123> nielsm: <- also that one
18:33:00  <frosch123> though  "thread_local" always looked like a hack to me :)
18:33:51  <TrueBrain> very easy to screw up too :P
18:56:00  <TrueBrain> it might surprise everyone in here, but using memory you didn't initialize doesn't work
18:56:06  <TrueBrain> sadly, it takes a few minutes to figure out you are trying that :D
18:56:09  <TrueBrain> stupid compilers not telling me
19:02:55  <Rubidium> might require you to enable more warnings, or maybe something like -fsanitize=memory
19:03:10  <TrueBrain> pfff
19:05:03  <nielsm> frosch123 wow, the usage of that _temp_store is just ugly
19:06:14  <frosch123> it's zeroed before every grf call, but some results are read after the grf call
19:06:51  <frosch123> i do not remember whether it is actually memset, or whether there was some state how much memset was needed
19:07:04  <frosch123> iirc i measured what was faster, and it was measureable :/
19:14:15  <TrueBrain> I assume you memset A LOT :P
19:17:05  <nielsm> memset'ing a memory size known at compile time probably allows the compiler to generate much tighter code, so I can imagine that being the faster
19:18:24  <frosch123>

Powered by YARRSTE version: svn-trunk