Logs: liberachat/#haskell
| 2025-11-13 08:10:59 | → | fp joins (~Thunderbi@2001:708:150:10::7e06) |
| 2025-11-13 08:11:19 | → | peterbecich joins (~Thunderbi@172.222.148.214) |
| 2025-11-13 08:13:36 | → | craunts795335385 joins (~craunts@175.176.16.173) |
| 2025-11-13 08:18:15 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-11-13 08:20:14 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:7b9b:6b63:6d71:c983) (Remote host closed the connection) |
| 2025-11-13 08:20:26 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:d054:8eb4:9a04:efa0) |
| 2025-11-13 08:20:40 | → | Googulator52 joins (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) |
| 2025-11-13 08:20:47 | × | Googulator60 quits (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-13 08:22:55 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-11-13 08:27:32 | → | kuribas joins (~user@2a02:1808:67:a09:b55b:215:13f6:6a3b) |
| 2025-11-13 08:27:55 | × | peterbecich quits (~Thunderbi@172.222.148.214) (Ping timeout: 240 seconds) |
| 2025-11-13 08:29:57 | × | Sgeo_ quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-11-13 08:40:16 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:d054:8eb4:9a04:efa0) (Remote host closed the connection) |
| 2025-11-13 08:40:28 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:663:9f3a:e61:332b) |
| 2025-11-13 08:40:54 | → | mreh joins (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2025-11-13 08:42:44 | × | emmanuelux_ quits (~emmanuelu@user/emmanuelux) (Remote host closed the connection) |
| 2025-11-13 08:43:25 | → | annamalai joins (~annamalai@157.33.249.99) |
| 2025-11-13 08:45:39 | → | Googulator66 joins (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) |
| 2025-11-13 08:45:45 | × | Googulator52 quits (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-13 08:53:07 | × | craunts795335385 quits (~craunts@175.176.16.173) (Quit: The Lounge - https://thelounge.chat) |
| 2025-11-13 09:07:48 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:663:9f3a:e61:332b) (Remote host closed the connection) |
| 2025-11-13 09:08:04 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:d096:39d7:b795:72d6) |
| 2025-11-13 09:08:47 | × | fp quits (~Thunderbi@2001:708:150:10::7e06) (Read error: Connection reset by peer) |
| 2025-11-13 09:08:57 | → | fp1 joins (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) |
| 2025-11-13 09:11:15 | fp1 | is now known as fp |
| 2025-11-13 09:11:48 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-13 09:14:45 | × | itaipu quits (~itaipu@168.121.97.28) (Ping timeout: 244 seconds) |
| 2025-11-13 09:20:26 | × | fp quits (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Quit: fp) |
| 2025-11-13 09:20:37 | → | fp joins (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) |
| 2025-11-13 09:25:43 | → | Googulator89 joins (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) |
| 2025-11-13 09:25:43 | × | Googulator66 quits (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-13 09:27:05 | × | tromp quits (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-13 09:27:20 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:d096:39d7:b795:72d6) (Remote host closed the connection) |
| 2025-11-13 09:27:34 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:bbc0:29cc:d3e9:c519) |
| 2025-11-13 09:27:57 | <[exa]> | is there any easy way to calculate integral `log2` with only bit operations and with just `base` (no integer-logarithms dependency or so) |
| 2025-11-13 09:29:54 | <[exa]> | also wth is 0x7c4add? https://hackage.haskell.org/package/bits-0.6/docs/src/Data.Bits.Extras.html#word32Log2 :D |
| 2025-11-13 09:33:35 | × | fp quits (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Ping timeout: 256 seconds) |
| 2025-11-13 09:34:42 | → | fp joins (~Thunderbi@130.233.70.206) |
| 2025-11-13 09:35:00 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 09:45:21 | <kuribas> | [exa]: count leading zeros? |
| 2025-11-13 09:46:05 | <kuribas> | https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-Bits.html#v:countLeadingZeros |
| 2025-11-13 09:46:51 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-13 09:46:53 | <kuribas> | [exa]: should reduce to a single cpu instruction (if you have a bounded integer). |
| 2025-11-13 09:47:26 | <kuribas> | Mutable hashtables seem quite a bit faster than immutable hashmaps: https://github.com/haskell-perf/dictionaries |
| 2025-11-13 09:47:52 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:bbc0:29cc:d3e9:c519) (Remote host closed the connection) |
| 2025-11-13 09:48:05 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:752d:1b8c:f480:a279) |
| 2025-11-13 09:48:32 | → | tromp joins (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) |
| 2025-11-13 09:49:44 | <kuribas> | Shame I cannot "freeze" a mutable hashmap, to use it from pure code. |
| 2025-11-13 09:50:14 | <kuribas> | Well, probably easy to implement using copying and unsafe code. |
| 2025-11-13 09:50:16 | × | fp quits (~Thunderbi@130.233.70.206) (Quit: fp) |
| 2025-11-13 09:50:37 | → | fp joins (~Thunderbi@2001:708:20:1406::10c5) |
| 2025-11-13 09:51:05 | <[exa]> | kuribas: that looks mildly suspicious tbh |
| 2025-11-13 09:51:15 | <kuribas> | why? |
| 2025-11-13 09:51:45 | <kuribas> | [exa]: the benchmark, or the zerocount? |
| 2025-11-13 09:52:44 | <[exa]> | the benchmark -- the int lookup for Data.HashMap.Strict should be essentially const-time like for the basic & linear hash tables, but it grows linearly |
| 2025-11-13 09:52:54 | <[exa]> | I'd suspect they're measuring some laziness artifact |
| 2025-11-13 09:53:13 | <[exa]> | either that or the Data.HashMap implementation is borked |
| 2025-11-13 09:53:56 | → | weary-traveler joins (~user@user/user363627) |
| 2025-11-13 09:54:00 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 09:54:27 | <kuribas> | maybe it measures n lookups? |
| 2025-11-13 09:57:33 | <kuribas> | it does seem like that from the code https://github.com/haskell-perf/dictionaries/blob/master/Time.hs#L338 |
| 2025-11-13 09:58:11 | <Leary> | [exa]: `GHC.Num.integerLog2`? |
| 2025-11-13 09:59:30 | <[exa]> | Leary: oh I missed that one again. Thanks! |
| 2025-11-13 09:59:32 | <kuribas> | Leary: that's probably slower on bounded integers. |
| 2025-11-13 09:59:58 | <[exa]> | kuribas: yeah there's something weird there for sure |
| 2025-11-13 10:01:45 | → | Taneb joins (~username@host-95-251-57-201.retail.telecomitalia.it) |
| 2025-11-13 10:02:35 | <kuribas> | [exa]: devide by n gives: 13.29, 17.28, 22.42, 41.10, 85.40, 460 ns |
| 2025-11-13 10:02:57 | <kuribas> | that looks logarithm-isch... |
| 2025-11-13 10:05:40 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-13 10:05:48 | → | trickard__ joins (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-13 10:06:01 | × | trickard quits (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-11-13 10:06:06 | <kuribas> | [exa]: it doubles, until 1000000, when it is suddenly X5. |
| 2025-11-13 10:07:54 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:752d:1b8c:f480:a279) (Remote host closed the connection) |
| 2025-11-13 10:08:07 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:796f:1d1b:ab7f:a73f) |
| 2025-11-13 10:08:40 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2025-11-13 10:10:14 | <kuribas> | maybe more log^2(n)? |
| 2025-11-13 10:12:41 | → | gmg joins (~user@user/gehmehgeh) |
| 2025-11-13 10:13:15 | <[exa]> | kuribas: that's kinda expected because of cache effects |
| 2025-11-13 10:14:02 | <kuribas> | maybe GC? |
| 2025-11-13 10:14:51 | <kuribas> | I suppose no because lookup doesn't need GC... |
| 2025-11-13 10:15:03 | <[exa]> | what's concerning is that the IO variants really seem to be measured differently (there's difference 500ms vs 14 ns, that's big right |
| 2025-11-13 10:15:25 | × | xff0x_ quits (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 240 seconds) |
| 2025-11-13 10:15:42 | <[exa]> | no htat's a normal thing, if you have too much of an array and access it randomly, you'll eventually hit the cache size (8MB sounds expectable here) and it's going to get a few times slower |
| 2025-11-13 10:16:06 | <[exa]> | notice the same happens for the LinearHashTable below, suddenly 3x slower (per query I assume) |
| 2025-11-13 10:16:12 | × | j1n37 quits (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
| 2025-11-13 10:17:17 | → | j1n37 joins (~j1n37@user/j1n37) |
| 2025-11-13 10:17:57 | <kuribas> | right |
| 2025-11-13 10:20:01 | × | trickard__ quits (~trickard@cpe-62-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-13 10:20:14 | → | trickard_ joins (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-13 10:20:25 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 240 seconds) |
| 2025-11-13 10:22:16 | → | kuribas` joins (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2025-11-13 10:22:40 | <[exa]> | anyway I assume the table building has leaked into the benchmark for the non-IO variant, half a second for selection in whimsy 1M table is....tooo much. |
| 2025-11-13 10:24:04 | × | kuribas quits (~user@2a02:1808:67:a09:b55b:215:13f6:6a3b) (Ping timeout: 255 seconds) |
| 2025-11-13 10:27:56 | × | deptype_ quits (~deptype@2406:b400:3a:73c2:796f:1d1b:ab7f:a73f) (Remote host closed the connection) |
| 2025-11-13 10:28:14 | → | deptype_ joins (~deptype@2406:b400:3a:73c2:ebd8:a6e4:ac56:ebb9) |
| 2025-11-13 10:31:33 | → | merijn joins (~merijn@77.242.116.146) |
| 2025-11-13 10:31:36 | <merijn> | kuribas: I mean, immutable hashmaps seems like a worst of all worlds |
| 2025-11-13 10:31:58 | <merijn> | In generaly I'm a well-known hash map hater, though. Waaaay overrated data structure |
| 2025-11-13 10:33:37 | <kuribas`> | merijn: good for strings? |
| 2025-11-13 10:38:18 | <[exa]> | people who index stuff with unstructured strings truly deserve hashmaps |
All times are in UTC.