Newest at the top
| 2024-11-14 16:11:06 +0100 | <bailsman> | the benchmark is using `nf` so that should be forcing both the source list and the destination list to be actually created now, right? But it's exactly as fast as before |
| 2024-11-14 16:11:06 +0100 | <geekosaur> | right, I'm not sure it's the place to start buit the fundamentals of the zipper technique are http://strictlypositive.org/diff.pdf |
| 2024-11-14 16:11:03 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 246 seconds) |
| 2024-11-14 16:10:43 +0100 | <bailsman> | doing smallRecsDeep = smallRecs `deepseq` smallRecs did not change anything either |
| 2024-11-14 16:10:04 +0100 | <haskellbridge> | <Bowuigi> You might need the slightly more general idea of the "derivative of a data structure" but it is essentially the same idea |
| 2024-11-14 16:09:51 +0100 | <geekosaur> | I don't know of any examples, but that doesn't seem much different from (say) a zipper for red-black trees |
| 2024-11-14 16:08:52 +0100 | <ph88> | geekosaur, i was mistaken, i have actually not one data structure to fit all of the tree but multiple like `data Program = Program a [Statement]` and `data Statement = Statement a Expression` (dummy examples). Can tree zippers work with this? or do i need another technique? |
| 2024-11-14 16:08:48 +0100 | <geekosaur> | optimizing lists by treating them as loops is another |
| 2024-11-14 16:08:20 +0100 | <haskellbridge> | <Bowuigi> You can force the first constructor (IIRC) with "seq", every constructor with "length" and the entire thing with "deepseq". Yeah Haskell has evaluation control |
| 2024-11-14 16:08:18 +0100 | <geekosaur> | build/foldr is one |
| 2024-11-14 16:08:14 +0100 | <geekosaur> | there's multiple levels of cheating |
| 2024-11-14 16:08:02 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2024-11-14 16:07:27 +0100 | <EvanR> | why are we trying to cripple haskell again by "actually creating lists" and enabling Strict xD |
| 2024-11-14 16:07:23 +0100 | <bailsman> | Or did the compiler optimize that out |
| 2024-11-14 16:06:57 +0100 | <haskellbridge> | <Bowuigi> Laziness is something you will want to learn at some point but for now you can use "{-# LANGUAGE Strict #-}" if you don't want laziness |
| 2024-11-14 16:06:43 +0100 | <bailsman> | How do I force it to actually create the list? `smallRecs = force [... | ... <- ...]` did not change anything, map is still as fast as it was before. Maybe it wasn't cheating? |
| 2024-11-14 16:05:47 +0100 | <geekosaur> | IIRC it's in OCaml instead of Haskell so it won't cover things like laziness, but it'll still teach you the zen of functional programming |
| 2024-11-14 16:04:53 +0100 | <haskellbridge> | <Bowuigi> Because it is different to what you are used to. Functional languages can do optimizations that imperative langs can't, like list/fold/map/hylo fusion (AKA removing intermediate computations while traversing or creating stuff), safe(-ish) inlining, laziness stuff, etc |
| 2024-11-14 16:04:47 +0100 | <geekosaur> | I think maybe if you want to understand idiomatic-and-performant, it might be worth looking at Chris Okasaki's thesis on functional data structures |
| 2024-11-14 16:04:02 +0100 | <EvanR> | also forget python for good measure |
| 2024-11-14 16:03:49 +0100 | <EvanR> | advice: forget anything you know about C and C++ and learn haskell |
| 2024-11-14 16:03:33 +0100 | <bailsman> | EvanR: That would be helpful advice if I automatically understood how to write idiomatic-and-perforant code in Haskell - but unfortunately that wisdom is as yet inaccesible to me :P |
| 2024-11-14 16:03:24 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-14 16:03:18 +0100 | <geekosaur> | (including C /gd&r) |
| 2024-11-14 16:02:59 +0100 | <EvanR> | haskell is weird that way. But it's actually not smart to write C in any language generally |
| 2024-11-14 16:02:33 +0100 | <geekosaur> | because everyone wants speeeeeeed |
| 2024-11-14 16:02:30 +0100 | <EvanR> | yes, when you "write C in any language" in haskell, it's not optimal. Surprise |
| 2024-11-14 16:02:19 +0100 | <bailsman> | Why is understand performance of things so difficult aaargh |
| 2024-11-14 16:01:46 +0100 | <bailsman> | It has to actually be stored and loaded from memory to be a fair comparison. |
| 2024-11-14 16:01:11 +0100 | <bailsman> | I need to benchmark the list already existing |
| 2024-11-14 16:01:05 +0100 | <bailsman> | Hey, no, that's cheating. Then I've written my benchmark wrong |
| 2024-11-14 16:00:40 +0100 | <geekosaur> | in the optimal case, the list is never constructed as such, elements are fed directly to map as they are created |
| 2024-11-14 16:00:07 +0100 | <geekosaur> | bailsman, construction of the list vs. mapping through the list |
| 2024-11-14 15:59:43 +0100 | <haskellbridge> | <Bowuigi> GHC does dark magic to not actually use a linked list |
| 2024-11-14 15:59:42 +0100 | <bailsman> | I am just doing [SmallRecord] -> [SmallRecord] by updating a field in the record |
| 2024-11-14 15:59:34 +0100 | <geekosaur> | ph88, that's what I meant by style but also a mediawiki upgrade is what started the whole outage thing |
| 2024-11-14 15:59:10 +0100 | <ph88> | wiki got a makeover? i remember being it uglier |
| 2024-11-14 15:59:04 +0100 | <bailsman> | I don't know what any of those words mean |
| 2024-11-14 15:58:44 +0100 | <geekosaur> | if your generation and consumption are written correctly, they get pipelined |
| 2024-11-14 15:58:25 +0100 | <bailsman> | Or does it turn into an in-place algorithm? |
| 2024-11-14 15:58:09 +0100 | <bailsman> | What do you mean by tight loop? Surely it still has to allocate all the elements for the new list? |
| 2024-11-14 15:57:50 +0100 | <haskellbridge> | <Bowuigi> Gérard Huet's pearl "The Zipper" is also good if you don't mind OCaml |
| 2024-11-14 15:56:57 +0100 | <geekosaur> | it uses a tree as the example data structure, where most of them focus on lists which are the easiest case |
| 2024-11-14 15:56:30 +0100 | <geekosaur> | https://wiki.haskell.org/Zipper |
| 2024-11-14 15:56:30 +0100 | <bailsman> | Awesome! Thank you to whoever fixed it |
| 2024-11-14 15:56:29 +0100 | <geekosaur> | actually hgolden in #h-i said there are still some style issues |
| 2024-11-14 15:56:16 +0100 | <geekosaur> | just found that, yes |
| 2024-11-14 15:56:08 +0100 | <hellwolf> | (wiki has been fixed) |
| 2024-11-14 15:56:06 +0100 | <bailsman> | I have some parts right now that use random access. But was thinking maybe I don't want to pay a 4x performance penalty just for random access. |
| 2024-11-14 15:55:53 +0100 | <geekosaur> | sadly the first reference that comes to mind is on the wiki… |