IRC logs for #openttd on OFTC at 2024-02-11
⏴ go to previous day
00:39:24 <truebrain> For some reason OpenTTD is top in Hacker News, but not because of the blog or something .. the About page is linked
00:42:17 <peter1138[d]> Cesspit of the Internet.
00:43:04 <_jgr_> If you think HN is the cesspit of the internet, you'll be in for a shock when you explore the rest of it 😛
03:16:01 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:18:56 *** gnu_jj_ has joined #openttd
03:22:30 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:33:41 *** Wormnest has joined #openttd
03:49:37 *** Wormnest has quit IRC (Quit: Leaving)
04:51:07 *** Tirili has quit IRC (Quit: Leaving)
07:26:51 <Rubidium> ah, you don't read the backlog either ;)
07:27:21 <merni> seems people think unbunching is only for RVs
08:07:04 <Eddi|zuHause> well, train didn't usually need any unbunching because the iignal distance takes care of that
08:10:40 <merni> you don't always want trains following one block apart either, though
08:19:13 <Eddi|zuHause> but that makes the issue so much less pronounced, that i never felt the need for handling it in any way.
08:25:12 <reldred> Autospacing trains has been a mainstay of building passenger train networks of any great size in my jgrpp games for just about forever. Cargo has never warranted it, but pasenger train routes definitely.
08:32:27 <jfs> yeah I think a longer following distance will mean that average speed increases (and so should payments too), since there won't be as much contestation on signals around stations, especially if you have terminus stations
10:00:33 <andythenorth> Unbunching ships is the secret weapon
10:01:13 <andythenorth> Pax ships will 100% overlap positionally in a shared order group of identical vehicles
10:01:46 <andythenorth> Not that it matters, just visually weird
10:02:10 <Eddi|zuHause> that i can see, if you try to avoid using full load.
10:05:52 <andythenorth> Or with cdist abd capacity > waiting
10:08:27 <peter1138[d]> Have the rising income text of other companies always been visible?
10:10:41 <peter1138[d]> Seems to me like it's not something that should happen.
10:11:10 <truebrain> Unlike real life, you can see all the details of other companies financials
10:11:29 <truebrain> Including their net worth, what they spend, how much loan
10:11:39 <truebrain> So why does income text surprise you? 🙂
10:11:47 <merni> well, isn't that something you can do in real life too?
10:13:43 <truebrain> Me saying "all the details" .. you saying "to an extent" .. I think you answered yourself 😉
10:14:06 <merni> well, the details of the finance that you can see in ottd should be visible for irl public companies too
10:14:15 <merni> the finance window only shows very general classifications
10:14:25 <merni> of course, floating income text is a different matter :p
10:14:40 <peter1138[d]> My question isn't really about "should we be able to see their income?" it's more "why would I want to see their income?"
10:14:55 <truebrain> More sensible question 😛
10:15:11 <truebrain> I think you also see the loading indicators etc, not?
10:15:46 <truebrain> But thinking about it, it would be funny to have a mode that shares less information of other companies
10:15:59 <truebrain> How full trains are, how many trains there are, their profits, etc
10:16:15 <peter1138[d]> As in, no you don't see their loading indicators.
10:16:24 <truebrain> Ah; that does surprise me
10:17:33 <truebrain> merni: You are thinking to narrow here .. you can see the profit of every individual train .. Good luck doing that in real life 🙂
10:25:08 <truebrain> peter1138[d]: code suggest you shouldn't see the income of another company; so that is lovely odd 😄
10:25:24 <truebrain> well, in 2 out of the 3 places it checks for local company
10:26:43 <truebrain> ah, no, autoreplace isn't shown
10:27:25 <andythenorth> I miss the rising income texts 😛
10:28:08 <truebrain> Guess where we got posted on HN? 😄
10:28:54 <peter1138[d]> andythenorth: Is that because you don't play it?
10:29:02 <andythenorth> Hmm the slowest thing in Horse compile is finding free ID slots
10:29:14 <truebrain> nice benchmark in #12055, lol; that is a heavy difference
10:29:28 <truebrain> how much more memory usage is the bitmap?
10:30:35 <peter1138[d]> It's a bit per slot.
10:31:03 <peter1138[d]> If you have 100,000 vehicles, the bitmap takes 12500 bytes. And the pool of pointers (not the actual items) takes 800000 bytes.
10:31:30 <truebrain> okay, and more importantly: it grows when the pool grows
10:31:35 <truebrain> that was more what I was asking for 🙂
10:31:50 <peter1138[d]> Yes it grows with the pool.
10:32:09 <peter1138[d]> Unlikely JGR's version, my version doesn't force the pool growth to 64 items.
10:32:38 <andythenorth> Could we support loading indicator definition in grf?
10:32:50 <truebrain> and you just apply this on all pools
10:33:03 <peter1138[d]> Yes, that's a bit wasteful, but makes it simpler.
10:33:10 <truebrain> not sure it is actually wasteful
10:33:11 *** uhuame has quit IRC (Read error: Connection reset by peer)
10:33:23 <peter1138[d]> But also, CargoPacket pool probably benefits too.
10:33:35 <truebrain> yeah, and if someone wants to build a lot of stations, it helps too 😛
10:33:43 <truebrain> and all that for 1/64th increase in memory
10:33:52 <truebrain> on the pools pointer-data, ofc
10:34:08 <truebrain> so compared to the actually data, that is nothing 😄
10:34:10 <peter1138[d]> I should add a note about memory.
10:34:22 <peter1138[d]> Would've "saved" these questions 🙂
10:34:24 <truebrain> I was just too lazy to look at the diff 😛
10:36:24 <truebrain> seems like a worth-while change to me 🙂 I like how simple some of these things can be 🙂
10:36:33 <truebrain> especially as this has been talked about for years 😛
10:38:03 <truebrain> so HN caused 10 times as much load on the website than normal .. and Cloudflare ofc handled that just fine, without any issues. Still funny how many people read such articles and click through 🙂
10:38:21 <peter1138[d]> Would andy's MBP have coped?
10:39:03 <truebrain> in peak it was ~150 requests per second
10:44:39 <truebrain> lot of positive responses on the blog post on Steam
10:44:39 <andythenorth> The MBP was fine, I disabled the AV
10:44:57 <truebrain> mostly amazement that 20 years later the game still gets new features
10:45:36 <peter1138[d]> It is surprising the Minecraft still gets new features, 14 years later.
10:45:46 <truebrain> without additional costs, yes
10:45:56 <peter1138[d]> Oh sh.., how did Minecraft get to be that old...
10:46:00 <truebrain> I expected them to want to grab even more money
10:46:59 <_jgr_> I suppose open plan/sandbox type games like these are easier to keep adding things to, unlike your more typical story-driven games
10:47:50 <truebrain> I am shocked most mods still update for newest version 😛
10:47:51 <andythenorth> There’s always another craftable material to invent 😛
11:13:43 <truebrain> here I was thinking 12055 was a simple solution *shrugs*
11:15:10 <truebrain> haha, I am looking into if I can fix a problem with older clients falling back to TCP for BaNaNaS, which requires me reading more of the old tcp_http .. I found the reason why the UI is sometimes not responsive .. not useful anymore, but at least I found out why 😛
11:15:12 <jfs> if it works and is not worse (apart from possible pathological cases) then go for it
11:15:19 <jfs> and then we can bikeshed it later
11:16:18 <jfs> not letting perfect be the enemy of good etc
11:16:27 <_jgr_> I doubt that there any pathological cases TBH
11:17:47 <_jgr_> This sort of pattern is really not new at all
11:19:31 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
11:20:05 <truebrain> the only question is ... do we add this to 14.0? 😄
11:20:16 <truebrain> (this late in the release-cycle)
11:22:47 <locosage> wonder if iterating bitmap from the end is faster...
11:23:10 <locosage> also it can probably made into something like fenwick tree for log(n) search
11:23:23 <locosage> though at this point any possible gains are probably irrelevant
11:24:00 <_jgr_> That is severe overkill for "find an empty slot in a given range"
11:25:41 <locosage> wouldn't call an overkill something that barely adds any code
11:25:42 <peter1138[d]> A std::set of free items might be faster to allocate a free item, but could use more time managing the set than this bitmap way.
11:25:49 <locosage> fenwick tree is basically a one-liner
11:25:55 <peter1138[d]> And deleting a lot of vehicles at once could result in a big set.
11:26:19 <_jgr_> std::set is really not a fast structure, and it uses a lot of memory
11:29:12 <_jgr_> Though the upside is that you get ordering for free
11:29:31 <_jgr_> So getting the first free is O(1)
11:29:33 <peter1138[d]> Anyway, I say "I have not" because if you want to try it go ahead 🙂
11:30:31 <truebrain> I agree with jfs , we can always bikeshed some other time. The improvements that PR introduces are insane, so on its own already worth it. Can it be better? Sure. Useful to talk about that for weeks? Nah 🙂
11:31:57 <peter1138[d]> It's faster, but it takes an extreme savegame to be really noticable.
11:32:22 <locosage> _jgr_: getting min in std::set is log(n) iirc
11:32:36 <locosage> it's a tree, not a heap xD
11:32:59 <peter1138[d]> Maybe it would be noticeable in Wentbourne if it used steam engines 😄
11:33:56 <_jgr_> locosage: std::set::begin() is supposedly constant complexity
11:34:26 <locosage> ok, getting it may be constant, removing it likely isn't
11:35:39 <peter1138[d]> So basically what I said.
11:37:34 <andythenorth> 5 weeks ish until 14.0?
11:37:44 <andythenorth> Ship the change 😛
11:41:01 <peter1138[d]> Fairly big set already.
11:41:23 <peter1138[d]> But that jump from 13471 to 477673...
11:41:32 <locosage> is that a normal game/
11:41:43 <peter1138[d]> It's a Xarick game.
11:42:53 <peter1138[d]> I can't directly compare benchmarks as the time is consumed elsewhere.
11:43:03 <locosage> well, I guess better question to ask is that vehicle buy/sell or just effects?
11:44:08 <peter1138[d]> Wentbourne... because Maglev...
11:44:10 <johnfranklin> I found a "scale cargo aging" pr
11:45:06 <xarick> there are more vehicles than packets?
11:47:05 <locosage> oh, yeah, 680k vehicles, is that all bloody effects? xD
11:47:18 <locosage> they need their own pool :p
11:47:46 <_jgr_> If effects were moved out of the vehicle pool then ordering of them wouldn't matter at all
11:48:19 <_jgr_> So you wouldn't necessarily have to use a pool for them
11:48:47 <johnfranklin> Is openttd programmed by C++20
11:49:07 <locosage> yeah, it's juts where else to put stuff in openttd if not a pool xD
11:50:00 <xarick> my goal is 1 million vehicles
11:50:29 <merni> johnfranklin: yes, since last month
11:50:47 <johnfranklin> I bought the right book
11:51:40 <merni> That seems like a highly expensive book for something that would be better learned online
11:51:58 <johnfranklin> online learning sucks
11:52:08 <merni> And honestly, I never "learned" C++ as such... started with C and picked up the additions in C++ as I went
11:52:22 <merni> johnfranklin: Yes, but you need to be careful about the quality of books
11:52:55 <merni> I learned C from K&R and another book I forgot the name of, but there are any number of books that parrot objectively wrong or bad code
11:53:00 <merni> Especially non-English books
11:53:42 <locosage> I remember when I was young my parents gifted me a c++ book that was just a print out of C++ formal grammar
11:55:09 <peter1138[d]> Is it possible to template a template... 😮
11:55:34 <locosage> but, yeah K&R, Stroustrup, Meyers are a classic
11:55:51 <johnfranklin> CNY 259.8 ~ USD 35
11:57:51 <merni> That's a lot by Indian standards, though probably cheap by American standards for a textbook
11:58:22 <_jgr_> Whether you start learning from a book or online, the important part is doing/practice, not really the source
11:59:10 <merni> But there are some C books which encourage styles which are errors/discouraged in standard C
11:59:22 <merni> In particular `void main()`
11:59:53 <merni> And also a lot of unclear explanations about things like pointers
12:00:04 <locosage> by my standards I'm not keeping a book even if I get paid 35 USD for that xD
12:00:31 <_jgr_> merni: The problem is that there isn't just one "standard C" 😛
12:00:48 <merni> well, "any recent ISO standard"
12:01:26 <merni> Actually I don't think any historical ISO C standard has permitted that particularly egregious example
12:06:00 <truebrain> that moment your Internet connection is too fast to do decent testing for network issues 😛
12:06:12 <xarick> train ticks got better, road veh ticks... not really, something else's going on?
12:11:58 <truebrain> _jgr_: as you originally looked into the above issue, mind giving it a look if this still resolves the original issue?
12:12:46 <truebrain> sadly, that PR still doesn't help me in reducing the TCP downloads for BaNaNaS .. I still have no clue why there are so many 😦
12:13:08 <truebrain> (11% of the downloads are via TCP, instead of HTTP, which costs us a lot of money every month)
12:13:46 <truebrain> maybe I should just remove `no_http_content_downloads` .. or force-reset it to false for everyone .. I dunno
12:15:06 <peter1138[d]> xarick: road vehicles don't produce effect vehicles like trains do.
12:15:40 <peter1138[d]> Shouldn't really be slower though, but it depends what the AIs decided to do.
12:19:16 <xarick> where have I seen this before?
12:19:55 <xarick> I suspect levelcrossings...
12:20:17 <xarick> now identifying where...
12:22:09 <xarick> previously, these sudden spike increases, decreases were related to constant pathfinder calls
12:22:35 <xarick> but not like this, where trains go up and roads go down at the same moment
12:26:12 <peter1138[d]> Trying to make equivalent benchmarks between bitmap and set versions of free items.
12:29:44 <xarick> does checking collisions also look through effect vehicles? do they occupy space?
12:32:17 <peter1138[d]> bitmap seems to be faster than set for wentbourne.
12:37:04 <locosage> with 2 free items and 85k vehicles? weird
12:37:24 <locosage> though I guess iterating thousand ints is very fast
12:37:40 <locosage> especially compared to rb tree
12:38:07 <locosage> so it's more of a memory save than time
12:38:41 <locosage> wonder if std::set is optimized for a low item count
12:39:14 <locosage> for a few dozen items vector is probably faster
12:41:09 <peter1138[d]> I don't iterate the set at all, but insertion and removal (which will only be the first item) are presumably the costly things.
12:42:02 <locosage> hm, is there a heap in std:: nowadays?
12:43:23 <_jgr_> locosage: The heap stuff in algorithm is still there
12:43:38 <peter1138[d]> With Xarick's save, the set version is faster, but move of the time is moved to FreeItem as it inserts into the set.
12:44:19 <_jgr_> locosage: std::set is not optimised in any such way, the guarantees promised by the spec don't allow it
12:44:38 <peter1138[d]> Hmm, actually no, bitmap is still faster overall.
12:45:25 <peter1138[d]> No that was wrong, set is faster overall but not by as much as GetNew appears.
12:45:54 <locosage> _jgr_: yeah, then overhead is probably eating all algorithmic advantage
12:45:55 <peter1138[d]> I know std::set is not optimised, but it's a lot quicker to prototype than implementing a custom container thing...
12:46:10 <locosage> you can use std::vector with heap stuff
12:46:14 <peter1138[d]> Of course, the benchmark is therefore useless.
12:46:57 <peter1138[d]> We do have SmallSet though. Hmm.
12:47:18 <peter1138[d]> Okay, that is pathfinder only.
12:47:31 <peter1138[d]> Oh, Signals only.
12:47:34 <peter1138[d]> It's not generic 🙂
12:48:25 <peter1138[d]> I assume there's no reason to bother trying a std::list.
12:49:57 <locosage> try heap, that should be fast
12:50:10 <locosage> list will probably get beaten by vector anyway
12:50:11 <jfs> std::list would be the worst of all worlds, I imagine
12:52:02 <peter1138[d]> C++ heap stuff? Seems a bit weird, built on top of vector but lots of sorting.
12:52:50 <locosage> well, that's how heap is traditionally done
12:53:11 <locosage> idk why stl didn't wrap it in its own container but it's basically vector + heapify function anyway
12:53:16 <_jgr_> You can use whatever container you want, it doesn't have to be a vector
12:53:35 <_jgr_> That's why it's in algorithm and not its own container type
12:53:57 <locosage> why would anyone use it on non-vector?
12:54:18 <locosage> well, I guess some vector-like-but-not-vector make sense
12:56:10 <peter1138[d]> Examples of how to use the heap functions are a bit lacking.
12:56:23 <locosage> the weirdest one is std::sort_heap, sort that only works on a heap but has the same complexity as normal sort xD
12:56:43 <_jgr_> truebrain: I was testing before by downloading the GETS GRF, it still seems to download fine with that PR
12:56:49 <peter1138[d]> Filling a vector, then calling make_heap, then calling pop_heap, then exiting. Is not a good example.
12:56:51 <locosage> well, technically I guess there are some savings it can do...
12:57:16 <locosage> you probably start with empty vector so no need for make heap
12:57:35 <locosage> for removal get front, use pop_heap and vector pop_back
12:58:43 <locosage> insert is push_back + push_heap
12:59:36 <locosage> it all makes sense if you ever written a heap yourself
12:59:46 <locosage> if not, yeah, probably not much xD
13:01:35 <locosage> all those heap functions basically just call heapify that compares element to parent, swap if needed and recurses to parent
13:02:07 <locosage> minimal implementation is like 5 lines of code for the whole structure xD
13:04:39 <_jgr_> There is an existing example in the implementation of ScriptPriorityQueue
13:07:25 <locosage> oh, yeah, and there is std::priority_queue as well
13:08:11 <locosage> I always forget it has another name
13:20:00 <xarick> EnumCheckRoadVehClose is heavy
13:20:33 <xarick> more precisely, this thing: RoadVehFindData *rvf = (RoadVehFindData*)data;
13:34:28 <peter1138[d]> push_heap/pop_heap performs better than set, but worse than bitmap with Wentbourne.
13:34:59 <peter1138[d]> For Xarick's crazy save, heap is a clear winner.
13:35:08 <peter1138[d]> But... it's a max-heap not a min-heap.
13:35:10 <peter1138[d]> I need to fix that.
13:37:49 <talltyler> Sorry peter1138[d], this is a weird one
13:52:06 <peter1138[d]> Bah, everything useful is optimized away.
13:52:11 <peter1138[d]> Debug variant ahead...
13:54:18 <peter1138[d]> I guess using max-heap instead of min-heap would be desync-causing too.
13:56:33 <truebrain> not a step closer to understand why so many downloads happen over TCP .. am I just going to bet that 14.0 solves it by using HTTPS?
13:56:40 <peter1138[d]> talltyler: Hmm, you have the same cargo accepted twice.
13:57:01 <peter1138[d]> That apparently doesn't phase industries themselves.
13:58:18 <peter1138[d]> Industry Chains window goes by the spec's properties and doesn't use callbacks (those callbacks are only valid for an instance of the industry)
14:06:56 <peter1138[d]> (Of course, it could be my recent changes)
14:11:56 <_glx_> path to your openttd.exe is funny talltyler, for me B: will always be a floppy drive in my head
14:12:43 <truebrain> wait, he uses `B:`? HOW?! 😄
14:14:21 <peter1138[d]> Thanks but I didn't really need to see the Windows stack trace to find this :p
14:16:59 <peter1138[d]> Although vs code did crash.
14:18:40 <peter1138[d]> \[2024-02-11 14:18:21] dbg: [grf:0] [54540401-improved_town_industries-2.9.tar/improved_town_industries-2.9/improved_town_industries.grf:0] Industry 5 accepts 9 more than once
14:18:49 <peter1138[d]> That's...not that useful, but confirms it at least.
14:22:05 <peter1138[d]> Ah, maybe it's not the steel mill.
14:22:31 *** m1cr0man has quit IRC (Quit: G'luck)
14:23:35 <peter1138[d]> Building Materials Factory
14:23:39 *** m1cr0man has joined #openttd
14:24:07 <peter1138[d]> I don't know what the intention is, but with my fix that's what it accepts.
14:26:36 <peter1138[d]> 13.4 on the brain
14:38:21 <peter1138[d]> AAAHogEx really doesn't like MAIL not existing.
14:38:33 <peter1138[d]> But that's a buggy AI 🙂
14:41:02 <frosch123> poor `std::vector<bool>`. noone likes it 🙂
14:43:42 <_jgr_> As I understand it, the consensus is that std::vector<bool> was not a good idea, but it can't be removed now for backwards compatibility reasons
14:43:56 <truebrain> wasn't it frosch123 too that said to never use that? 😛
14:44:48 <truebrain> I love the wording of std::vector<bool> ... "The manner in which std::vector<bool> is made space efficient (as well as whether it is optimized at all) is implementation defined"
14:44:57 <frosch123> it's most likely no good solution here either. it's just funny that people in 1998 thought it would be
14:45:01 <truebrain> like ... either you are screwed or it is the best thing ever, I dunno, figure it out, who knows! 😛
14:45:48 <frosch123> most imporantly i don't think there is a good way to find the first set/unset bit in a vector
14:46:41 <truebrain> no `.find(false)`? 🙂
14:46:47 <_jgr_> If you have a std::vector<T> in a template somewhere, and someone innocently passes in T = bool expecting actual bools that you can get pointers too, you can get all sorts of wacky failure modes
14:47:15 <truebrain> _jgr_: oof ... now that is painful
14:48:06 <frosch123> I have seen plenty `std::vector<uint8>` to store booleans, for that reason
14:48:23 <Rubidium> _jgr_: effect vehicle pool ordering is important due to BubbleTick using random :(
14:54:12 <andythenorth> peter1138[d]: Wait, that’s not FIRS. Not meme conpliant.
15:01:14 *** MrDowntempo has quit IRC (Quit: Page closed)
15:25:26 <peter1138[d]> Rgith, std::priority_queue?
15:40:44 <peter1138[d]> Hmm, okay, priority queue is slower than vector + heap methods.
15:41:32 <xarick> maybe we're looking at the wrong performance
15:41:35 <locosage> std::priority_queue? I thought it just wraps heap methods
15:42:14 <xarick> cargopackets doesn't seem to be affected much
15:42:19 <peter1138[d]> Well, the other difference is this was set to use std::less, but the heap method is a max-heap, so it's not actually the same result anyway. Hmm.
15:43:07 <peter1138[d]> Hmm, so I broke regression :S
15:44:07 <_jgr_> std::less is the default for priority_queue, which also gives a max-heap?
15:44:32 <peter1138[d]> I'm still using a debug build 😦
15:47:53 <peter1138[d]> if (!IsValidCargoID(*it)) hs->cargo_acceptance[i] = 0;
15:48:00 <talltyler> peter1138[d]: I don’t see where the duplicate cargo acceptance is coming from
15:48:11 <talltyler> In my NML source, I mean
15:48:27 <peter1138[d]> Building Materials Factory?
15:48:57 <talltyler> Yes, I only see STEL once
15:49:40 <peter1138[d]> Is it based on the factory? The 3rd slot defaults to steel for that.
15:50:17 <talltyler> Oh, it’s inheriting slots from the vanilla industry
15:50:23 <talltyler> That’s … interesting
15:50:43 <peter1138[d]> I don't think that's new behaviour.
15:50:50 <peter1138[d]> But I might have messed it up?
15:51:01 <talltyler> No, it just wasn’t a problem before I guess 🙂
15:52:02 <talltyler> Although I think if an author sets the cargo_types propriety, also inheriting whatever was there before is almost certainly undesired by the author
15:52:33 <talltyler> Because there’s no way for me to manually clear those slots
15:52:43 <peter1138[d]> Yes, might be a bug here 🙂
15:54:40 <_glx_> peter1138[d]: still fails
15:54:47 <peter1138[d]> No, it's another line 🙂
15:55:04 <peter1138[d]> It's "how the feck did that happen" error.
15:55:59 <peter1138[d]> talltyler: #12060 fixes that issue already.
15:59:14 <peter1138[d]> Huh, no, some other revision. My environment is confusing me 😦
16:00:49 <peter1138[d]> It should not be showing #12060 there!
16:01:23 <peter1138[d]> But anyway, I realise I missed some, and now accidentally included them in 12060 because I thought that's where they were done for the others for a moment :/
16:01:49 <_glx_> but 12060 now pass regression
16:03:08 <peter1138[d]> Yes, it's correct, but some of it should probably be a different PR.
16:03:15 <peter1138[d]> But... meh, it's all related.
16:06:49 <peter1138[d]> A user-provided Compare can be supplied to change the ordering, e.g. using std::greater<T> would cause the smallest element to appear as the top().
16:07:00 <peter1138[d]> I should read the documentation better 😄
16:13:10 <peter1138[d]> Hmm, problem with the heap method is it gets huge when items are deleted.
16:13:54 <jfs> yeah I could imagine that. and then you would have to add logic to put ranges into the heap instead and merge those when appropriate
16:15:07 <jfs> the bitmap might not have the best case time or memory complexity, but at least it has very predictable performance in all cases
16:19:34 <peter1138[d]> free_items size = 22546 Hmm
16:19:50 <locosage> you mean deleted like mass sell of vehicles or effects get deleted in waves or smth?
16:20:00 <peter1138[d]> Still only a fraction of the pool pointers though.
16:20:24 *** Wormnest has joined #openttd
16:20:30 <locosage> if it's something extraordinary can just cap heap size and fall back to iteration if it runs out
16:21:35 <peter1138[d]> That sounds like implement two methods and then trying to work out which is appropriate to use.
16:21:41 <locosage> if it's still less than pool size / 8 I guess it's a win compared to bitmap xD
16:23:40 <xarick> `Company::Get(old_owner)->money = UINT64_MAX >> 2; // jackpot ;p`
16:23:40 <xarick> shouldn't this be INT64_MAX instead?
16:23:41 <jfs> the heap can be of indexes, right? which are only 16 bit, unlike the pool itself which has 32 or 64 bit items (pointers)
16:24:57 <locosage> there are larger than 16 bit indexes
16:25:26 <jfs> ah right, I was only thinking of the vehicle pool, but there's also things like the cargo item (?) pool
16:26:22 <peter1138[d]> VehicleID is uint32_t anyway.
16:26:22 <_jgr_> The acrgo packet pool also uses 32 bit indices
16:27:05 <peter1138[d]> So absolutely worst case is the heap is half the size of the pool pointers (but not the pool data itself)
16:27:29 <peter1138[d]> With the bitmap, it's always pool count / 8.
16:28:16 <locosage> well, free list was never about worst case...
16:32:22 <peter1138[d]> Knowing the worst case is useful for evaluating solutions.
17:02:51 <peter1138[d]> Split them up properly now.
18:00:18 *** gelignite has joined #openttd
18:18:22 <_glx_> peter1138[d]: the numbers are correct ???
18:19:56 <peter1138[d]> I'm just collating some stats of more normal usage.
18:20:14 <truebrain> BuT iT cOsTs So MuCh MeMoRy
18:20:44 <peter1138[d]> I saved memory by using a `VehicleID` instead of a `Vehicle *` 😉
18:21:09 <_glx_> and by luck it might fall in some padding
18:21:11 <peter1138[d]> (That's actually because Vehicle::GetIfValid(index) is safer than trusting a pointer...)
18:23:20 <_jgr_> I didn't think that the difference would be that dramatic TBH
18:23:59 <_jgr_> I took the approach of just not doing the scan if there are no disaster vehicles at all, but this works when there are some as well
18:26:17 <_glx_> hehe was about to ask the same
18:28:51 <peter1138[d]> 500ms for each autoreplaced vehicle in Wentbourne is quite significant.
18:29:16 <peter1138[d]> I think "don't target the same vehicle" is a reasonable approach.
18:29:59 <peter1138[d]> Total number of targetable road vehicles isn't quite right though.
18:30:08 <_glx_> and it's "free" to detect that now 🙂
18:32:06 <Rubidium> I'd just do "if (this vehicle already targetted) {delete v; return false;}"
18:32:36 <Rubidium> just like when there's no vehicle, as you have to be extremely lucky to get into that situation
18:33:07 <peter1138[d]> It could just go around again next tick.
18:34:51 <DorpsGek> - Update: Translations from eints (by translators)
18:38:34 <peter1138[d]> But delete is simple enough.
18:39:11 <peter1138[d]> Caveat: I'm not sure I actually have a save game with small UFOs targetting a road vehicle... let alone two targetting one vehicle.
18:39:18 <peter1138[d]> Hmm, I can probably concoct one though.
18:40:06 <LordAro> ...no idea how i requested a review
18:41:15 <peter1138[d]> I hacked the game to spawn small UFOs every tick once.
18:41:18 <peter1138[d]> Where did I do that.
18:43:18 <peter1138[d]> DoDisaster() will do.
18:49:00 <peter1138[d]> Yay, found a bug.
18:51:16 <peter1138[d]> And other weirdness.
19:01:53 <locosage> another way would be to just get disaster vehicles their own pool
19:02:59 <locosage> though if disaster vehicles get sriptable it may need to get optimized anyway
19:21:49 <andythenorth> did we we make openttd build faster?
19:21:58 <andythenorth> seems to be completing quickly for me
19:22:20 <Rubidium> I did something a long while ago
19:29:14 <truebrain> can someone please redesign the Content Service window thingy ... it is very annoying to find base sounds 😛
19:31:01 <truebrain> code-wise, I feel to see the relation between sounds player and resolution changing .. but okay
19:32:24 <peter1138[d]> Oof, yeah, I can't delete a vehicle there. Oops.
19:38:04 <truebrain> I always forget how fast the game is, until I start a non-debug version 😛
19:43:33 <truebrain> okay, that is by far the funniest bug I have looked at in a while 😄
19:45:26 <truebrain> we don't track if hw-accel is actually active or not; just that it is requested to be active 🙂
19:46:01 <truebrain> Should be an easy fix
19:48:07 <peter1138[d]> I once started a patch for that but the rabbit hole was quite deep.
19:49:45 <truebrain> I see two easy routes; curious what I will discover 🙂
19:50:00 *** uhuame has quit IRC (Remote host closed the connection)
19:50:08 <truebrain> I also don't like vsync is "on" when acceleration is off, just because that was the setting
19:53:17 <xarick> disaster vehicle eats performance?
19:54:30 <xarick> oh... effect vehicle was triggering that?
19:55:33 <truebrain> owh, there is already code to make it appear untoggled when HW is off .. it just doesn't work or something 😛
19:55:59 <truebrain> ah, no, DisabledState
19:56:21 <peter1138[d]> xarick: No, just regular vehicle deletion.
19:57:47 <peter1138[d]> It is the main reason why stop_ai takes over a minute in your save.
19:58:22 <peter1138[d]> Maybe I should get a ThreadRipper 😄
19:58:39 <peter1138[d]> Or whatever the fastest stuff is these days.
20:02:12 <peter1138[d]> Ah yes, the rabbit hole was active settings vs saved settings, etc...
20:02:17 <locosage> GetNew for bitmap being faster than heap is kinda sus
20:02:25 <locosage> that's O(n) vs O(log(n))
20:02:41 <locosage> fast operations in both cases...
20:02:53 <Rubidium> it's "random memory access" vs "linear memory access"
20:03:13 <Rubidium> and don't forget that insertions to the heap are O(log(n)) too
20:03:19 <michi_cc[d]> Linear memory scans will probably be cached the most efficient by any recent processor.
20:03:25 <locosage> it's not random, it's linear from the back with skips
20:03:37 <peter1138[d]> This is testing the whole GetNew/FreeItem functions, not just the access to the bitmap / heap.
20:04:06 <peter1138[d]> So yes, memory access latency could play a part in it.
20:04:37 <peter1138[d]> And of course my testing could be wrong.
20:04:48 <Rubidium> locosage: that's random, as you'd likely be hitting a different cache line for each check
20:05:52 <locosage> no it's not, you're still reading in linear order, just skipping some values
20:06:18 <Rubidium> even then O(log(n)) vs O(n) says *nothing* about the overhead of the algorithm for small cases
20:07:04 <peter1138[d]> You can put the same TicTocs in to master and the PR to do comparisons.
20:07:17 <locosage> heap has very little overhead, it's one comparison and one assignment
20:07:52 <locosage> it might be something about the nature of values
20:08:09 <locosage> like if it mostly frees and gets a few items at the start of the pool
20:08:28 <locosage> so bitmap never rly needs to iterate anywhere far
20:08:59 <peter1138[d]> I've done my benchmarking. Feel free to do your own benchmarking.
20:09:00 <truebrain> lolz, WSL DirectX vsync is trying to be insanely quick 😄 500fps ... sounds unreasonable 😛 But also not something we do 🙂
20:09:21 <peter1138[d]> That's more useful that suggesting it should be faster.
20:09:43 <peter1138[d]> (I should be faster on my bike... sadly I have to put effort in for that too...)
20:12:39 <peter1138[d]> 1) These benchmarks are not testing just the "find next free index" algorithm, it's the whole of GetNew and FreeItem. 2) They are averaged over about 100,000 requests, so aren't one-off flukes. 3) The savegames tested are NOT very representational, if you can test a wider suite, do so.
20:13:14 <xarick> I am trying a better savegame
20:13:38 <peter1138[d]> It's quite useful for testing, but it isn't representational 🙂
20:17:00 <peter1138[d]> Okay, Reddit Server 1 game. Let's see.
20:20:01 <locosage> how reliable TicToc even is?
20:20:15 <locosage> high_resolution_clock doesn't look like something I'd trust with performance measures
20:21:02 <locosage> doesn't even seem to be guaranteed monotonic
20:29:11 <truebrain> frosch123: hahaha, especially the automatically moving around of rail is epic 😄
20:29:51 <peter1138[d]> Testing master again...
20:31:24 <peter1138[d]> And then maybe I should look at the industry production thing that saved some memory.
20:33:47 <locosage> I never used TicToc xD
20:35:21 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:35:33 <peter1138[d]> First µs value is the total, second is the average (simple total / count)
20:36:13 <peter1138[d]> The TicToc::State uses 10000, so it sums 10000 measurements then shows the result.
20:36:15 <locosage> yeah, but they just jump randomly between reports and avg is 0
20:36:58 <peter1138[d]> Yes, a small value divided by 10000 does that.
20:37:06 <locosage> well, avg doesn't have precision I guess
20:37:31 <locosage> but total being somewhere between 0 and 1666 says absolutely nothing to me
20:38:01 <peter1138[d]> So the first result could be due to loading the game, which might do something different from normal.
20:38:25 <locosage> there is 1246 when already fully loaded
20:38:32 <locosage> I did zoom the map though...
20:40:44 <locosage> ok, 1246 is on cargopayment, 407 for packet
20:41:57 <locosage> two consecutive reports
20:41:57 <locosage> [2024-02-12 02:08:04] dbg: [misc:0] [CargoPacket GetNew] 7 us [avg: 0.0 us]
20:41:57 <locosage> [2024-02-12 02:08:07] dbg: [misc:0] [CargoPacket GetNew] 430 us [avg: 0.0 us]
20:42:14 <locosage> so it took 7 for the first 10000 and 430 for the second?
20:42:48 <Rubidium> smells like allocating a new chunk in the pool
20:43:12 <peter1138[d]> GetNew may need to allocate the pool.
20:44:02 <locosage> well, I doubt it allocates it all the time but it jumps 0-300 constantly
20:44:35 <locosage> wentbourne is pretty static
20:44:44 <locosage> no ais to mess anything
20:49:00 <peter1138[d]> An actual pivot table, shocking.
20:49:23 <peter1138[d]> Reddit Server 1, obviously no AIs so something much going on other than effect vehicles, autoreplace and cargo payments.
20:50:05 <peter1138[d]> Bitmap giving priority_queue a run for its money there.
20:50:21 <truebrain> and bitmap is preditable (in memory and CPU) 😄
20:50:30 <truebrain> so no weird edge-cases to expect 😉
20:51:32 <truebrain> you can say you made (part of) the game 200 times faster! 😛
20:51:43 <peter1138[d]> Bitmap could use a lot of time if you have a free slot that causes it to keep switching between a low slot and a high slot. That is when it will have to scan more of the bitmap.
20:52:20 <peter1138[d]> Well, I'm doing benchmarking wrong of course, because the heap should always be faster 😉
20:52:45 <truebrain> Nothing applying `1 /` to these numbers doesn't fix
20:53:25 <locosage> peter1138[d]: this is even more sus
20:53:38 <locosage> how can bitmap freeitem be slover than anything else, it's just crlbit
20:59:51 <truebrain> I was wondering why the game was yelling at me to destruct
21:00:42 <michi_cc[d]> As long as it is just yelling and not pressing the button? 😛
21:05:26 <peter1138[d]> xarick: Only because mine didn't get approved yet.
21:05:28 <frosch123> is that the first "codefix" to be merged?
21:05:47 <truebrain> well, merged .. maybe 😛
21:07:20 <truebrain> when a server restarts, the clients are informed, and they will try to reconnect. To avoid the server being hammered all at once by all clients, it spreads them out ... by 1 tick per client 😛
21:08:07 <truebrain> quick, merge, just so my "no" is correct!
21:09:02 <_glx_> truebrain: so the server needs to save the game each tick ?
21:09:16 <truebrain> lolz, yes, that too
21:09:23 <truebrain> and like 1 tick separation is going to do anything
21:09:43 <truebrain> but I think it needs to make a save for every new connection anyway
21:09:43 <_glx_> I think if they join on the same tick it saves only once
21:10:05 <truebrain> we transfer to one client at the time
21:10:25 <truebrain> so no, it will just create a new savegame for each client anyway 🙂
21:11:16 <xarick> 1 save thread per client
21:21:09 <locosage> even with 100k samples this seems to be just measuring some random noise
21:21:11 <locosage> [2024-02-12 02:49:36] dbg: [misc:0] [CargoPacket FreeItem] 0 us [avg: 0.0 us]
21:21:11 <locosage> [2024-02-12 02:50:04] dbg: [misc:0] [CargoPacket FreeItem] 427 us [avg: 0.0 us]
21:23:45 <xarick> the day of 5000 trains * 15 companies will come
21:24:25 <xarick> unless vehicle limit is reached, not sure how many wagons that allows per train
21:25:03 <_glx_> wagons count as vehicles
21:25:23 <Eddi|zuHause> just divide 1mio by 5000 and by 15, and you get the average train length.
21:28:27 <andythenorth> /me paints trains
21:28:38 <andythenorth> is it time to switch to SVG though? 🙂
21:29:42 <xarick> how many effect vehicles are there in that savegame?
21:37:04 <truebrain> frosch123: I change my answer: yes
21:37:38 <LordAro> i suppose eints could just display something "generic" so that translators don't have to worry about specific codes they can't change anyway
21:39:15 <truebrain> are you implying that `{WHITE}` is ignored in translations?
21:41:05 <xarick> I have a new savegame peter!
21:41:35 <truebrain> peter1138[d]: too lazy to search, how can I check if a window is already open? 😄
21:41:47 <truebrain> FindWindowById being a non-nullptr?
21:42:40 <LordAro> truebrain: i'm implying it could be ignored by *translators*
21:42:46 <LordAro> just the positioning is needed
21:43:18 <truebrain> funny; didn't know it ignored the values of translations 🙂
21:43:46 <LordAro> i feel like i am missing something
21:44:00 <truebrain> you are telling me something I didn't know; is that so scary?
21:46:52 <peter1138[d]> truebrain: by id or class
21:47:05 <truebrain> what is the difference? 😄
21:47:16 <truebrain> `WC_NETWORK_ASK_RELAY`, so ID I guess
21:47:22 <peter1138[d]> By Class finds any instance of a window, By Id finds a specific window.
21:47:37 <peter1138[d]> That's a class, I guess.
21:47:48 <truebrain> yes; an ID is a (class, data) pair, I guess
21:48:02 <truebrain> yeah, okay 🙂 Cheers
21:48:11 <peter1138[d]> number is basically userdata anyway 😄
21:48:41 <andythenorth> oops forgot to compile a release build 😛
21:48:49 <andythenorth> reload_newgrfs sooooo slow in debug 🙂
21:51:10 <truebrain> peter1138[d]: is it possible to show a screen above the error window? I guess not?
21:51:55 <peter1138[d]> Oh you mean like Z-order above.
21:52:15 <locosage> high_resolution_clock is just garbage at these values basically.
21:53:25 <Rubidium> locosage: which compiler are you using? Might be useful to know which one have "garbage" high resolution clocks
21:53:43 <locosage> g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
21:54:44 <locosage> but I'm not sure other compilers do any better
21:57:45 <Rubidium> MSVC seems to have nano second resolution
21:59:10 <locosage> peter1138[d]: can you show what the measurements look like on msvc in this branch?
22:01:12 <peter1138[d]> No, I don't use msvc.
22:02:22 <locosage> it was meant to ask Rubidium
22:02:39 <xarick> I think I reached the vehicle pool limits. How do I tell which ones are effect vehicles?
22:03:13 <Rubidium> I'm just parroting what Microsoft's documentation says
22:03:44 <xarick> high res was unreliable when I tested
22:04:45 <locosage> I checked steady_clock but it's the same
22:06:00 <truebrain> solving bugs on the bug-tracker is a very slow process ... most open bugs are so niche, or so one-off ... but okay ... fixed a few at least 😛
22:10:53 <truebrain> at least that was an easy one 🙂
22:14:58 <truebrain> 16ns resolution? Damn, that is better than I expected
22:16:44 <locosage> stabilizes around 11-12
22:17:06 <locosage> but it doesn't mean anything if it's not reliably monotonic
22:19:28 <Rubidium> but it's not like a million or so, which would definitely skew any measurements
22:20:54 <truebrain> Rubidium: now I am curious .. GCC still uses system_clock as its highres clock?
22:21:37 <truebrain> Surprised to see such a high res om a system clock, hence the question 🙂
22:23:04 <peter1138[d]> Are we talking high-resolution vs high-accuracy here? :p
22:23:23 <xarick> I got a PR merged! horray
22:23:51 <Rubidium> I have no way to test accuracy...
22:25:41 <locosage> well, pool timings are below 1ns so I guess that checks up
22:29:02 <michi_cc[d]> As far as I know `std::high_resolution_clock::period` (or `steady_clock` etc) is supposed to be the resolution of the clock. For MSVC (where high resolution is steady_clock), this is 1 ns.
22:32:28 <_jgr_> The resolution of the type is 1ns, but the OS is not guaranteed to return values which are that precise
22:32:37 <_jgr_> It's not really an issue of which compiler you use
22:32:47 <truebrain> So in Rbs case the resolution is 1ns, and the accuracy 16ns 😛
22:33:32 <truebrain> Either way, more than sufficient to measure microsecond timings 🙂
22:35:47 <locosage> in other words with avg 0.0 total means nothing
22:37:13 <peter1138[d]> It's about trends.
22:39:20 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:46:38 <peter1138[d]> Poor Drenninghead
22:48:21 <xarick> for testing, im now setting smoke_amount to 0
22:48:46 <peter1138[d]> Icons missing eh?
23:03:41 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:10:35 <peter1138[d]> Until recently we had a rdtsc tictoc variant but that was removed.
23:11:05 <peter1138[d]> Your getticks() uses rdtsc.
23:20:41 <locosage> though tbh it's all snake oil at this scale
23:21:14 <locosage> nothing is gonna measure single instructions reliably
23:35:45 <locosage> ugh just `{TicToc tt(tts);}` in those two functions measures 4x difference even with getticks()
23:35:59 <locosage> is compiler doing weird stuff with destructors or smth?
23:41:05 <xarick> dP do you want an amazing savegame?
23:44:19 *** ChanServ sets mode: +v tokai
23:44:40 <talltyler> Nice! I wonder if you could lose the extra indent and allow the cargo label to essentially function as the bullet point
23:45:24 <peter1138[d]> 2 lines to change.
23:46:55 <locosage> xarick: well, I can add it to my collection if you manage to send it somehow
23:47:16 <locosage> but I'm kinda done with these measurements
23:47:30 <locosage> may be useful next time though who knows
23:47:31 <peter1138[d]> We've proved it's faster than master :p
23:47:48 <locosage> yeah, that's like the only thing that can definitely be said xD
23:47:57 <xarick> gonna try sending to OneDrive
23:49:30 <locosage> how much faster I've no idea but faster it is xD
23:51:06 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
