Newest at the top
| 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 |
| 2024-09-23 16:29:29 +0200 | <raehik> | I want to check two Word64# s for equality, but in the event of inequality, I want to see which byte failed first (from left to right). I could do this with `and64#` and checking the output. Would this be any slower than using `eqWord64#`? |
| 2024-09-23 16:27:50 +0200 | misterfish | (~misterfis@87.215.131.102) (Ping timeout: 265 seconds) |
| 2024-09-23 16:23:23 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-09-23 16:09:54 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-23 16:07:45 +0200 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2024-09-23 16:03:24 +0200 | rosco | (~rosco@175.136.158.234) |
| 2024-09-23 15:55:21 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-23 15:51:45 +0200 | kimiamania208 | kimiamania |
| 2024-09-23 15:50:26 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-09-23 15:50:07 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-09-23 15:36:55 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) |
| 2024-09-23 15:35:32 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-09-23 15:28:15 +0200 | sdrfan123 | (~sdrfan123@2607:fb90:df8d:eacb:59e2:a84b:249b:3618) (Ping timeout: 256 seconds) |
| 2024-09-23 15:22:19 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-09-23 15:22:02 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-09-23 15:17:52 +0200 | sdrfan123 | (~sdrfan123@2607:fb90:df8d:eacb:59e2:a84b:249b:3618) |
| 2024-09-23 15:15:07 +0200 | synchromesh | (~john@2406:5a00:241a:5600:793d:2863:f8b8:724f) |
| 2024-09-23 15:13:48 +0200 | synchromesh | (~john@2406:5a00:241a:5600:793d:2863:f8b8:724f) (Read error: Connection reset by peer) |
| 2024-09-23 15:08:49 +0200 | Guest61 | (~Guest57@129.227.235.110) (Client Quit) |
| 2024-09-23 15:05:08 +0200 | Guest61 | (~Guest57@129.227.235.110) |
| 2024-09-23 14:51:26 +0200 | tt123109783243 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-09-23 14:51:01 +0200 | tt123109783243 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: Ping timeout (120 seconds)) |
| 2024-09-23 14:47:48 +0200 | srazkvt | (~sarah@user/srazkvt) |
| 2024-09-23 14:43:57 +0200 | euleritian | (~euleritia@dynamic-176-006-134-141.176.6.pool.telefonica.de) |
| 2024-09-23 14:40:39 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 260 seconds) |