18:05 < Edible> thank you so much heinrich5991, i changed my password and i cant log in anymore
18:06 < Edible> hurrah strong passwords
18:06 <@heinrich5991> why didn't you write it down on your local machine?
18:06 < Edible> i did, it doesnt work
18:32 <@heinrich5991> I'm sorry
18:33 <@minus> password resets bork?
18:34 < Edible> not my machine, it was a free public unix shell
21:03 < rand> hello, I isolated a small part of my mod source that may be interesting for vanilla. It's different way to compute collision. I'm using intersection of segments obtained from the tiles. It's seems a bit more efficient but I didn't fully test it. (and i did some hack so that laser works for example)
21:03 < rand> https://github.com/nheir/teeworlds/commit/685f0b05c88baaa183b58a75a6187e854b40e2ba
21:32 <@matricks> is.. is that really faster?
21:32  * minus grabs popcurn
21:33 <@minus> popcorn even
21:33  * minus watches https://www.youtube.com/watch?v=-PGq2dV0fBw while waiting for rand's argument
21:34 < rand> i said it seems faster ^^
21:37 < rand> i gain about 2~5% cpu when using it globally (the server uses on my pc up to 15% (with 16 bots))
21:38 <@minus> that's not very accurate
21:38 < rand> i know
21:38 <@minus> probably not even significant
21:38 <@minus> count the cycles the physics take
21:39 < rand> how can I do that ?
21:39 <@heinrich5991> valgrind
21:40 <@minus> valgrind can count cycles?
21:40 <@heinrich5991> yes
21:40 <@heinrich5991> incl. cache misses etc IIRC
21:40 <@minus> though it might be too slow when it's running in valgrind
21:40 <@heinrich5991> doesn't matter
21:40 <@heinrich5991> the timing is still accurate
21:40 <@minus> maybe dtrace
21:40 <@minus> i listened to a podcast about it today
21:41 <@minus> seems pretty rad
21:41 <@minus> i wonder if matricks has used dtrace before
21:44 < rand> ok, i'll man valgrind about cycles
21:45 <@heinrich5991> valgrind --tool=cachegrind or so
21:45 <@heinrich5991> or maybe callgrind
21:45 <@heinrich5991> not sure
21:53 <@matricks> valgrind sucks when it comes to performance
21:54  * koomi prefers perf
21:54 <@matricks> rand: if yours is faster, I would speed up the version that is in there :)
21:55 <@matricks> for longer searches, yours should be faster, depending on map size
21:56 < rand> for my bots, the gain is obvious but I use a lot IntersectLine
21:56 < rand> exactly, for longer searches
21:56 <@matricks> rand: depends on map size as well
21:57 <@heinrich5991> matricks: does it suck at things other than IO?
21:57 <@matricks> heinrich5991: huh?
21:58 < rand> also, improving it is also possible, it should be possible reduce the number of segment checked with a good data structure
21:59 <@matricks> a distance field should yield pretty reliable performance
21:59 <@matricks> either way, the old implementation is really stupid and could be like 32x faster
22:02 < rand> I keep working on it since I really need it anyway
22:02 <@matricks> yap
22:08 <@heinrich5991> matricks: what do you mean with "valgrind sucks when it comes to performance"?
22:08 <@heinrich5991> that valgrinded programs execute slowly or that you cannot measure performance with valgrind?
22:09 < koomi> heinrich5991: it's a stupid model, why try to simulate a CPU when you can just run your program on a real one and ask it for counters?
22:09 <@heinrich5991> koomi: because it's more accurate
22:10 < koomi> why would that be?
22:10 <@heinrich5991> because as far as I know you can't get the performance down to the instruction level "on a real CPU"
22:11 <@heinrich5991> you just sample every once in a while (?)
22:12 < koomi> then how would you create a simulated cpu that is more accurate than what you can measure on a real one?
22:14 <@minus> unless the simulated one simulates the real pipeline, cache and memory access as well it's pretty worthless
22:16 <@matricks> heinrich5991: but thats the thing, it's not accurate
22:16 <@heinrich5991> minus: I thought that's exactly what it did
22:16 <@matricks> heinrich5991: last time I tried it got cache misses completly wrong
22:17 <@matricks> it didn't take into account precache instructions etc
22:17 <@matricks> benching in PC however is.. well.. really really hard
22:17 <@heinrich5991> koomi: if you simulate something, you can do more stuff than on the real thing
22:18 <@matricks> problem is if your simulation is off :)
22:18 <@heinrich5991> yes
22:19 < koomi> heinrich5991: sure, but how do you know how the real thing preforms better than what you can measure on it?
22:21 <@heinrich5991> koomi: I'm not sure I get what you want to say. if you can simulate a piece of hardware, then you can measure anything on it in much greater detail. if our simulation is accurate, we're guaranteed to get the same performance "on the real thing"
22:23 < koomi> the problem is how do you create an accurate simulation? unlike memory access etc. performance characteristics of a x86 aren't specified at all
22:23 < koomi> the only way to know anything about it is to measure it
22:24 < koomi> unless intel is nice to you and gives you their source
22:25 <@heinrich5991> yes
22:25 <@heinrich5991> pretty much
22:25 <@matricks> you can't, you can create a typical simulation
22:25 <@minus> Also Performance is different from model to model
22:26 <@heinrich5991> yes :)
22:27 <@minus> Just add performance metrics and deploy to your customers
22:39 <@matricks> optimiziieried it for 10458% extra pörformänce
22:41 <@matricks> minus: do it like this: https://www.youtube.com/watch?v=4QZjnGIxvmc
22:43 < rand> is Ir (for instruction read) relevant ?
22:43 <@matricks> rand: huh?
22:43 <@matricks> oh, yeah
22:43 <@matricks> or what, context?
22:44 < rand> for the computation of collision (on dm1)
22:45 <@matricks> have to see it in a bigger context
22:45 < rand> from 10k to 1k Ir with Porjectile collision and 19k to 2.6k Ir for character collision
22:46 <@matricks> lower should be better :)
22:47 <@matricks> best trailer ever btw