Newest at the top
| 2025-11-13 11:06:06 +0100 | <kuribas> | [exa]: it doubles, until 1000000, when it is suddenly X5. |
| 2025-11-13 11:06:01 +0100 | trickard | (~trickard@cpe-62-98-47-163.wireline.com.au) (Ping timeout: 264 seconds) |
| 2025-11-13 11:05:48 +0100 | trickard__ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-13 11:05:40 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-13 11:02:57 +0100 | <kuribas> | that looks logarithm-isch... |
| 2025-11-13 11:02:35 +0100 | <kuribas> | [exa]: devide by n gives: 13.29, 17.28, 22.42, 41.10, 85.40, 460 ns |
| 2025-11-13 11:01:45 +0100 | Taneb | (~username@host-95-251-57-201.retail.telecomitalia.it) Taneb |
| 2025-11-13 10:59:58 +0100 | <[exa]> | kuribas: yeah there's something weird there for sure |
| 2025-11-13 10:59:32 +0100 | <kuribas> | Leary: that's probably slower on bounded integers. |
| 2025-11-13 10:59:30 +0100 | <[exa]> | Leary: oh I missed that one again. Thanks! |
| 2025-11-13 10:58:11 +0100 | <Leary> | [exa]: `GHC.Num.integerLog2`? |
| 2025-11-13 10:57:33 +0100 | <kuribas> | it does seem like that from the code https://github.com/haskell-perf/dictionaries/blob/master/Time.hs#L338 |
| 2025-11-13 10:54:27 +0100 | <kuribas> | maybe it measures n lookups? |
| 2025-11-13 10:54:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 10:53:56 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-11-13 10:53:13 +0100 | <[exa]> | either that or the Data.HashMap implementation is borked |
| 2025-11-13 10:52:54 +0100 | <[exa]> | I'd suspect they're measuring some laziness artifact |
| 2025-11-13 10:52:44 +0100 | <[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 10:51:45 +0100 | <kuribas> | [exa]: the benchmark, or the zerocount? |
| 2025-11-13 10:51:15 +0100 | <kuribas> | why? |
| 2025-11-13 10:51:05 +0100 | <[exa]> | kuribas: that looks mildly suspicious tbh |
| 2025-11-13 10:50:37 +0100 | fp | (~Thunderbi@2001:708:20:1406::10c5) fp |
| 2025-11-13 10:50:16 +0100 | fp | (~Thunderbi@130.233.70.206) (Quit: fp) |
| 2025-11-13 10:50:14 +0100 | <kuribas> | Well, probably easy to implement using copying and unsafe code. |
| 2025-11-13 10:49:44 +0100 | <kuribas> | Shame I cannot "freeze" a mutable hashmap, to use it from pure code. |
| 2025-11-13 10:48:32 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) |
| 2025-11-13 10:48:05 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:752d:1b8c:f480:a279) |
| 2025-11-13 10:47:52 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:bbc0:29cc:d3e9:c519) (Remote host closed the connection) |
| 2025-11-13 10:47:26 +0100 | <kuribas> | Mutable hashtables seem quite a bit faster than immutable hashmaps: https://github.com/haskell-perf/dictionaries |
| 2025-11-13 10:46:53 +0100 | <kuribas> | [exa]: should reduce to a single cpu instruction (if you have a bounded integer). |
| 2025-11-13 10:46:51 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-13 10:46:05 +0100 | <kuribas> | https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-Bits.html#v:countLeadingZeros |
| 2025-11-13 10:45:21 +0100 | <kuribas> | [exa]: count leading zeros? |
| 2025-11-13 10:35:00 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 256 seconds) |
| 2025-11-13 10:34:42 +0100 | fp | (~Thunderbi@130.233.70.206) fp |
| 2025-11-13 10:33:35 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Ping timeout: 256 seconds) |
| 2025-11-13 10:29:54 +0100 | <[exa]> | also wth is 0x7c4add? https://hackage.haskell.org/package/bits-0.6/docs/src/Data.Bits.Extras.html#word32Log2 :D |
| 2025-11-13 10:27:57 +0100 | <[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 10:27:34 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:bbc0:29cc:d3e9:c519) |
| 2025-11-13 10:27:20 +0100 | deptype_ | (~deptype@2406:b400:3a:73c2:d096:39d7:b795:72d6) (Remote host closed the connection) |
| 2025-11-13 10:27:05 +0100 | tromp | (~textual@2001:1c00:3487:1b00:7d:cf52:961a:9343) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-11-13 10:25:43 +0100 | Googulator66 | (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-11-13 10:25:43 +0100 | Googulator89 | (~Googulato@2a01-036d-0106-0180-7503-5e9f-00fa-e270.pool6.digikabel.hu) |
| 2025-11-13 10:20:37 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) fp |
| 2025-11-13 10:20:26 +0100 | fp | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) (Quit: fp) |
| 2025-11-13 10:14:45 +0100 | itaipu | (~itaipu@168.121.97.28) (Ping timeout: 244 seconds) |
| 2025-11-13 10:11:48 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-11-13 10:11:15 +0100 | fp1 | fp |
| 2025-11-13 10:08:57 +0100 | fp1 | (~Thunderbi@wireless-86-50-140-45.open.aalto.fi) fp |
| 2025-11-13 10:08:47 +0100 | fp | (~Thunderbi@2001:708:150:10::7e06) (Read error: Connection reset by peer) |