Newest at the top
| 2024-11-14 15:55:03 +0100 | <geekosaur> | it actually compiles down to a tight loop in most cases, not the C-style linked list you might expect |
| 2024-11-14 15:54:16 +0100 | <geekosaur> | right, map's going to be one of those cases that [] will work very well for |
| 2024-11-14 15:54:11 +0100 | <hellwolf> | "data Array i e" is also under rated. |
| 2024-11-14 15:54:06 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6c70:1ac0:d127:74dd) hgolden |
| 2024-11-14 15:53:38 +0100 | <bailsman> | Data.Vector.Map over a vector is consistently 4x slower than regular map over []. (Data.Map is 10x slower) |
| 2024-11-14 15:53:14 +0100 | <haskellbridge> | <Bowuigi> Data.Map is the first one that comes to mind |
| 2024-11-14 15:52:55 +0100 | <haskellbridge> | <Bowuigi> Have you tried any functional random access data structures? |
| 2024-11-14 15:52:00 +0100 | <bailsman> | I thought I needed to do a lot of random indexing. But, now I'm not sure if I shouldn't instead redesign everything so that it does not require random access. |
| 2024-11-14 15:51:04 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:7ee4:dffc:4616:9e2a) |
| 2024-11-14 15:50:40 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) misterfish |
| 2024-11-14 15:50:37 +0100 | <haskellbridge> | <Bowuigi> Reasoning imperatively in functional languages leads to bad performance in general |
| 2024-11-14 15:50:23 +0100 | <geekosaur> | allocation, gc, and iteration are all optimized because it's so common |
| 2024-11-14 15:49:51 +0100 | <hellwolf> | I mean, if you need to do a log of random indexing, it got to be slow. but for stream processing, it is probably the most efficient |
| 2024-11-14 15:49:41 +0100 | <geekosaur> | if all you're doing is iterating through them, consider that ghc is optimized for that case: think of a list as a loop encoded as data |
| 2024-11-14 15:48:48 +0100 | <bailsman> | Plain old lists are consistently the fastest. I find that somewhat confusing, since in imperative languages linked lists are often slow. |
| 2024-11-14 15:47:02 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) billchenchina |
| 2024-11-14 15:41:12 +0100 | weary-traveler | (~user@user/user363627) (Quit: Konversation terminated!) |
| 2024-11-14 15:39:55 +0100 | Cadey | (~cadey@perl/impostor/xe) (Quit: WeeChat 4.4.2) |
| 2024-11-14 15:36:41 +0100 | yaroot | (~yaroot@2400:4052:ac0:d901:1cf4:2aff:fe51:c04c) yaroot |
| 2024-11-14 15:36:27 +0100 | yaroot | (~yaroot@2400:4052:ac0:d901:1cf4:2aff:fe51:c04c) (Read error: Connection reset by peer) |
| 2024-11-14 15:35:59 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |
| 2024-11-14 15:35:45 +0100 | ash3en | (~Thunderbi@149.222.147.110) (Client Quit) |
| 2024-11-14 15:35:40 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-14 15:35:09 +0100 | ash3en | (~Thunderbi@149.222.147.110) ash3en |
| 2024-11-14 15:30:28 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 15:18:37 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2024-11-14 15:16:32 +0100 | mari-estel | (~mari-este@user/mari-estel) (Quit: errands) |
| 2024-11-14 15:10:02 +0100 | <dminuoso> | bailsman: Do you have the actual code and the generated core to look at? |
| 2024-11-14 15:06:31 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds) |
| 2024-11-14 15:05:34 +0100 | ash3en | (~Thunderbi@149.222.147.110) (Client Quit) |
| 2024-11-14 15:01:26 +0100 | ash3en | (~Thunderbi@149.222.147.110) ash3en |
| 2024-11-14 14:56:06 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-11-14 14:50:45 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2024-11-14 14:48:24 +0100 | misterfish | (~misterfis@31-161-39-137.biz.kpn.net) (Ping timeout: 276 seconds) |
| 2024-11-14 14:38:28 +0100 | mari-estel | (~mari-este@user/mari-estel) mari-estel |
| 2024-11-14 14:35:46 +0100 | acidjnk | (~acidjnk@p200300d6e7283f73687bc11ede7922f8.dip0.t-ipconnect.de) acidjnk |
| 2024-11-14 14:33:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-14 14:32:56 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-14 14:24:13 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |
| 2024-11-14 14:18:58 +0100 | <bailsman> | I think if you need a mutable algorithm maybe you should do a CFFI or something. |
| 2024-11-14 14:18:30 +0100 | <geekosaur> | but that's built into GC and I don't think vector can take advantage of it |
| 2024-11-14 14:18:13 +0100 | <bailsman> | I tried look at it with -ddump-simpl and the mutable version doesn't compile to simple code at all. What should be like 5 assembly instructions turns into several pages of assembly. |
| 2024-11-14 14:18:05 +0100 | <geekosaur> | for Array it's split into "cards" and modifications within a single card are batched so only a single copy needs to be done by the mutator, AIUI |
| 2024-11-14 14:17:21 +0100 | <geekosaur> | it's still going to do copies, I think, and more of them the more elements you touch. but I'mnot sure how that plays out for vector |
| 2024-11-14 14:16:51 +0100 | <geekosaur> | pretty much |
| 2024-11-14 14:16:30 +0100 | <bailsman> | If you expect to touch every element, just use map. |
| 2024-11-14 14:15:25 +0100 | <bailsman> | So the use cases are considerably more niche than I thought. Like if you need to exchange two elements or something, the pure version would have to copy the entire thing and the mutable version only two elements. But for most cases, it's a bait? |
| 2024-11-14 14:14:28 +0100 | <geekosaur> | they will definitely have costs you don't incur with immutable vectors |
| 2024-11-14 14:13:44 +0100 | <bailsman> | Huh, are mutable vectors a scam? `VM.iforM_ mv $ \i x -> VM.write mv i (updateValue x)` is considerably slower for simple objects, and barely faster than `map updateValue` even for large complex objects. |
| 2024-11-14 14:12:30 +0100 | <kuribas`> | If you would evaluate the second element of the list, the debugger should not halt the whole expression. |