Logs: liberachat/#haskell
| 2021-07-06 17:17:38 | <qrpnxz> | lol what |
| 2021-07-06 17:18:08 | <safinaskar> | anyway function checkAmbiguity is not bottleneck |
| 2021-07-06 17:18:10 | <dsal> | Having your own type is fine and readable and stuff, but Either is a functor, applicative, monad, foldable, traversable, a semigroup, etc... Things that would generally make your code be easier and probably faster. |
| 2021-07-06 17:18:18 | × | smichel17 quits (~smichel17@2601:193:8201:330::1) (Quit: smichel17) |
| 2021-07-06 17:18:40 | <dsal> | Not being willing to try Haskell isn't a good start. I don't think I can help you much. |
| 2021-07-06 17:19:17 | → | jneira[m] joins (~jneira@233.red-176-87-44.dynamicip.rima-tde.net) |
| 2021-07-06 17:19:22 | <qrpnxz> | wym, he wrote a whole lib |
| 2021-07-06 17:19:32 | <dsal> | Oh yeah, never mind. :P |
| 2021-07-06 17:19:38 | <qrpnxz> | lol |
| 2021-07-06 17:20:10 | → | chddr joins (~Thunderbi@91.226.34.151) |
| 2021-07-06 17:20:30 | <monochrom> | You can weaken that to "not willing to try idiomatic haskell" and it would have some merit |
| 2021-07-06 17:20:44 | → | P1RATEZ joins (piratez@user/p1ratez) |
| 2021-07-06 17:21:17 | <ahdyt> | monochrom do you have a github acc with bunch of haskell stuff? |
| 2021-07-06 17:21:18 | <qrpnxz> | let's parameterize it in-case we need it again xd |
| 2021-07-06 17:21:27 | → | boxscape joins (~boxscape@user/boxscape) |
| 2021-07-06 17:21:39 | <monochrom> | @quote monochrom pointless.debate |
| 2021-07-06 17:21:39 | <lambdabot> | monochrom says: All pointless debates can be settled by going polymorphic. |
| 2021-07-06 17:22:19 | <monochrom> | https://github.com/treblacy |
| 2021-07-06 17:22:58 | <safinaskar> | dsal: "This is basically a fold, but with a lot of indirection" - my code looks similar to what i used to write before (c++). i don't want to convert it to fold, i hope compiler will convert it for me. anyway all STRef manipulations happen outside of inner loop |
| 2021-07-06 17:23:10 | <monochrom> | Please ignore the fact that I have a fork of cabal. IIRC I was only thinking "what does this button do?" |
| 2021-07-06 17:23:24 | <dsal> | lol |
| 2021-07-06 17:24:18 | <qrpnxz> | he's not bringing up the fold because it's some kind of crutch for functional programmers, it's abstraction over almost every container reduction ever. It's to help you write code! |
| 2021-07-06 17:25:54 | <dsal> | "hope compiler will convert" [nine STRef calls in an inner loop to a fold] |
| 2021-07-06 17:25:59 | <safinaskar> | qrpnxz: https://termbin.com/i44b - i hate if..then..else. Because it is hard to see where "else" branch ended. So, I usually use "case ... { True -> ...; False -> ... }" instead with braces {}. Closing brace always tell me where this construction ends |
| 2021-07-06 17:25:59 | × | jippiedoe quits (~david@2a02-a44c-e14e-1-bf09-cdaf-695c-5a88.fixed6.kpn.net) (Ping timeout: 252 seconds) |
| 2021-07-06 17:26:33 | <dsal> | safinaskar: Other people have to read your code and you have to read other people's code. If you reject the local idioms, nobody is going to have a good time. |
| 2021-07-06 17:26:52 | → | shapr joins (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-06 17:27:04 | <qrpnxz> | it ends at the end of the expression :) |
| 2021-07-06 17:27:06 | <dolio> | Writing stuff to look like C++ and expecting GHC to turn it into effective Haskell code isn't a particularly realistic expectation. |
| 2021-07-06 17:27:31 | <qrpnxz> | tbf that's how i get my haskell programs to run as fast as C |
| 2021-07-06 17:27:35 | <qrpnxz> | maybe he didn't do -O2 |
| 2021-07-06 17:27:40 | × | notzmv quits (~zmv@user/notzmv) (Ping timeout: 246 seconds) |
| 2021-07-06 17:27:40 | <qrpnxz> | safinaskar, did you do -O2 |
| 2021-07-06 17:27:53 | <monochrom> | I don't mind unrealistic expectation. I have my share of unrealistic expectations of humans, too. |
| 2021-07-06 17:28:40 | → | Lycurgus joins (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-06 17:28:43 | <monochrom> | Namely, at the meta level, I unrealistically expect that programmers go "I don't really know, but I hope, but I will actually empirically verify at the very least". |
| 2021-07-06 17:28:44 | <dsal> | I like to write code I can read first, and then if it's too slow, sprinkle in ugly. |
| 2021-07-06 17:29:12 | <qrpnxz> | sounds reasonable to me |
| 2021-07-06 17:29:24 | <monochrom> | Well, in the real world, programmers simply kill the "empirically verify" part. Whatever they hope, they just assume it will happen, then pretend to be very surprised that it never does. |
| 2021-07-06 17:29:49 | <qrpnxz> | i hope not |
| 2021-07-06 17:29:55 | <monochrom> | :) |
| 2021-07-06 17:30:00 | <dminuoso> | Sounds about right, monochrom. |
| 2021-07-06 17:30:04 | <qrpnxz> | rip |
| 2021-07-06 17:30:15 | <qrpnxz> | can we at least theoretically verify |
| 2021-07-06 17:30:18 | <safinaskar> | qrpnxz: "tbf that's how i get my haskell programs to run as fast as C" - how?! |
| 2021-07-06 17:30:19 | → | notzmv joins (~zmv@user/notzmv) |
| 2021-07-06 17:30:34 | <safinaskar> | qrpnxz: "maybe he didn't do -O2" - i did (i did -O3) |
| 2021-07-06 17:30:44 | <dminuoso> | I guess that's how bugs arise in the first place. It's because we implicitly assume our code does what we think it does, without having tests to assert these properties about it. |
| 2021-07-06 17:31:11 | <monochrom> | cabal already does -O by default. Very few code shows a difference between -O and -O2. |
| 2021-07-06 17:31:44 | <monochrom> | -O3 doesn't exist. |
| 2021-07-06 17:31:44 | <dsal> | I had a huge performance problem in a codebase once before someone pointed out that the build system was running without optimization. |
| 2021-07-06 17:31:54 | <dminuoso> | safinaskar: Here we go, -O3 is the same as -O2! |
| 2021-07-06 17:31:57 | <dsal> | -O3 is a spoiler. |
| 2021-07-06 17:32:03 | × | gentauro quits (~gentauro@user/gentauro) (Quit: leaving) |
| 2021-07-06 17:32:03 | → | shapr` joins (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-07-06 17:32:06 | <dminuoso> | This already is a false assumption that -O3 does more than -O2. |
| 2021-07-06 17:32:15 | <monochrom> | or rather, -O3 is undefined behaviour. |
| 2021-07-06 17:32:18 | → | gentauro joins (~gentauro@user/gentauro) |
| 2021-07-06 17:32:29 | <dminuoso> | But I guess that's what you get for using compiler flags without first checking the user manual. :-) |
| 2021-07-06 17:32:38 | <monochrom> | But what surprised me is that, with that logic, why not -O42 |
| 2021-07-06 17:32:44 | × | johnw quits (~johnw@2600:1700:cf00:db0:580c:2973:6ceb:6156) (Quit: ZNC - http://znc.in) |
| 2021-07-06 17:33:17 | <dminuoso> | monochrom: Im guessing the reason is the same for assuming that assumptions that hold for C++ compilers hold for GHC. |
| 2021-07-06 17:33:18 | → | johnw joins (~johnw@2600:1700:cf00:db0:edf9:8c5b:5a8d:2f85) |
| 2021-07-06 17:33:54 | <dminuoso> | If clang/gcc have a -O3 flag, then I can see how people might blindly assume that GHC also has a -O3. If GHC then happily accepts it.. |
| 2021-07-06 17:33:58 | <qrpnxz> | safinaskar, it's possible to go as fast as C really. GHC optimize a lot. But often i have had to basically turn a lot of the code imperative and depending on the problem sprinkle strictness here and there. to be fair to haskell, the imperative version of the haskell code is: safer semantically, memory managed, easier to change, not ever really bigger than the C version. And another point, i'm not a super e |
| 2021-07-06 17:33:58 | <qrpnxz> | xperienced haskell programmer. My simpler program might have been able to go faster if I just used the abstraction more efficiently rather than wrote it like C |
| 2021-07-06 17:34:00 | × | shapr quits (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 272 seconds) |
| 2021-07-06 17:34:23 | shapr` | is now known as shapr |
| 2021-07-06 17:34:31 | <monochrom> | "gcc -O42" is not an error. I just tried. I expect an ardent C or C++ programmer to go with that for future-proof-ness. |
| 2021-07-06 17:34:58 | <c_wraith> | what does gcc think it means? |
| 2021-07-06 17:35:03 | <qrpnxz> | lol mono |
| 2021-07-06 17:35:14 | <monochrom> | I am too lazy to find out what it really means. >:) |
| 2021-07-06 17:35:34 | c_wraith | deepseqs monochrom |
| 2021-07-06 17:35:42 | <qrpnxz> | lol |
| 2021-07-06 17:36:05 | <dminuoso> | Obligatory: https://ro-che.info/ccc/11 |
| 2021-07-06 17:36:13 | <monochrom> | I do hope the gcc people are trolling us and do a mod-4 thing. |
| 2021-07-06 17:36:31 | <qrpnxz> | dminuoso, lmao nice |
| 2021-07-06 17:36:31 | <monochrom> | haha |
| 2021-07-06 17:37:36 | × | jneira[m] quits (~jneira@233.red-176-87-44.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2021-07-06 17:37:50 | <dsal> | qrpnxz: I've rewritten code to use STRef in very specific ways that I had a good intuition that might speed things up. e.g., working with a large array and needing to change small bits regularly. The rewrite gave me something to compare against and see whether it was faster and faster enough to warrant the change. |
| 2021-07-06 17:38:12 | <safinaskar> | monochrom: "But what surprised me is that, with that logic, why not -O42" - because -O3 is maximal optimization level in gcc and clang :) (and i know that -O3 and -O2 are same in ghc) |
| 2021-07-06 17:38:34 | × | alx741 quits (~alx741@181.196.69.147) (Ping timeout: 240 seconds) |
| 2021-07-06 17:38:46 | <dsal> | For things like this, I'd expect ST to strictly slow down the code. |
| 2021-07-06 17:40:04 | <qrpnxz> | dsal, i think there is also supposed to be magic in data.vector that will let you modify without copying, but i have not trusted it enough to see if it is true. I'm too busy prematurely optimizing xDDD |
| 2021-07-06 17:40:11 | <dsal> | Imagine a compiler that didn't let you make things slower. |
| 2021-07-06 17:41:01 | <monochrom> | The magic in vector is limited to: update from 0 to n-1; now update from 0 to n-1 again; etc |
| 2021-07-06 17:41:16 | <qrpnxz> | write the factors of large numbers to the network on every op, no way to optimize that :D |
| 2021-07-06 17:41:20 | <monochrom> | There are further limitations. |
| 2021-07-06 17:41:47 | → | derelict joins (~derelict@user/derelict) |
| 2021-07-06 17:41:47 | <qrpnxz> | can someone make a Slow monad that does that on every bind |
| 2021-07-06 17:41:52 | <qrpnxz> | lmao |
| 2021-07-06 17:42:11 | <monochrom> | So for example if you have a pipeline like "filter . map . generate" you're good. |
| 2021-07-06 17:43:07 | <qrpnxz> | right the fusing stuff is more expected, but i meant things like say the bulk update procedure and the like. The more targeted edits. Or snoc for example |
| 2021-07-06 17:43:08 | <c_wraith> | vector's fusion framework is too complicated. |
| 2021-07-06 17:43:50 | <qrpnxz> | ig with linear types it would be easier to make it happen |
| 2021-07-06 17:44:00 | <c_wraith> | 4 different internal representations, 3 of which exist only to enable certain kinds of fusion, and should never be observable to the end user? |
| 2021-07-06 17:44:22 | <dminuoso> | At the end clang/gcc are quite good at local aggressive optimizations. They come with things like loop invariant motion, loop unrolling, vectorization, loop fission/distribution.. these are things that GHC largely doesn't do or effectively.. |
| 2021-07-06 17:44:26 | <qrpnxz> | ah yeah, i've tried looking at the source it's utterly inscrutable, but it works ig |
| 2021-07-06 17:44:35 | <monochrom> | Oh, linear types makes hopeful a different optimization. |
| 2021-07-06 17:44:39 | <dminuoso> | So to get even close to performance in Haskell, you have to cater to GHC *a* *lot* |
All times are in UTC.