IRC logs for #openttd on OFTC at 2023-08-14
⏴ go to previous day
00:22:59 *** sittinbythefire has quit IRC (Quit: User went offline on Discord a while ago)
01:55:22 *** Wormnest has quit IRC (Quit: Leaving)
01:59:44 *** Tirili has quit IRC (Quit: Leaving)
02:56:15 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:10:39 *** D-HUND is now known as debdog
06:03:32 <truebrain> Are you now sticking a feather up your own ass? 😄 😛 (sorry, couldn't resist 😄 )
06:10:32 <truebrain> bit weird ... westbourne memory dropped by 30% on 2023-03-01, where it wasn't the case on 2023-02-26 .. but no commit around that time actually stands out where I am like: yeah, that would explain it
06:12:03 <truebrain> ah, no, the commit it picked up from 2023-02-26 is a bit weird, but okay .. so this is most likely the rework of how linkgraph is stored
06:12:19 <truebrain> `Only store present link graph edges and not all possible edges`
06:12:22 <truebrain> that sounds reasonable
06:12:33 <truebrain> yeah, just checking 😛
06:13:26 <Bouke> However it doesn't feel nice (the feather that is...)
06:13:39 <truebrain> sounds like a "you" problem
06:15:26 <truebrain> no, for `release/` branches that is a change made in the actual code
06:15:32 <Bouke> truebrain: If you really want to know, a git bisect would narrow it down.
06:16:35 <truebrain> I am more surprised by how `--before` works in git .. it feels somewhat random whether it includes the day itself or not
06:18:10 <Bouke> truebrain: Like a global search and replace (remove)?
06:18:41 <truebrain> no, just check the `release/` commit history, you will find a commit that changes the assert option from off to on (or the other way around)
06:24:19 <truebrain> I am trying to understand why my scripting picked a certain hash on a certain date .... and I can't reproduce the result
06:28:48 <truebrain> as if something changed between yesterday and today ... this is so odd
06:30:20 <truebrain> yesterday, the fucking same script, picked `20230226--ma18182e24b` for that date .. today it picks `20230226--m6fcc8727f5`
06:30:25 <truebrain> but the result of yesterday makes NO sense ..
06:32:17 <Bouke> truebrain: Could I use the regular nightly build script for it, or would I need a build without assertions? I guess the nightly suffices, however that means adding assertions are considered a penalty then.
06:33:26 <truebrain> nightlies are build with asserts on
06:33:39 <truebrain> does it matter for relative comparison? No clue
06:34:04 <truebrain> I don't even know if running this on GitHub runners is stable .. or worded differently: how much noise it would introduce
06:34:12 <truebrain> that is for you to find out I guess 😄
06:36:39 <truebrain> hmm .... that this `--before` in git now returns different results is very annoying, as that means all the binaries I have been building are now not always the ones it will use on a next run .. which is not what the idea was behind it, ofc 😄
06:43:37 <truebrain> the only thing that makes sense if is the timezone changed on this machine .. which can't be the case .. but that would be the only thing that makes sense
06:47:52 <pickpacket> according to nml I have 6 orphaned sprites. Is there an easy way to find them?
06:48:49 <Bouke> truebrain: Different terminal with different environment variables having a different timezone?
06:50:02 <truebrain> about 10% of the binaries I produced are of the wrong commit in that day .. still in that day, but a lot harder to find back what commit that would make 😄
06:50:26 <truebrain> Bouke: not from what I can tell .. freshly installed VM configured on UTC
06:50:53 <truebrain> and I don't mind as much that it might be wrong, but I do mind I have no clue why, so fixing it is hard 😛
06:55:12 <truebrain> okay, so one picked the wrong date like 15 minutes ago, in the same shell, re-executing the command, gives me the right one
06:55:18 <truebrain> wth is going on here 😄
06:56:09 <peter1138> Does it depend on the current time for some reason...
06:56:41 <truebrain> owh, there you might have something ..
06:56:48 <truebrain> that it takes the date I ask him, and the time of the current clock
06:56:55 <truebrain> would that be the case? That would be a really stupid implementation
06:57:01 <truebrain> but that might just make sense ..
06:57:02 <peter1138> I mean, that would be stupid, but...
06:57:58 <truebrain> how to test that hypothesis ..
07:02:30 *** Extrems has quit IRC (Ping timeout: 480 seconds)
07:08:20 *** Extrems has joined #openttd
07:22:58 <truebrain> no, that doesn't seem to be it .. at least, another day with a commit that passed the current time didn't change in the returning value
07:26:06 <truebrain> okay, I now have one I can actually reproduce (for now at least) on my local machine
07:27:09 <truebrain> `git log --pretty=format:"%C(auto)%h %ci %cn %s" --date=iso --before "2022-10-25"` returns one commit on the 25th (but not the other), where it should return no commits on the 25th
07:28:10 <truebrain> so it does seem to add some arbitrary time .. just not sure which time 😛
07:28:38 <truebrain> okay, I can fix it by adding a time too
07:28:41 <truebrain> but that is just weird
07:40:07 <Bouke> What is the author/commit date time of that commit?
07:49:44 <truebrain> check for yourself! But clearly some imaginary time is added to the date .. I just can't figure out which 😛
07:49:55 <truebrain> but adding 23:59:59 fixes two problems I had, so it is fine now, I think 🙂
07:50:17 <truebrain> now time to redo the whole shebang, as I wanted to make some configuration changes too 🙂
07:50:33 <truebrain> the 1.4 titlegame now seems a lot more stable .. let's hope it remains that way 😄
07:52:51 <truebrain> okay, also time to add a few more savegames I guess .. let's see, where is my archive ..
07:58:53 <peter1138> Bah, hungry is striking again.
07:59:19 <truebrain> a bit sad that the good openttdcoop games need GRFs that I cannot publish 😦
07:59:35 <truebrain> LordAro: nooooooooooo
08:00:02 <LordAro> the progames are vanilla, iirc?
08:00:06 <truebrain> except that doesn't really do anything 😛
08:00:12 <truebrain> yeah, progames are good; but there are better ones
08:00:28 <truebrain> we really should collect some good savegames in that repo tbh
08:01:58 <truebrain> but by closing that PR, you kinda force someone to add GitHub workflows to every night test if the savegames in that repo still run against the nightly 😛
08:02:07 <truebrain> guess that also means we should move it into OpenTTD space 😄
08:02:13 <truebrain> your had a holiday right LordAro? 😄 😄
08:03:22 <truebrain> I still think it is a good idea to run a set of savegames in predefined intervals .. as one can see, the 1.4 title game failed for over a month 😛
08:05:58 <truebrain> owh right, I also once wrote scripting that runs a savegame for N ticks in both master and older builds, create a savegame after those N ticks, and compares those two
08:06:27 <truebrain> we found bugs because of it!
08:06:47 <truebrain> I just never finished it and pushed it
08:06:50 <truebrain> as with many things 🙂
08:07:09 <truebrain> it did leave me with an archive of many many different games 🙂
08:09:19 <truebrain> LordAro: it was the other way around btw .. public games had no NewGRFs .. the pro-games had this whole pack, with GRFs that I still can't recover till this day 😛
08:09:35 <truebrain> (and I have the mercurial repo of that pack .. but I am still missing the exact match of a few)
08:11:33 <andythenorth> Ok breakfast time
08:12:14 <truebrain> on a game without NewGRFs 😄
08:13:52 <peter1138> NewGRFs removed at some point?>
08:14:01 <Eddi|zuHause> is that like saying "the fire on the ship probably started with electric cars, because they are so dangerous",,, and then finding that the electric cars were actually least affected by the fire?
08:16:31 <truebrain> LordAro: why do I have a savegame contributed to you named "biggest-town-ever"? 😄
08:17:24 <Eddi|zuHause> i think it should be either "contributed by" or "attributed to"
08:35:37 <truebrain> right, added 8 games with random interesting properties .. still without AIs, as that kinda kills performance too much 😄
08:35:49 <truebrain> this already takes a good amount of time to do a single version 😛
08:36:28 <truebrain> the only thing I didn't have, was an aircraft game, it seems .. I do have trains, ships, and RVs 🙂
08:38:01 <peter1138> Aircraft are basically free 😉
08:38:30 <peter1138> They are Eddi's ultimate transport... just a simple state machine to follow.
08:39:05 <Eddi|zuHause> sure. i let you believe that :p
08:39:17 <truebrain> Stats in the most extreme form 😛
08:39:36 <truebrain> all those that go up in CPU are title games .. so although 15% sounds like a lot, those games do absolutely nothing 😛
08:40:28 <truebrain> biggest-town-ever game increase 3% in memory footprint 😛
08:40:53 <truebrain> the only interesting one is a timberwolf game, with a 9% increase in CPU over 2 years
08:41:16 <truebrain> so there seems to be at least some regression in terms of performance 😄
08:42:13 <Eddi|zuHause> are you comparing game versions? not very clear from the picture
08:43:19 <peter1138> Game version is the date along the X-axis.
08:44:51 <Eddi|zuHause> yeah. but release? nightly? the graph seems to only compare two versions on either end of the "scale"
08:45:00 <truebrain> okay, I will let this do its thing for a while .. maybe it shows something interesting
08:46:20 <Eddi|zuHause> i was trying to think if i have some interesting save game to contribute, but i think almost all games are with some kind of patchpack
08:46:40 <Eddi|zuHause> or experimental newgrfs
08:47:47 <Eddi|zuHause> like a custom dbsetxl-adapter for firs
08:48:10 <truebrain> and slowly more data tripples in .. I still like how memory was heavily reduced for most games in the last few months 😄
08:48:27 <truebrain> the CPU graph however becomes less and less clear to read .. as that goes 😛
08:48:53 <peter1138> Linkgraph changes, right?
08:49:00 <truebrain> yeah, pretty sure linkgraph was a big one
08:49:03 <truebrain> but there are several other ones
08:50:23 <truebrain> and I see I need to improve the crash detection .. that drop in 2023-02 is in fact a crash 😛
08:52:05 <truebrain> it takes about 3 minutes per datapoint
08:52:13 <truebrain> it has 500 datapoints to make
08:52:42 <Eddi|zuHause> ideally you'd store those so you don't have to rerun them to update the graph :p
08:53:15 <peter1138> Urgh, PC hard-locked 😦
08:54:07 <Eddi|zuHause> i hate when that happens. usually for me it's "oom doesn't trigger until it's way too late"... or a graphics driver issue
08:55:24 <truebrain> I wonder if I can run multiple simulations at once, or if that would influence the results too much of each other ...
08:56:40 <peter1138> "fatal: your current branch appears to be broken"
08:59:20 <peter1138> So it froze while I was cherry-picking, and now my git repo is corrupted. Hmm.
09:03:57 <LordAro> truebrain: is it the save with the single town covering the whole map?
09:09:54 <LordAro> that came from the forum iirc
09:13:42 <locosage> what's the map size?
09:19:22 <locosage> I had some performance testings saves somewhere...
09:23:57 <alfagamma_0007> That looks awful
09:24:55 <locosage> it doesn't need to look good xD
09:25:14 <locosage> it was created to test performance of cargo catchment changes
09:26:00 <locosage> also, makes openttd use 1.5Gb of memory xD
09:27:00 <alfagamma_0007> The max ottd took I think was 800 megs?
09:27:24 <locosage> oh, 1.1gb actually on fresh run
09:27:33 <locosage> it was over 2gb on older versions
09:27:39 <locosage> stations use a lot of memory
09:27:46 <locosage> even if they do nothing
09:30:37 <truebrain> seems the savegames all behave different at different points in time, which is good 😄
09:31:10 <alfagamma_0007> How did you benchmark this?
09:31:29 <truebrain> If only there was text in the screenshot explaining it 🙂
09:32:21 <locosage> truebrain: title games are just cluttering the chart at this point
09:32:59 <peter1138> Hmm, this one doesn't show the same CPU reduction as before...
09:34:14 <truebrain> it does? Depends on what you refer to as "before" 😄
09:34:34 <truebrain> it is less clear now, as they move at different points, if you compare it with the one with just 2 points 🙂
09:35:20 <locosage> truebrain: it's weird that some have a drastic change on a second point, you sure that's not an error?
09:36:38 <truebrain> I am still unsure what the 1.4 title game is doing .. I disabled autosave and linkgraph recalc, which made it more stable, but something in this game behaves unexpected, but just sometimes. Will be fun to look into 😄
09:37:14 <truebrain> (the last dip is because of a bug in OpenTTD; but the other two are not there if I would redo that point in time .. it is the only savegame behaving like this)
09:45:09 <Bouke> Is there a way to generate/modify a savegame/scenario programmatically? Say I'd like to fill one side of the map with a single industry, and wouldn't like spending a long time of clicking 'build industry'.
09:45:30 <truebrain> in theory, you can do that, yes, but it is very very tricky
09:45:43 <truebrain> some objects reference other objects etc
09:45:47 <_jgr_> You can write a gamescript to do it
09:46:04 <truebrain> there are also attempts to make heightmaps contain metadata for these kind of things
09:50:39 <locosage> _jgr_: can just patch the openttd quickly
09:50:46 <locosage> at least, that's how I did minee
10:06:57 <andythenorth> Ok back on my MBP, shall I install MAMP stack so we can move the infra to it?
10:07:18 <truebrain> orrrrr, more useful, I pinged you in one of these PRs, if you can test it out 🙂
10:10:37 <truebrain> it magically fixed itself? 😮
10:12:10 <truebrain> well, we did fix a crash, but if that was the cause of that backtrace, MacOS needs to learn to produce better backtraces 😛
10:17:15 <truebrain> annoying our CI doesn't pick up on it
10:19:21 <Bouke> truebrain: Pick up what?
10:19:30 <truebrain> the build failure you are having
10:19:44 <truebrain> so now it is easy for someone to add another file with the same name .. CI says: everything is fine!
10:19:50 <truebrain> I rather have CIs fail on stuff that goes wrong 😛
10:19:55 <truebrain> prevent is better than cure etc etc
10:20:11 <peter1138> Not going to lie, those files having the same name tripped me up a few times when opening the wrong file...
10:20:38 <truebrain> haha 😄 So MacOS is just protecting peter1138 sanity .. I can live with that 😄
10:20:39 <Bouke> You'd have to actually build through Xcode to catch this issue; the CI build simply uses CMake directly (not going through Xcode).
10:20:53 <truebrain> it uses xcode in the backend 🙂
10:20:55 <truebrain> just not the GUI part 😄
10:20:59 <peter1138> The MSVS issue is why the sound drivers end in _s, music wtih _m and video with _v...
10:21:45 <truebrain> either way, a failing CI on these mistakes would be nice, but it is what it is
10:21:46 <Bouke> It uses the build tools from Xcode. The problematic part here is the Xcode project file, which is only needed when working in the GUI. That part isn't used when building through CMake.
10:22:09 <Bouke> Well we could have a simple script that starts yelling when there are duplicate file names.
10:22:31 <truebrain> we have more scripts that yell when people make a mistake that isn't noticed that easily 😛
10:53:35 <peter1138> In fact, if you make a PR, we can run it against the current code base, then once #11186 is merged, run it again... to make sure it works.
10:59:02 <peter1138> Hehe, it fails the CI itself 😄
11:00:24 <_glx_> truebrain: Should be quite easy to check that inside cmake
11:00:39 <_glx_> We use a nice function to add files
11:03:10 <truebrain> CMake would be preferred, as then you get the issue locally too
11:06:32 <peter1138> Doing it in CMake means you need to test all configurations
11:07:22 <peter1138> So, potentially useful to do both ways.
11:08:58 <peter1138> Also, do CI checks have dependencies? So e.g. it could skip actually trying to compile if a prerequisite (duplicate files, bad commit messages...) fails...
11:09:33 <truebrain> it could; but do we really want to? 🙂
11:09:57 <truebrain> especially bad commit messages, we can fix during squash; some fly-by committers just don't understand git enough to fix that properly 🙂
11:10:14 <Bouke> Well I know not enough CMake-foo to get that to work.
12:29:39 <Bouke> It looks like hardware counters are not available inside the (github actions) VM:
12:29:39 <Bouke> 2023-08-14T12:21:29.9142050Z Performance counter stats for 'ls /':
12:29:39 <Bouke> 2023-08-14T12:21:29.9142381Z
12:29:39 <Bouke> 2023-08-14T12:21:29.9143029Z 1.40 msec task-clock # 0.654 CPUs utilized
12:29:39 <Bouke> 2023-08-14T12:21:29.9143794Z 0 context-switches # 0.000 /sec
12:29:40 <Bouke> 2023-08-14T12:21:29.9144530Z 0 cpu-migrations # 0.000 /sec
12:29:40 <Bouke> 2023-08-14T12:21:29.9145652Z 115 page-faults # 82.420 K/sec
12:29:42 <Bouke> 2023-08-14T12:21:29.9146591Z <not supported> cycles
12:29:42 <Bouke> 2023-08-14T12:21:29.9147117Z <not supported> instructions
12:29:44 <Bouke> 2023-08-14T12:21:29.9147715Z <not supported> branches
12:29:44 <Bouke> 2023-08-14T12:21:29.9148487Z <not supported> branch-misses
12:29:46 <Bouke> 2023-08-14T12:21:29.9149231Z <not supported> L1-dcache-loads
12:29:46 <Bouke> 2023-08-14T12:21:29.9149999Z <not supported> L1-dcache-load-misses
12:29:48 <Bouke> 2023-08-14T12:21:29.9150679Z <not supported> LLC-loads
12:29:48 <Bouke> 2023-08-14T12:21:29.9151400Z <not supported> LLC-load-misses
12:29:50 <Bouke> 2023-08-14T12:21:29.9152296Z
12:29:50 <Bouke> 2023-08-14T12:21:29.9152527Z 0.002133719 seconds time elapsed
12:29:52 <Bouke> 2023-08-14T12:21:29.9152859Z
12:29:52 <Bouke> 2023-08-14T12:21:29.9152997Z 0.002251000 seconds user
12:29:54 <Bouke> 2023-08-14T12:21:29.9153426Z 0.000000000 seconds sys
12:42:52 <Bouke> Yeah sorry, not used to IRC bridge 🙂 (I've shortened in discord)
12:52:45 <Bouke> _jgr_: I'd want the savegame to be playable without any dependencies.
12:58:30 <_jgr_> Bouke: You can remove the script afterwards once its done whatever needs doing. Otherwise you'll need to make a custom build to do it as suggested above
13:30:45 <Bouke> OTTD doesn't seem to pick up my GS. I have a file `~/OpenTTD/game/coalcity/info.nut` calling `RegisterGS(CoalCity());`. From the (sparse) docs I suppose that should create a menu item for this GS? It only lists GS I've downloaded.
13:30:52 *** nielsm has quit IRC (Ping timeout: 480 seconds)
13:35:17 <LordAro> that's not one of the locations it looks in
13:35:24 <Bouke> Sorry I meant `~/Documents/OpenTTD`
13:35:49 <Bouke> (in the same OpenTTD root my save games are in)
13:36:52 *** _aD has quit IRC (Ping timeout: 480 seconds)
13:38:12 <Bouke> Right... it requires specific file names. And running with `-d script=1` gives some info. At least my entry is listed now.
14:00:44 <Bouke> In order to learn from other gamescripts on bananas, I'd have to download them ingame and then unpack?
14:13:00 <_glx_> when you download ingame they are in a tar
14:20:15 <_glx_> but this script might be hidden (depending on some settings)
14:26:55 <_glx_> and it seems the list is not updated when gui.ai_developer_tools changes
15:09:19 *** gelignite has joined #openttd
15:11:28 *** _aD has quit IRC (Ping timeout: 480 seconds)
15:50:26 *** Wormnest has joined #openttd
16:40:50 *** HerzogDeXtEr has joined #openttd
17:18:34 <_glx_> ```1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/core.h
17:18:34 <_glx_> 1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/game_info.cpp
17:18:34 <_glx_> 1> [CMake] Duplicate file for openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h
17:19:38 <_glx_> paths are just for me to see where
18:35:45 <truebrain> seems there is another savegame that behaves a bit weird. But otherwise data is getting more and more accurate. The yellow line is when a linkgraph change landed that heavily reduced memory usage. The CPU graph feels "messy", but it really isn't. Just a few savegames that I didn't run for long enough to be accureate. Now I just have to let it gather some more data to see what commit actually
18:35:45 <truebrain> caused a positive or negative change 🙂
18:37:14 <truebrain> a bit cleaned up CPU graph, where you can see arond 2021-12 there was a regression, and around 2022-10 there was a good change 🙂
18:37:25 <truebrain> now I just want to know what caused the regression there 😛
18:37:44 <truebrain> (there is also a regression around 2022-07, but it is a bit harder to spot
18:38:27 <DorpsGek> - Update: Translations from eints (by translators)
18:38:40 <peter1138> Does the CPU graph include starting up OpenTTD itself?
18:39:37 <truebrain> that among other things is what makes the smaller runs a lot more noisy
18:45:47 <truebrain> so the increase in CPU from 2021-12, was at 2021-12-16, when the command system was changed to be more template-magic .. I just fail to see how that impacts performance for this kind of performance testing 😄
18:45:55 <truebrain> There are no AIs or GSes, so .. no commands?
18:49:26 <michi_cc[d]> Commands are used locally, too, for example CMD_LANDSCAPE_CLEAR can be called from tile loop things as well.
18:49:38 <truebrain> ah .. did not know 😄
18:49:52 <truebrain> so yeah, that was a 5% impact on some games
18:50:43 <michi_cc[d]> It not the main use of commands, but stuff like planting fields, (tropical) lumber mill or flooding use commands to get all the proper checks "for free).
18:54:29 <truebrain> the drop around 2022-10 is because of the framerate change for trains
18:58:20 <truebrain> so let me check if the stats are actually correct 😄
18:59:14 <truebrain> yup, it actually is that commit .. very odd
19:05:57 <truebrain> 2 more interesting points in 2023, but I need more data first to pinpoint those .. but that is all the commits with significant CPU impact
19:06:01 <truebrain> I am kinda shocked there are so few 😛
19:07:24 <_jgr_> The CMD_ALL_TILES test should be cheaper than the IsValidTile test, so you could perhaps get a small saving by doing them in the other order
19:07:53 <truebrain> that is worth trying
19:08:03 <truebrain> what surprises me more, is that the commit reads as if it only impacts networking games
19:08:11 <truebrain> so I am a bit puzzled how it impacts this performance test 😄
19:11:35 <peter1138> "received from a client"... in a single player performance test... Hmm.
19:14:04 <peter1138> Surprising if IsValidTile() is a performance issue, it doesn't do much, except for accessing the map.
19:18:28 <truebrain> yeah, need to confirm it is actually that commit, but everything suggests it is
19:18:40 <pickpacket> The topic still says 13.3
19:21:23 *** DorpsGek changes topic to "13.4 | Website: *.openttd.org (source: github, translator: translator, server list: servers, wiki: wiki) | Don't ask to ask, just ask | 'Latest' is not a valid version, 'Most recent' neither | English only"
19:55:36 <truebrain> michi_cc[d]: would it be difficult to not use the command system for those calls? Just wondering out loud, more than anything
20:07:59 <FLHerne> truebrain: do any of the savegames you're testing use grfs?
20:08:36 <_glx_> ```1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/core.h filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/3rdparty/fmt/core.h
20:08:36 <_glx_> 1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/network/core/game_info.cpp filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/game/game_info.cpp
20:08:36 <_glx_> 1> [CMake] openttd_lib: D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h filename is a duplicate of D:/developpement/GitHub/glx22/OpenTTD/src/strgen/strgen.h
20:08:42 <FLHerne> I find by far the biggest perf hit for me is sprite action evaluation for stuff like FIRS industries
20:08:53 <_glx_> the last one is funny 🙂
20:09:15 <truebrain> I am not measuring what takes time; I am measuring if we have regressions 🙂
20:09:28 <truebrain> and if so, what we can learn from them, if anything
20:09:37 <FLHerne> truebrain: ok, thanks, just didn't see any in the screenshot Wentbourne + titlescreens
20:09:52 <truebrain> you can see in one of the others what maps are loaded
20:09:53 <FLHerne> truebrain: yeah, but regressions in grf action evaluation would be bad
20:09:54 <truebrain> but there are many 😄
20:10:06 <FLHerne> (or gains would be good, like that improvement in sprite caching)
20:10:34 <peter1138> TrueBrain is measuring changes that happened, not potential changes.
20:10:35 <truebrain> regressions in grf handling will be picked up 🙂 Or should ..
20:13:51 <FLHerne> peter1138: There was a real commit that significantly improved caching of some industry-tile actions, I was just trying to find it
20:13:56 <FLHerne> unless I hallucinated it again
20:15:43 <FLHerne> yeah, I think this was the one I remembered and I dreamed the bit about industry tiles :p
20:16:08 <peter1138> Okay, so I cna get remote xterm to display, but remote OpenTTD is eluding me 😦
20:17:30 <truebrain> FLHerne: that PR is from before my measurements, so it will not show up 😦
20:17:39 <truebrain> I took 2 year back as reference, as .. why not 🙂
20:18:55 <FLHerne> I don't think it matters in isolation, was just curious if your testing set picked up that kind of large-effect-on-niche-cases performance change
20:19:14 <truebrain> otherwise we need to add a test case
20:19:40 <truebrain> but I try to keep the savegames realistic user played maps
20:19:48 <truebrain> as that is the important thing to me 🙂
20:20:01 <truebrain> (and it consumes a lot of time to evaluate a savegame
20:22:13 <peter1138> Come on SDL, this should work...
20:29:36 <truebrain> FLHerne: btw, this means if you have a game that is representing an actual game and has these kind of things, please do let me know 🙂
20:29:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:33:11 <truebrain> Bouke: awh, that is sad 😦 Tnx for checking .. but that is sad. What I can do, is offer my home server as GitHub Runner, so we can still do these performance things, but then it can't be part of the regular CI .. as my home server is not a guarantee 😛
20:33:25 <truebrain> and I don't think it is worth the money to run an EC2 instance on AWS for this 🙂
20:36:02 <truebrain> my wiki cache technique actually works (and still works) 😄
20:36:11 <truebrain> saving money and serving pages faster, w00p!
20:36:17 <peter1138> Etag instead of last modified?
20:36:25 <truebrain> that, and multi-tier caching
20:36:40 <truebrain> so local (at a POP location) cache, if that fails, R2 bucket cache, if that fails, call to AWS
20:36:46 <peter1138> Probably andy's MBP wouldn't struggle with 8GB.
20:37:05 <truebrain> is in 3 days, so a total of ~100GB a month, so yeah .. he should be fine
20:37:52 <truebrain> the rendered wiki so far (what is cached in the R2 bucket) is 350MB in size
20:37:59 <truebrain> people really went apeshit on the wiki 🙂
20:39:50 <truebrain> talltyler: how is the economy going?
20:40:26 <truebrain> `47,202,030,198 instructions:u # 1.32 insn per cycle ( +- 0.00% )` I am still surprised how stable this method of measuring is .. a difference of 0.00% over 5 runs ..
20:41:10 <_glx_> openttd is very deterministic 🙂
20:41:10 <talltyler> Done with work for the day, time to see if I have enough brain left to make TimerGameCommon and figure out inheritance in C++
20:41:20 <truebrain> _glx_: except the title game of 1.4 😛
20:41:30 <truebrain> talltyler: good luck 🙂
20:41:48 <truebrain> _glx_: I pay good money if someone can point to what makes 1.4 so not-deterministic 😄
20:43:11 <_glx_> yeah this 1.4 save has to be very special
20:43:26 <truebrain> I found another savegame that shows similar issues .. so I will compare their settings soon
20:43:38 <truebrain> disabling autosave helped
20:44:56 <peter1138> Cargo dist involved?
20:45:12 <truebrain> I don't know cargodist enough, but the settings in 1.4 were off
20:45:21 <truebrain> but I might have been looking wrong there
20:45:24 <truebrain> AIs and GSs are not loaded
20:45:52 <talltyler> Off to a good start by hanging Visual Studio entirely just adding a file 😲
20:46:10 <_glx_> well it's a title game, it should not have AI or GS
20:46:26 <_glx_> ah yes it hanged at me on start
20:46:47 <_glx_> updating status for version control
20:47:13 <Eddi|zuHause> wasn't there a rule that the title game submissions can have AI, because they will be purged anyway?
20:47:32 <_glx_> it seems each new VS version is worse than the previous one
20:47:50 <Eddi|zuHause> that's true about many things
20:47:52 <talltyler> Good thing I only need to add two files, it hung again for the second!
20:48:44 <_glx_> and I uninstalled then reinstalled it to get rid of annoying errors at startup
20:49:07 <talltyler> I didn't upgrade from VS2019 properly so I can't run in debug mode anymore, the option is greyed out 😦
20:49:20 <talltyler> I have to build and then run from explorer
20:49:25 <_glx_> that's how I learned newer versions (since 17.6) come with there own vcpg
20:50:04 <_glx_> breaking my build setup because it was using its vcpkg and not mine
20:54:01 <truebrain> lol, I thought you composed an image
20:54:06 <truebrain> but .. yeah .. good job QA 😛
20:54:30 <_glx_> it depends on which tab you visited before this one 🙂
20:54:48 <_glx_> somebody forgot a widget in background
20:56:39 *** gelignite has quit IRC (Quit: Stay safe!)
20:57:50 <truebrain> oof, command_func.h changes is basically a recompile ... ssslllloooowwwwww 😄
21:03:12 <talltyler> `a member of type "const uint16_t[]" cannot have an in-class initializer` 🤔
21:03:19 <talltyler> Where am I supposed to initialize it?
21:05:39 <talltyler> Ah, constexpr seems to work too
21:05:54 <talltyler> (according to stackoverflow and the lack of error now 🙂 )
21:05:58 <truebrain> class members that a "const" should be "constexpr" 🙂
21:06:20 <truebrain> it has its reasons, but .. yeah, constexpr to the rescue 🙂
21:08:19 <talltyler> What would the naming pattern be for `_month_date_from_year_day[]` once it's inside a class? Keep it the same, or change it?
21:08:39 <truebrain> I think it doesn't have to be part of the class
21:08:44 <truebrain> I think you can just define it static at top
21:08:53 <truebrain> but that whole array is just ... old
21:08:57 <truebrain> but you have been through that before 😄
21:09:18 <talltyler> It was outside the class, but then it won't be inherited, right?
21:09:50 <talltyler> I guess that could still work, but it sounds...ugly
21:11:15 <talltyler> The array is only used within the same file, but the function that uses it gets inherited by two subclasses, so they would reference the parent static array
21:11:26 <truebrain> which is totally fine
21:15:06 <peter1138> You don't need to go all-or-nothing with OO.
21:16:20 <talltyler> C# is the only other OO language I know 🙂
21:20:45 <LordAro> truebrain: could the nondeterminism be cpu cache based?
21:21:04 <truebrain> in theory, yes, but none of the other savegames show that behaviour
21:21:10 <truebrain> I would also not expect it to be that much of a difference
21:21:24 <truebrain> I will just have to run a few calgrind profiles, and compare them
21:21:25 <LordAro> maybe it's right at some sort of boundary
21:21:59 <_glx_> I decided to be nice and report the options visual artifacts to microsoft 🙂
21:22:15 <_glx_> will see if it takes a year to fix it 🙂
21:22:19 <truebrain> also applied for a position as QA? 😄
21:25:06 <truebrain> it is such a stupid bug, as you know someone was just being lazy
21:25:48 <_glx_> yeah it's most likely a missing panel under the groups
21:26:12 <truebrain> you just know if you can touch their code you can fix it in minutes 😛
21:27:01 <truebrain> meh; we made too many changes in the last few months .. 1 day can have like 10 commits .. hard to find out which commit caused a performance gain 😄
21:27:51 <_glx_> all the std::string changes 🙂
21:28:19 <_glx_> nice rabbit hole commits 😉
21:29:02 <truebrain> I am still surprised by that add-tile-check-in-command-system commit .. why it has an impact, and why it no longer has any 😛
21:33:40 <talltyler> truebrain: All the timer handlers are not currently part of the class, can/should they be moved inside so they can be inherited, or stay outside and get duplicated? (::Elapsed is different for each, so it would get overridden)
21:34:10 <truebrain> I am sure you want to make them different for economy over time 🙂
21:34:39 <truebrain> but that is not an actual question I can answer without doing the work 🙂
21:43:42 <Bouke> truebrain: Not having it on a PR is a pity, as immediate feedback is better than a daily aggregate.
21:44:18 <truebrain> we do have to be careful that it doesn't become: THOU SHALL NOT DECREASE PERFORMANCE 😛
21:48:08 <Bouke> Easy enough to blame it on variance 😉
21:50:23 <truebrain> and .... another recompile. lol
21:53:00 <Bouke> Bouke: Or have it on the PR anyway, and 🤷🏼♂️ when your server is unavailable. We could even have Andy’s MBP as fallback.
21:59:52 <_jgr_> It could be due to InternalExecutePrepTest not rejecting things which it previously did?
22:00:06 <_jgr_> Which then go on to consume cycles
22:00:07 <truebrain> oeh, good questions; let's test
22:00:30 *** keikoz has quit IRC (Read error: No route to host)
22:06:28 <talltyler> truebrain: No rush, but I pushed a commit splitting the timers for you to look at. I get a "no instance of constructor matching the argument list" error everywhere I try to create a new timer...and I can't even find the constructor! 😄
22:06:45 <talltyler> No rush, but maybe you can point me to what I'm missing... 🙂
22:06:56 <talltyler> It's time to make dinner so I'm taking a break anyway
22:07:52 <truebrain> I think you also moved too much 🙂 You need to remember that in the end you want Economy to come in two forms, with slightly different behaviour
22:08:01 <truebrain> so some duplication is to be expected
22:08:06 <truebrain> but that is easy to say from a distance, so *shrug*
22:09:03 <truebrain> anyway, way to tired to actually process what you did in a useful way 😛 So maybe someone else can help you out here 🙂
22:12:02 <talltyler> Ah moving `struct TPeriod` back into the child classes seemed to fix it 🙂
22:19:24 <truebrain> _jgr_: I liked the idea, but that function is also only called once .. I must be doing something else wrong here 😛
22:32:49 <truebrain> small changes take ~10 minutes before it is compiled again .. LTO is killing me 😄
22:36:20 <talltyler> Ah heck, I got it to compile, then rebased, and now I have 316 unresolved external symbols... 😬
22:36:39 <truebrain> you forgot your cmakelists.txt changes? 🙂
22:43:38 <truebrain> this commit ..... for sure it is the change in InternalPost, but it is called once, and it passes ...
22:43:52 <truebrain> I can't find a normal explanation 😛
22:49:21 <truebrain> the `tile >= MapSize() || ` is btw cute; `IsValidTile` also does that 😛
22:51:58 <_jgr_> tile >= MapSize() still needs to be checked even for the CMD_ALL_TILES case
22:52:12 <truebrain> yeah, so reordering the if-statement would be more efficient
22:52:19 <truebrain> but still, from what I can tell it is called once .. so ...
22:52:25 <truebrain> why is it having such trouble with it?
22:54:05 <truebrain> it could be some weird command that is prevented by this check, but it doesn't even return 😛
22:59:03 <truebrain> if I make the if-statement a bit smaller, it doesn't slow down as much .. lol
22:59:24 <_jgr_> Is it all the saves that see a change on that commit or just some of them?
23:00:01 <truebrain> they are the ones that run relatively shorter, so it might be some savegame loading overhead
23:00:09 <truebrain> but still, I wouldn't expect that if-statement to influence it 😛
23:01:36 <truebrain> also weird that in master this behaviour doesn't exist, but I don't see anywhere where the performance is regained .. and as it is pretty visible, I would have expected that
23:01:55 <truebrain> although ofc it could be during another change
23:02:07 <truebrain> just weird 😛 I don't like weird 😄
23:03:01 <truebrain> I can understand if that if-statement makes the function too big so compilers don't inline it or something .. but that would require more than one call 😛
23:09:18 <truebrain> if I force-inline it, I get my performance back
23:09:29 <truebrain> so that if-statement pushed it over the threshold of this compiler I am using
23:10:24 <truebrain> let's see what it does on master
23:10:37 *** debdog has quit IRC (Ping timeout: 480 seconds)
23:14:18 <talltyler> Trying to compare before and after the rebase but my git skills aren't quite good enough
23:19:52 <truebrain> force inlining it in master doesn't make a real difference. Owh well, I guess at least that somewhat explains it 😛
23:20:11 <talltyler> Somehow git diff keeps showing me code from...master?
23:20:24 <talltyler> Even when I give it commit hashes from reflog
23:22:27 <talltyler> Maybe it's easier to see what I missed when I can view commits online
23:24:44 <truebrain> ah, I didn't actually disable linkgraph as I hoped; the settings can't be large enough to make that happen
23:26:13 <talltyler> Aha, that might be it
23:26:26 <truebrain> all 4 distribution modes are on manual
23:26:31 <truebrain> guess that means linkgraph is also not doing anything?
23:27:41 <truebrain> why is Autosave both in settings and in game options? Weird
23:31:30 <_glx_> talltyler: maybe you should try "github desktop"
23:34:35 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:35:35 <_jgr_> truebrain: The settings for these are stored in the savegame, so changing it in the config won't have any effect
23:36:04 <_jgr_> If the savegame had any pending jobs they'll be started straight away on load as well
23:36:19 <truebrain> but when everything is on manual, they don't restart, right?
23:36:48 <truebrain> tomorrow I will check if any jobs are pending in that savegame .. would explain a thing or two 🙂
23:37:20 <_jgr_> If it's manual it shouldn't start any jobs
23:39:12 *** _aD has quit IRC (Ping timeout: 480 seconds)
23:45:44 <talltyler> Okay, fixed it! That's enough for today. 🙂
23:51:05 *** ChanServ sets mode: +v tokai
23:57:52 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
23:58:04 <_jgr_> truebrain: Actually, looking at the code, it seems the jobs are run anyway, they just don't have as much work to do
continue to next day ⏵
