Newest at the top
| 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 |
| 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) |