00:00 < bridge> i was already convinced when you started typing 00:00 < bridge> `./sysdeps/x86_64/multiarch/strcpy-sse2.S` I looked at the sse2 one 00:01 < bridge> Finally someone that takes me for my word 00:01 < bridge> all plagiarized from the dictionary 00:02 < bridge> fwiw I only looked to spot the presence of 2 loops and I couldn't spot 2 loops 00:03 < bridge> I think in practice the compilers do have an object size limitation of PTRDIFF_MAX 00:03 < bridge> and I guess if you used a 64 bit unsigned for the length the max length would be your whole address space anyway (not that it would work) 00:04 < bridge> though probably a joke 00:04 < bridge> ackshully, since zero terminated strings are just a single pointer, their object size is just the size of a pointer 00:04 < bridge> the memory backing the string is an object, I wasn't talking about the pointer itself 00:05 < bridge> <-StormAx> does ddnet have a function to rotate text? 00:06 < bridge> For a C string literal under clang and gcc it maybe matters, but any portion of memory that ends in a `\0` is technically free game. e.g. strlens implementation knows nothing about the object size limits 00:08 < bridge> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397 00:08 < bridge> I've had gcc give me a related bogus warning with wording: 00:08 < bridge> `exceeds maximum object size 9223372036854775807 ` 00:08 < bridge> (which is PTRDIFF_MAX) 00:10 < bridge> but if anyone has the 9 million TB of memory please give me some 00:23 < bridge> uh, this seems to be too long for the time i have 😢 00:30 < bridge> waiting 20mins already for xorg to finish installing....... 00:31 < bridge> 15€ rpi do be slow 00:52 < bridge> hmm 00:52 < bridge> color picker is kind of jank 00:53 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1213272835846578206/image.png?ex=65f4df61&is=65e26a61&hm=6607c335c5f5eb5a80c9ec7f0b29829c3ee89956d88a2837eb944c439d56f5e7& 01:01 < bridge> neither does size prefixed strings (in a real physical world) 01:02 < bridge> because you only need the inner core of the strlen function in the inner loop of strcpy 01:02 < bridge> you mean in a real theoretical world, unless you want to introduce a branch, length is limited 01:02 < bridge> to detect the null character in the input string 01:03 < bridge> how is it practically limited when no machine has enough memory to fill 2^64 bytes ? 01:04 < bridge> anyway, on SIMD, in x86, the glibc function just checks for page boundary on 4kB page 01:04 < bridge> then it fetches as much as it wants and detects if there's a null character in the data 01:04 < bridge> yes, after looking at it this was obvious 01:04 < bridge> it's not, I'm just being pedantic since they are being pedantic 01:05 < bridge> my null delimited strings will work for my universe computer with 10 exobyte strings 01:05 < bridge> the first load is a special unaligned ones that performs less good than another instruction which requires an cache aligned (or 32B aligned) address, otherwise it generates a segfault (really not the best exception to generate though) 01:11 < bridge> note that some ISA allows vector loads to safe in an elegant manner with not touching elements outside the allowed region 01:11 < bridge> note that some ISA allows vector loads to fail in an elegant manner with not touching elements outside the allowed region 08:48 < bridge> @robyt3 i tested on windows 08:48 < bridge> 08:48 < bridge> ram changes, but it doesnt permanentaly increase 08:49 < bridge> @furo321: when fix \#8038 08:49 < bridge> @furo321: when fix \#8039 08:52 < bridge> @robyt3 i did however indeed have a massive lag closing the console after a while 😄 08:55 < bridge> Dude @remakepower when improve English axaxaxa. Just run your sentences through chatgpt before you post on GitHub and then read the text so everytime you learn it a bit :p 08:55 < bridge> 08:55 < bridge> It’s much harder to take you serious when your messages barley make sense 08:55 < bridge> @robyt3 m_Elements defs increases the whole time 😄 08:56 < bridge> maybe gcc has a different allocation strategy 08:56 < bridge> so it takes much longer to notice with it 08:57 < bridge> chillerdragon: check dms aka offtopic 08:57 < bridge> chillerdragon: don't make fun of others 08:58 < bridge> :justatest: 08:58 < bridge> Who did I make fun of? 08:58 < bridge> On da phone later 09:00 < bridge> Oh you deleted my message to bamcane. That’s weird ngl. I was being nice giving him advice on how to be respected more on GitHub. I didn’t make fun of anyone. 09:01 < bridge> @heinrich5991: don’t you agree his comments would be treated more seriously if they were corrected by chatgpt? Or that he could learn by doing so? You also correct my English all the time and I learn through that. It’s nice. 09:02 < bridge> ChillerDragon: feel free to DM me about rules, if you want anything clarified 09:11 < ws-client> ye sure im actually curious @heinrich5991 where dm 09:12 < bridge> at your service, I'm currently monitoring irc, matrix and discord 09:12 < ws-client> do you mind doing it in a public irc channel thats not bridged to ddnet? 09:13 < ws-client> #ddnet-off-topic on quakenet 09:18 < bridge> prefer not to 09:18 < bridge> interesting: https://sourcehut.org/blog/2021-11-29-announcing-the-chat.sr.ht-public-beta/ 09:24 < bridge> @robyt3 i think i understand the problem now... it's indeed not a leak, it's just a suboptimal way of doing small allocation 09:24 < bridge> 09:24 < bridge> if you'd wait long enough it would probably decrease memory again. 09:24 < bridge> 09:24 < bridge> I'll think about a solution 09:32 < bridge> who is cpp pro? 09:32 < bridge> 09:32 < bridge> i need this: 09:32 < bridge> https://en.cppreference.com/w/cpp/container/multimap/lower_bound 09:32 < bridge> 09:32 < bridge> however in my case the multimap is sorted in a reversed order 09:32 < bridge> 09:32 < bridge> so i'd also need the reverse of lower_bound basically 09:32 < bridge> 09:32 < bridge> in other words: 09:32 < bridge> "the last element that is still greater (or equal) than key" 09:32 < bridge> iterators in cpp are so hard 09:32 < bridge> xd 09:33 < bridge> have you overloaded the `operator<` to sort in reverse order? 09:34 < bridge> std::multiset> 09:34 < bridge> this basically 09:34 < bridge> then `lower_bound` should do what you want, no? 09:34 < bridge> that's not clear for me from the specs 09:34 < bridge> xd 09:34 < bridge> "This overload participates in overload resolution only if the qualified-id Compare::is_transparent is valid and denotes a type. It allows calling this function without constructing an instance of Key." 09:35 < bridge> this is the hardest sentence i over read 09:35 < bridge> but that would be the intuitive solution i guess 09:35 < bridge> I'm not sure what else it would return 09:36 < bridge> it can't suddenly start using something other than your comparator, that would violate its internal guarantees, I guess 09:36 < bridge> i'll simply test it out i guess 😄 09:45 < bridge> seems not to work 09:46 < bridge> do i need to use upper_bound then? 09:46 < bridge> 09:46 < bridge> but would it also allow equal compare? 09:47 < bridge> ok upper also doesnt work 09:47 < bridge> i don't want to manually quick sort xd 09:49 < bridge> https://en.cppreference.com/w/cpp/algorithm/lower_bound takes a comparitor 09:49 < bridge> maybe i can use that 10:10 < bridge> you can't change the operators to sort with rbegin and rend? 10:21 < ws-client> did my bugtrix msgs reach u @heinrich5991 ? 10:24 < bridge> added casts to edlang 10:33 < bridge> Odd, it used to work correctly with Vulkan and OpenGL when I tested it, but in 18.0.3 it doesn't work consistently with Vulkan anymore 10:51 < bridge> well i simply need a reversed lower bound, but the class function doesnt offer it 😄 10:51 < bridge> but yeah with the std thing it's ez 11:17 < bridge> I'm not entirely sure what you need. can you give an example with a couple of sample values? 11:17 < bridge> ```c++ 11:17 < bridge> #include 11:17 < bridge> #include 11:17 < bridge> 11:17 < bridge> int main() { 11:17 < bridge> std::multimap> map; 11:17 < bridge> map.insert({1, 2}); 11:17 < bridge> map.insert({4, 3}); 11:17 < bridge> map.insert({9, 5}); 11:18 < bridge> printf("%d\n", map.lower_bound(8)->first); 11:18 < bridge> return 0; 11:18 < bridge> } 11:18 < bridge> ``` 11:18 < bridge> this prints `4` for me, which is the first element after `8`, given that I have the `std::greater` ordering 11:25 < bridge> "the last element that is still greater (or equal) than key" 11:25 < bridge> 11:25 < bridge> so the last element >= 8 11:25 < bridge> 11:25 < bridge> in your case it's 9 11:25 < bridge> i basically need a reverse iterator 11:29 < bridge> i already solved it btw 11:29 < bridge> nice 11:29 < bridge> with std::lower_bound tho 11:30 < bridge> i don't think the class is built for my needs xd 11:30 < bridge> to me, it's not clear from your description, whether "greater" refers to the container ordering that is reversed or to the ordering outside the container 11:30 < bridge> the container is reverse bcs of the std::greater too, like in your example 11:33 < bridge> i could probably also rewrite it to not use greater in the container already.. but honestly i'm too lazy xdd 11:33 < bridge> 11:33 < bridge> with rust iterators it would have been easier 11:33 < bridge> just saiyan 11:33 < bridge> ```rs 11:33 < bridge> #include 11:33 < bridge> #include 11:33 < bridge> 11:33 < bridge> int main() { 11:33 < bridge> std::multimap> map; 11:33 < bridge> map.insert({1, 2}); 11:33 < bridge> map.insert({4, 3}); 11:33 < bridge> map.insert({9, 5}); 11:33 < bridge> auto it = map.lower_bound(8); 11:33 < bridge> it--; 11:33 < bridge> printf("%d\n", it->first); 11:33 < bridge> return 0; 11:33 < bridge> } 11:33 < bridge> ``` 11:33 < bridge> I think decrementing the iterator would work then 11:33 < bridge> yep, probably 11:33 < bridge> but what if there is no fitting entry 11:33 < bridge> then u decrement end 11:33 < bridge> eh 😦 11:33 < bridge> what even happens then xd 11:33 < bridge> yea 11:33 < bridge> UB, probablu 11:34 < bridge> UB, probably 11:34 < bridge> my cpp brain really got removed 11:34 < bridge> i forgot everything 11:34 < bridge> in my case this would actually even work 11:34 < bridge> bcs i first check if there could be a fitting allocation anyway 11:35 < bridge> to prevent the worst case of iterating through all entries 11:35 < bridge> which is likely 11:39 < bridge> i think i'll need quick_search anyway :lol: 11:39 < bridge> i need to calculate the alignment too, which changes the size requirements 11:39 < bridge> all discussion for nothing 11:40 < bridge> but it's also not really correct 11:40 < bridge> this is harder than expected 11:40 < bridge> a lower_bound with a condition 11:47 < bridge> clangd code insight also seems compltely broken 11:47 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1213437409518424084/image.png?ex=65f578a7&is=65e303a7&hm=6f1d090e0814452ac5c1ba272e8daf715047fd9bcfd7cfe678e949802ae95cfc& 11:48 < bridge> i think it's broken since our refactor for include what u need 11:48 < bridge> why didnt the tool for example say: 11:48 < bridge> include 11:48 < bridge> 11:48 < bridge> here? 11:48 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1213437867221713018/image.png?ex=65f57914&is=65e30414&hm=40b61afee3742e6609b2508ae85e08e20ca23d30507c68e5a6d15bd482acf02c& 11:49 < bridge> does it find some earlier include and then just stops? 11:49 < bridge> 11:49 < bridge> isn't that the opposite of include what you need :lol: 11:49 < bridge> include what others need 11:49 < bridge> xd 11:49 < bridge> don't include what others already needed* 12:02 < bridge> ``` 12:02 < bridge> 12:02 < bridge> log 12:02 < bridge> 2(last - first) + O(1) comparisons). However, for non-LegacyRandomAccessIterators, the number of iterator increments is linear. Notably, std::map, std::multimap, std::set, and std::multiset iterators are not random access, and so their member lower_bound functions should be preferred. 12:02 < bridge> ``` 12:02 < bridge> 12:02 < bridge> MHHH 12:02 < bridge> well that sucks :lol: 12:03 < bridge> man when gpt 5 ngl 12:03 < bridge> 12:03 < bridge> i waste 1h for a problem where i know the solution, but struggle to apply it 12:23 < bridge> i have a curse or something that breaks every feature when i try to use it 12:25 < bridge> Most likely explanation is that we updated our drivers, which causes the buggy code path in the Vulkan backend to be used instead 12:51 < bridge> i think this generally does not work without reversing the iterator 12:51 < bridge> 12:51 < bridge> "Returns an iterator pointing to the first element that is not less than (i.e. greater or equal to) key" 12:51 < bridge> 12:51 < bridge> for greater it would mean smaller or equal 12:51 < bridge> 12:51 < bridge> but i need smaller (without equal) 12:51 < bridge> 12:51 < bridge> this really sucks xd 12:51 < bridge> i dunno how i can make it work without O(1) lookup 12:53 < bridge> i guess i'll simply rewrite the container to use std::less 12:54 < bridge> well i could use greater_eq 12:54 < bridge> i guess 12:54 < bridge> what was the name of repo which could count loc in project 12:55 < bridge> tokei 12:55 < bridge> or snth 12:55 < bridge> oh ye, thx 12:56 < bridge> @milkeeycat Are you working on #8020? 12:56 < bridge> https://github.com/ddnet/ddnet/issues/8020 12:56 < bridge> ah. and you potentially have a lot of elements with the same key? 12:56 < bridge> that's probably forbidden 12:57 < bridge> no, there's no way my little noodle can fix it, i just wanted to help as much as I could =] 12:57 < bridge> well a multimap can store multiple equals, so i guess it's no problem here? 12:57 < bridge> ok, thanks 🙂 12:57 < bridge> i do indeed 12:58 < bridge> ah, so this relates to the main thread index or whatever is used for the one-time-use buffer objects? 12:58 < bridge> yes, but equal is defined as `!(a < b) && !(b < a)` 12:58 < bridge> that fails if you replace `<` with `<=` 12:59 < bridge> but why should it need eq 12:59 < bridge> well maybe it matters, but it seems like in worst case it appends it to a later element? 12:59 < bridge> when inserting 12:59 < bridge> for lookup, e.g. 13:00 < bridge> probably UB, but you might get away with it for non-production code 13:00 < bridge> the problem is the allocations in that thread yeah 😄 13:00 < bridge> but the real problem is a little bit harder to explain 13:00 < bridge> if it always uses the biggest allocation => it grows the allocation heap 13:01 < bridge> it cant merge it bcs of delayed cleanups 13:01 < bridge> yea, the comparator must suffice `Compare` 13:01 < bridge> and `Compare` states that equality must be `!(a < b) && !(b < a)` 13:01 < bridge> so AFAICT, passing `<=` is UB 13:03 < bridge> Hm, why not upper_bound - 1? 13:03 < bridge> even tho that makes sense, doesn't it depend on the lookup done? 13:03 < bridge> 13:03 < bridge> e.g. if i never use a "normal" find 13:03 < bridge> i mean it's UB by spec 13:03 < bridge> but logically 13:03 < bridge> logically, it might work 13:03 < bridge> but then, you'd think the same applies to `sort` 13:04 < bridge> and that causes actual segfaults for stuff that doesn't adhere to `Compare` 13:04 < bridge> yeah i tried that in the pr.. dunno where my thought mistake is 13:05 < bridge> Not for lower and upper bound btw 13:05 < bridge> but for `lower_bound`/`upper_bound` on `multimap` 13:05 < bridge> because `multimap` requires it 13:05 < bridge> (the member functions) 13:05 < bridge> esp upper_bound requires it 13:05 < bridge> "Returns an iterator pointing to the first element that is greater than key." 13:05 < bridge> 13:05 < bridge> it could tell if it's greater 13:05 < bridge> without knowing it's not equal 13:05 < bridge> 😄 13:05 < bridge> couldn't * 13:06 < bridge> Me and a friend got timed out at the same time, can't connect to any server because "UDP seems to be filtered" what causes this 13:06 < bridge> that sounds like UDP isn't working for you, currently 13:07 < bridge> teeworlds/ddnet run over UDP 13:08 < bridge> Hm, I'm unsure whether the compare fn you use with the multimap itself has to be the same as the one you use in upper and lower bound as long as the data satisfies is_partitioned for both 13:08 < bridge> so linear search works 13:08 < bridge> 13:08 < bridge> to remove the linear search partially i tried to first find the upper bound for size (minus one) 13:08 < bridge> => then i reversed the returned iterator and did the linear search on the remaining values 13:08 < bridge> what is wrong about this xd 13:09 < bridge> `upper_bound`/`lower_bound` member functions don't take another comparison function 13:09 < bridge> i guess make_reverse_iterator automatically does minus one? 13:09 < bridge> Bamboozled once again, why does multimap have member upper and lower bound? 😄 13:09 < bridge> " std::copy(std::make_reverse_iterator(v.end()), 13:09 < bridge> std::make_reverse_iterator(v.begin()), 13:10 < bridge> std::ostream_iterator(std::cout, ", "));" 13:10 < bridge> that's how i understand their example 13:10 < bridge> https://upload.cppreference.com/mwiki/images/3/39/range-rbegin-rend.svg 13:10 < bridge> xd 13:10 < bridge> to do the logarithmic complexity `lower_bound`/`upper_bound` 13:11 < bridge> so that was my mistake 13:11 < bridge> the function doesnt reverse the order of the iteration, but literally changes the iterator 13:11 < bridge> i swear i find cpp's iterator stuff way too complicated 13:12 < bridge> Why not a template specialization for the non-member ones though? I guess there is no way to express the operations in terms of iterators? 13:12 < bridge> interesting. I don't know. I guess it should be possible in terms of iteratorss 13:13 < bridge> I'm sure I'm missing something here. Why did you think it would reverse the order? 13:15 < bridge> i am not used to not lazy evaluated iterators anymore 13:16 < bridge> i simply didnt think about it dunno 13:16 < bridge> there is no .next() call 13:16 < bridge> it does that automatically xd 13:19 < bridge> So is your problem fixed btw? 13:19 < bridge> i guess so 13:19 < bridge> upper bound was never the problem 13:19 < bridge> but if u have a clever way to remove the O(1) search 13:19 < bridge> u could help me with that 13:20 < bridge> O(n)? 13:20 < bridge> but i think it's not really possible 13:20 < bridge> What is the actual problem? 13:20 < bridge> Like what are we solving? 13:20 < bridge> i need to calc alignment on fly 13:20 < bridge> and add that to the required size 13:20 < bridge> so the key i am searching for is literally changing xd 13:20 < bridge> only thing guaranteed is that at least one exists 13:22 < bridge> only real solution i see is overallocating the whole alignment 13:22 < bridge> but you as vulkan expert know why i shouldnt 13:22 < bridge> I don't quite get it, why does alignment requirement of an object depend on other objects? 13:22 < bridge> Why are your things in a multimap? 13:23 < bridge> the allocation itself has alignment requirements 13:23 < bridge> but how the allocations (the list of possible allocations) are aligned is not saved in some key value 13:23 < bridge> spotted on my save before map change pr afair 13:23 < bridge> it's not possible @learath2 just ignore my monologue 13:23 < bridge> i just can't accept that it's linear 13:24 < bridge> Sorry, I guess this is far too niche for me to understand from the outside. I was hoping it was more abstract 13:24 < bridge> Well a linear search in sorted data does sound like a bummer 13:24 < bridge> i'd need a data structure that somehow is categorized in certain alignment requirements already i guess 13:25 < bridge> in 99% of all cases it also doesnt matter 13:25 < bridge> i already put similar alignments together, similar != equal in this case 13:25 < bridge> Depends on how expensive a comparison is and how big your set is 13:25 < bridge> more like upper categories xD 13:26 < bridge> What are you making btw? 13:27 < bridge> basically this 13:27 < bridge> Search __most__ fitting allocation, not _first_ fitting 13:28 < bridge> it's not very easy to explain, but since some stuff is lazy deallocated the allocation heap grows in an undesirable way 13:28 < bridge> where it sometimes does not merge back similar allocations 13:32 < bridge> now comes the rust version fix 13:32 < bridge> let's see how much i struggle there. 13:32 < bridge> 13:32 < bridge> multimaps don't exist in rust 13:33 < bridge> I bet there is a crate for it 13:33 < bridge> back then i didnt find one 13:34 < bridge> There is one called multimap and another multi_map 13:34 < bridge> Maybe one of them works for you 13:35 < bridge> Or I guess you can have a naive multimap as a hashmap of key to vec. 13:35 < bridge> apparently i used this 13:35 < bridge> ```rust 13:35 < bridge> std::collections::BTreeMap> 13:35 < bridge> ``` 13:35 < bridge> and rewrote the logic 13:35 < bridge> MemoryHeapQueueElement just says nothing to me 😄 13:36 < bridge> understandable xd 13:36 < bridge> why LinkedHashMap? 13:36 < bridge> Linked lists are hot 13:36 < bridge> and why nonzero? 13:36 < bridge> it's basically just the struct that stores the alloc size and alignment in buffer 13:36 < bridge> xd 13:36 < bridge> that's just some id 13:36 < bridge> bcs i don't work with ptrs in rust 13:36 < bridge> why not 13:36 < bridge> in cpp multimap iterators stay valid 13:37 < bridge> smth like that doesnt exist in rust 13:37 < bridge> So this keeps track of your allocations in gpu memory? 13:37 < bridge> and would be some kind of ptr magic 13:37 < bridge> well kind of i guess 13:37 < bridge> 13:37 < bridge> but not directly 13:37 < bridge> is that safe 13:37 < bridge> it keeps track of sub allocations 13:37 < bridge> Why does the alignment need to be kept track of? Do you move objects around later? 13:37 < bridge> it is safe, as long as they entry doesnt get invalid 13:38 < bridge> maybe u can achieve that with pin or smth 13:38 < bridge> but ye sounds annoying 13:38 < bridge> well for the allocator the offset in heap is interesting 13:38 < bridge> but for user the offset + align 13:38 < bridge> xd 13:38 < bridge> apparently the user for simplicity simply gets a copy 13:38 < bridge> of that element 13:39 < bridge> so ignore the alignment stuff 13:40 < bridge> ```std::multiset>;``` 13:40 < bridge> 13:40 < bridge> cpp version btw `SMemoryHeapQueueElement` is the same here 13:41 < bridge> i also use multiset not map.. but doesnt matter in this case xD 13:42 < bridge> Hm, see I may be missing something but alignment should only be important when you allocate first, unless the allocations need to be relocatable without user intervention 13:43 < bridge> it is 13:43 < bridge> ignore the alignment part 13:43 < bridge> i dont use it 13:43 < bridge> it's only for the result value 13:44 < bridge> but alignment is affected by the offset in the buffer 13:44 < bridge> Anyway, a map doesn't look like the best structure for this. I'll think about it over breakfast 13:44 < bridge> so exactly at allocation time it matters what the offset is 13:44 < bridge> note that i already group _similar_ aligned stuff together 13:44 < bridge> so it only sometimes doesn't fit 13:45 < bridge> You want to find the best fitting, so the smallest free block that's properly aligned with enough size, yes? 13:45 < bridge> yes 13:45 < bridge> Ok, brb tea and fooding. It helps me think 13:45 < bridge> xd 13:46 < bridge> lerato tea-powered 13:46 < bridge> and btw it should not only be the properly aligned one.. if the allocation is big enough, it should be allowed to align the memory inside the allocation 13:46 < bridge> it's better to waste a few bytes than use a oversized chunk i guess 13:47 < bridge> or in other words: 13:47 < bridge> if no alignment fits (without wasting bytes) 13:47 < bridge>