Newest at the top
2024-09-23 18:28:45 +0200 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) (Quit: ZNC 1.9.1 - https://znc.in) |
2024-09-23 18:26:43 +0200 | ChanServ | +v yahb2 |
2024-09-23 18:26:43 +0200 | yahb2 | (~yahb2@user/tomsmeding/bot/yahb2) |
2024-09-23 18:25:47 +0200 | yahb2 | (~yahb2@user/tomsmeding/bot/yahb2) (Remote host closed the connection) |
2024-09-23 18:18:14 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
2024-09-23 18:17:56 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
2024-09-23 18:16:19 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Ping timeout: 264 seconds) |
2024-09-23 18:15:03 +0200 | youthlic | (~Thunderbi@user/youthlic) (Ping timeout: 246 seconds) |
2024-09-23 18:13:49 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
2024-09-23 18:13:18 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 245 seconds) |
2024-09-23 18:07:09 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 260 seconds) |
2024-09-23 18:00:38 +0200 | sdrfan123 | (~sdrfan123@2607:fb90:df8d:eacb:1ce7:a140:b870:c72c) |
2024-09-23 17:59:32 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
2024-09-23 17:57:03 +0200 | sdrfan123 | (~sdrfan123@2607:fb90:df8d:eacb:1ce7:a140:b870:c72c) (Quit: Client closed) |
2024-09-23 17:56:02 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 248 seconds) |
2024-09-23 17:54:44 +0200 | sabino | (~sabino@user/sabino) |
2024-09-23 17:53:27 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) |
2024-09-23 17:52:12 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
2024-09-23 17:49:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 248 seconds) |
2024-09-23 17:43:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2024-09-23 17:42:43 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
2024-09-23 17:34:27 +0200 | lucy | (~lucy@user/lucy) |
2024-09-23 17:32:44 +0200 | sdrfan123 | (~sdrfan123@2607:fb90:df8d:eacb:1ce7:a140:b870:c72c) |
2024-09-23 17:32:33 +0200 | lucy | (~lucy@user/lucy) (Ping timeout: 248 seconds) |
2024-09-23 17:32:09 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) |
2024-09-23 17:30:16 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.2) |
2024-09-23 17:24:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2024-09-23 17:23:46 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
2024-09-23 17:21:03 +0200 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
2024-09-23 17:17:05 +0200 | <raehik> | in any case I should still use XOR in the failure case so I will be writing both, so might do some unscientific benchmarking |
2024-09-23 17:16:07 +0200 | <raehik> | merijn: you're right it's much more complex than I thought and I can't find definite answers online for x86(-64) or ARM! I was right thinking that XOR _should_ be faster than "default" equality checks via CMP/SUB, but modern processors & ISAs are clever and weird |
2024-09-23 17:14:53 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
2024-09-23 16:54:09 +0200 | supercode | (~supercode@user/supercode) |
2024-09-23 16:48:24 +0200 | athan | (~athan@2600:382:2d0c:946e:ee6b:c0a7:dbf9:e4ec) |
2024-09-23 16:42:35 +0200 | <raehik> | thinking more about it, I'm sure the equality check should be faster by an instruction in some way |
2024-09-23 16:41:44 +0200 | <raehik> | merijn: thanks I admittedly don't know much about micro-benchmarking! |
2024-09-23 16:40:58 +0200 | <merijn> | because micro-benchmarking is HAAAAAAARD |
2024-09-23 16:40:50 +0200 | <merijn> | raehik: I mean, benchmarking that accurately in C would still take you weeks of benchmark writing :p |
2024-09-23 16:39:06 +0200 | <raehik> | I figure I could benchmark the instructions themselves with C if I wanted, but I assume there's some programmer knowledge out there like "your average ALU will do all these operations at the same speed" |
2024-09-23 16:37:39 +0200 | <raehik> | oh. I was most interested in instruction count. I figured that would tell me enough |
2024-09-23 16:36:44 +0200 | <merijn> | Like, we're talking performance differences that would probably take you weeks of micro-benchmark writing to determine |
2024-09-23 16:36:41 +0200 | <raehik> | merijn: that's true, but I figured I could google for general case comparing XOR with whatever gets used for `eqX` |
2024-09-23 16:36:01 +0200 | <merijn> | Less instructions is not the same as faster |
2024-09-23 16:35:44 +0200 | <merijn> | I mean, that doesn't tell you much either |
2024-09-23 16:35:12 +0200 | <raehik> | atrociously pointless optimization for the error case which should not happen much xd |
2024-09-23 16:33:47 +0200 | rosco | (~rosco@175.136.158.234) (Quit: Lost terminal) |
2024-09-23 16:32:51 +0200 | <raehik> | merijn: ok thx just going by feel here. think I do both and compare output assembly |
2024-09-23 16:31:36 +0200 | <raehik> | (actually probably I want xor not and but w/e) |
2024-09-23 16:31:30 +0200 | <raehik> | In my head, I can make up some assembly where both are the same number of instructions (assuming 8-byte instructions). But it would rely on doing a conditional jump on the boolean op result, which I don't know how to control |
2024-09-23 16:31:26 +0200 | <merijn> | raehik: Probably not in any sensible manner :p |