Newest at the top
| 2026-02-24 22:31:20 +0100 | <EvanR> | @botsnack |
| 2026-02-24 22:31:02 +0100 | <EvanR> | :t nubOn |
| 2026-02-24 22:30:24 +0100 | <haskellbridge> | <ijouw> Is there a good way to define a more general Ord class that avoids troubles with functions using Ordered argumens like nubOn? |
| 2026-02-24 22:30:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-24 22:29:33 +0100 | <EvanR> | ok it doesn't seem to be trying to print out literally 10^6 ints but the program is more complex than that |
| 2026-02-24 22:28:09 +0100 | <lantti> | in each run |
| 2026-02-24 22:27:55 +0100 | <lantti> | so basically two runs of consecutive ints with one exception |
| 2026-02-24 22:27:17 +0100 | <lantti> | the whole task is that one: https://cses.fi/alon/task/1092/ |
| 2026-02-24 22:26:32 +0100 | <EvanR> | are they particularly uniform ints or like up to 3 digits or |
| 2026-02-24 22:26:07 +0100 | <lantti> | oops, 1000000 |
| 2026-02-24 22:25:54 +0100 | <EvanR> | 10^7 ints |
| 2026-02-24 22:25:51 +0100 | cbarrett | (sid192934@id-192934.helmsley.irccloud.com) cbarrett |
| 2026-02-24 22:25:39 +0100 | cbarrett | (sid192934@id-192934.helmsley.irccloud.com) (Server closed connection) |
| 2026-02-24 22:25:35 +0100 | <lantti> | I can't figure out the profiling under stack right now, but unix time command for the 10000000 Ints case gives 0.8s |
| 2026-02-24 22:25:04 +0100 | <EvanR> | requiring us to do artifically additional buffering wtf |
| 2026-02-24 22:24:47 +0100 | <EvanR> | hopefully evaluate doesn't first take an MVar before evaluating xD |
| 2026-02-24 22:23:24 +0100 | <lambdabot> | Foldable t => t b -> IO () |
| 2026-02-24 22:23:22 +0100 | <mauke> | :t mapM_ evaluate |
| 2026-02-24 22:20:42 +0100 | <tomsmeding> | that's the dual version :p |
| 2026-02-24 22:20:32 +0100 | <EvanR> | .oO( replace the printing with just evaluating the ints in sequence ) |
| 2026-02-24 22:20:01 +0100 | <newmind> | that was my second suggestion, replacing ints with [1..100000] or something |
| 2026-02-24 22:19:21 +0100 | <tomsmeding> | further tip: benchmark your code but setting `ints = replicate 100000 123456789` or something, just to double-check it's actually the printing that's slow, not the computation preceding it |
| 2026-02-24 22:19:01 +0100 | aka_dude | (~aka_dude@2a03:f80:30:f490::1) (Remote host closed the connection) |
| 2026-02-24 22:18:19 +0100 | morj_away | (~morj@user/morj) (Quit: Konversation terminated!) |
| 2026-02-24 22:18:02 +0100 | aka_dude | (~aka_dude@2a03:f80:30:f490::1) |
| 2026-02-24 22:17:41 +0100 | <newmind> | lantti: what's the actual time you're getting? just to see how reasonable it is |
| 2026-02-24 22:17:20 +0100 | <tomsmeding> | but that doesn't have the nice Int serialiser |
| 2026-02-24 22:17:10 +0100 | <tomsmeding> | EvanR: which i why I recommended `T.intercalate` first |
| 2026-02-24 22:16:54 +0100 | <dolio> | Oh. I guess it's just bytestring builders. |
| 2026-02-24 22:16:49 +0100 | <EvanR> | builder is often recommended in case people are trying to form a big sequence from pieces other than just tacking onto the end |
| 2026-02-24 22:16:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-02-24 22:16:31 +0100 | <tomsmeding> | dolio: doesn't seem like you can, but toLazyText should be fine |
| 2026-02-24 22:15:46 +0100 | <EvanR> | then a builder to make a straight lazy list is not helping |
| 2026-02-24 22:15:35 +0100 | <tomsmeding> | or, well, it does, but then it (kind of) synchronises with the one in the RTS so they kinda merge |
| 2026-02-24 22:15:35 +0100 | <EvanR> | a lazy text itself is already a lazy list |
| 2026-02-24 22:15:33 +0100 | <dolio> | I think you can directly put a builder, too. |
| 2026-02-24 22:15:08 +0100 | <tomsmeding> | EvanR: also, a Text Builder produces a _lazy_ text, so that doesn't actually create a whole separate buffering step |
| 2026-02-24 22:14:47 +0100 | <dolio> | It's already effectively building a 'buffer' as a lazy list of characters. Builder is just generally a better one. |
| 2026-02-24 22:14:20 +0100 | <tomsmeding> | EvanR: output is already buffered, the actual write(2) call in the kernel is only called when stdout is flushed, which, if you don't write newlines, happens only every 4096 bytes or so |
| 2026-02-24 22:14:09 +0100 | <lantti> | I'm currently trying to figure out how the profiling works, so I can get a better idea of the bottlenecks |
| 2026-02-24 22:13:58 +0100 | <EvanR> | kind of like buffering your own buffer before it gets to the OS buffers, which are then buffered |
| 2026-02-24 22:13:41 +0100 | <EvanR> | this sounds so backwards |
| 2026-02-24 22:13:29 +0100 | <tomsmeding> | writing everything in a big buffer and then sending that buffer into stdout may be quite a bit faster |
| 2026-02-24 22:13:16 +0100 | <EvanR> | facepalm |
| 2026-02-24 22:13:04 +0100 | <tomsmeding> | taking an MVar for outputting like 5 bytes may not be optimal |
| 2026-02-24 22:12:51 +0100 | <tomsmeding> | well, putStrLn takes an MVar on stdout |
| 2026-02-24 22:12:45 +0100 | <EvanR> | just print them in order |
| 2026-02-24 22:12:36 +0100 | <EvanR> | isn't builder in appropriate here since we already have a lazy list of the things to print, in order |
| 2026-02-24 22:12:24 +0100 | <tomsmeding> | right, possibly laziness makes it look like it is, even if it actually isn't |
| 2026-02-24 22:12:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |