DDraceNetwork - developer

<ChillerDragon> For someone big on compatibility I sometimes have the feeling you want to break teeworlds compatibility just for the sake of it @heinrich5991

00:19

<ChillerDragon> Every time I mention doing something the same way as teeworlds you shutdown and argue against me.

00:20

<ChillerDragon> When I proposed to switch to standardized json for auto mappers like teeworlds does it you declined the proposal.

00:20

<ChillerDragon> When I proposed the colored broadcast format from 0.7 you requested to not do it like teeworlds but use something more standardized like html.

Agreed, too biased

based

whats the benefit of json for automappers btw

02:08

why was it changed

idk why it was changed but the benefit is that json is a standardized format. So you can work on it with existing tooling. Parse it with code using existing libraries. Have syntax highlight in your editor. Lint it with json checkers.

gm

https://github.com/BurntSushi/jiff

GitHub - BurntSushi/jiff: A date-time library for Rust that encoura...

A date-time library for Rust that encourages you to jump into the pit of success. - BurntSushi/jiff

heinrich5991

cool. ty ❤️

but tbh the bench look sus, last time i did them they didnt optimize the loops away, seems like rust/llvm also improved in the last 1.5 years ^^ (should try playing around with black_box) (edited)

Ryozuki

https://github.com/BurntSushi/jiff

using something else than UTC except for UI display always sucks change my mind

06:12

it's just always trouble to think about timezones and shit xD

06:12

and on UI display u can often simply do "to_system_time"

storing time in future is pain pepeW

MilkeeyCat

storing time in future is pain pepeW

when do you work on std::time module for your language

Jupstar ✪

when do you work on std::time module for your language

we don't need time

MilkeeyCat

we don't need time

tru

@Ryozuki have you ever seriously worked with the black_box function?

hi jupstar

ye

i have to say i find it bit hard to directly understand wtf it is doing: e.g. let _ = std::hint::black_box(v); vs let a = v; std::hint::black_box(a); already produces significantly different results xD (ran it a few times only tho)

#iterate
indexmap took 131ns:
vec took 120ns:
hashmap took 340ns:
linked-hashmap took 230ns:
fx hashmap took 310ns:
indexmap (values only) took 150ns:
linked-hashmap (with view) took 200ns:
linked-hashmap (values only) took 200ns:
fx hashmap (values only) took 321ns:

vs

#iterate
indexmap took 61ns:
vec took 80ns:
hashmap took 251ns:
linked-hashmap took 141ns:
fx hashmap took 240ns:
indexmap (values only) took 80ns:
linked-hashmap (with view) took 130ns:
linked-hashmap (values only) took 120ns:
fx hashmap (values only) took 190ns:

(edited)

Ewan

hi jupstar

hello pro

how are u pro

I'm fine and you pro

alright

07:27

about to set up windows manager some more

gm pros

Jupstar ✪

i have to say i find it bit hard to directly understand wtf it is doing: e.g. let _ = std::hint::black_box(v); vs let a = v; std::hint::black_box(a); already produces significantly different results xD (ran it a few times only tho)

#iterate
indexmap took 131ns:
vec took 120ns:
hashmap took 340ns:
linked-hashmap took 230ns:
fx hashmap took 310ns:
indexmap (values only) took 150ns:
linked-hashmap (with view) took 200ns:
linked-hashmap (values only) took 200ns:
fx hashmap (values only) took 321ns:

vs

#iterate
indexmap took 61ns:
vec took 80ns:
hashmap took 251ns:
linked-hashmap took 141ns:
fx hashmap took 240ns:
indexmap (values only) took 80ns:
linked-hashmap (with view) took 130ns:
linked-hashmap (values only) took 120ns:
fx hashmap (values only) took 190ns:

(edited)

Is it atleast consistent that one is significantly slower? You probably should run this in a loop and take the mean until the mean stabilizes

Learath2

Is it atleast consistent that one is significantly slower? You probably should run this in a loop and take the mean until the mean stabilizes

i ran it few times and the times are always similar, so yes one was slower

07:51

and actually i'd have thought the second should be slower if at all

07:52

that confuses me additionally... but maybe it's about that the second is not used as a result and stays unused or smth xd

https://github.com/llvm/llvm-project/pull/84453

[mlir-c] expand the mlir llvm dialect C api with more attributes/en...

This is kind of a followup to #83992

07:53

epyc

@Learath2 have u ever analyzed cache misses and got any information out of it?

i now know tablegen

Jupstar ✪

@Learath2 have u ever analyzed cache misses and got any information out of it?

like actually improved stuff with the knowledge

Ryozuki

https://github.com/llvm/llvm-project/pull/84453

epyc coder moment

Jupstar ✪

@Learath2 have u ever analyzed cache misses and got any information out of it?

Only once while messing around with trying to optimize ban lookups

07:55

I didn’t exactly get better code but it made me understand why a certain idea that seemed promising performed like shit

1

Jupstar ✪

that confuses me additionally... but maybe it's about that the second is not used as a result and stays unused or smth xd

Ah, the second one is completely wrong that’s why. You need to use a value that is blackboxed. In the second one you just black box sth then you do nothing with it

Learath2

Ah, the second one is completely wrong that’s why. You need to use a value that is blackboxed. In the second one you just black box sth then you do nothing with it

sure but shouldnt black box still return the var volatile?

Jupstar ✪

sure but shouldnt black box still return the var volatile?

You just discard what it returns

in the first i also don't do anything with the result xD

08:00

let _ = is easily a discard

The assignment has to be done for the first one because the compiler probably can’t assume anything about _ even though it’s a discard label

I don't know why they don't perform the same

08:38

the first one drops v

08:38

the second one moves v into a and then drops a

08:39

I woulld have thought that it optimizes to the same code

heinrich5991

the first one drops v

I'm guessing it simply can't drop v immediately because of some quirk of black_box that's not exactly intuitive

09:24

To test my hypothesis I would just copy paste that line over and over. It should get worse and worse

i'll leave it for now anyway. I have to focus on other things than micro benchmarks for now. But someday i want to watch a stream of @Learath2 showing all tricks to find bottlenecks on linux. Be it over sampling for a certain amount of time, or benching the whole app or finding cache misses xdd I tried so many tools but never really found something insanely useful and often they are not really intuitive or easy to use

Jupstar ✪

i'll leave it for now anyway. I have to focus on other things than micro benchmarks for now. But someday i want to watch a stream of @Learath2 showing all tricks to find bottlenecks on linux. Be it over sampling for a certain amount of time, or benching the whole app or finding cache misses xdd I tried so many tools but never really found something insanely useful and often they are not really intuitive or easy to use

Perf is my beloved

Jupstar ✪

i have to say i find it bit hard to directly understand wtf it is doing: e.g. let _ = std::hint::black_box(v); vs let a = v; std::hint::black_box(a); already produces significantly different results xD (ran it a few times only tho)

#iterate
indexmap took 131ns:
vec took 120ns:
hashmap took 340ns:
linked-hashmap took 230ns:
fx hashmap took 310ns:
indexmap (values only) took 150ns:
linked-hashmap (with view) took 200ns:
linked-hashmap (values only) took 200ns:
fx hashmap (values only) took 321ns:

vs

#iterate
indexmap took 61ns:
vec took 80ns:
hashmap took 251ns:
linked-hashmap took 141ns:
fx hashmap took 240ns:
indexmap (values only) took 80ns:
linked-hashmap (with view) took 130ns:
linked-hashmap (values only) took 120ns:
fx hashmap (values only) took 190ns:

(edited)

show code

09:42

of how u use it

09:42

more context

09:42

black box is mainly to not let compiler inline and const propagate

it just inside a iter().for_each

why dont u put it in godbolt

i am too lazy for now xd

but ultimately, as the path says, its a hint

yeah

09:43

was just surprised

09:44

maybe llvm dev ryo would be like: that is expected

09:44

pew pew

Jupstar ✪

i have to say i find it bit hard to directly understand wtf it is doing: e.g. let _ = std::hint::black_box(v); vs let a = v; std::hint::black_box(a); already produces significantly different results xD (ran it a few times only tho)

#iterate
indexmap took 131ns:
vec took 120ns:
hashmap took 340ns:
linked-hashmap took 230ns:
fx hashmap took 310ns:
indexmap (values only) took 150ns:
linked-hashmap (with view) took 200ns:
linked-hashmap (values only) took 200ns:
fx hashmap (values only) took 321ns:

vs

#iterate
indexmap took 61ns:
vec took 80ns:
hashmap took 251ns:
linked-hashmap took 141ns:
fx hashmap took 240ns:
indexmap (values only) took 80ns:
linked-hashmap (with view) took 130ns:
linked-hashmap (values only) took 120ns:
fx hashmap (values only) took 190ns:

(edited)

v is not copy right?

yeah it's a reference

@Jupstar ✪ https://godbolt.org/z/W3nrW6Khc

Compiler Explorer

Compiler Explorer is an interactive online compiler which shows the assembly output of compiled C++, Rust, Go (and many more) code.

09:49

am i doing it correct?

09:49

looks the same xd

09:49

missing context

yes

@Jupstar ✪ can you try black_box(&result) instead?

it doesnt do a copy refering the ghost code in my editor if that is your assumption

Jupstar ✪

it doesnt do a copy refering the ghost code in my editor if that is your assumption

not sure if I understand you. black_box(result) has to move result around

10:06

black_box(&result) doesn't have to do that

but what is result in your example

10:07

iter().for_each() gives a ref

let _ = hint::black_box(&v);

i never deref it

ah

but in any case, maybe i got simply unlucky and got a bad cpu core