Logs: freenode/#haskell
| 2020-11-15 16:18:25 | × | avdb quits (~avdb@ip-83-134-109-106.dsl.scarlet.be) (Ping timeout: 260 seconds) |
| 2020-11-15 16:20:45 | × | o1lo01ol1o quits (~o1lo01ol1@bl11-140-216.dsl.telepac.pt) (Ping timeout: 240 seconds) |
| 2020-11-15 16:21:44 | × | geekosaur quits (ac3a8f2f@172.58.143.47) (Ping timeout: 245 seconds) |
| 2020-11-15 16:21:54 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 2020-11-15 16:22:49 | × | elfets quits (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Quit: Leaving) |
| 2020-11-15 16:23:45 | × | alx741 quits (~alx741@186.178.110.6) (Ping timeout: 240 seconds) |
| 2020-11-15 16:24:29 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-15 16:26:00 | → | elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
| 2020-11-15 16:26:37 | × | jakalx quits (~jakalx@base.jakalx.net) (Ping timeout: 260 seconds) |
| 2020-11-15 16:26:42 | <kuribas> | Why do libraries handwrite their transformers? |
| 2020-11-15 16:28:25 | <kuribas> | with a generic cps'ed exceptT you could simply replace the current ExceptT with the CPSd version, and get the same performance gains, but without that difficulties. |
| 2020-11-15 16:29:22 | × | lemald quits (~eddie@capybara.lemald.org) (Quit: WeeChat 2.7.1) |
| 2020-11-15 16:30:49 | <kuribas> | for example, attoparsec uses a CPSed error handling, but it is hard to understand. |
| 2020-11-15 16:31:43 | × | toorevitimirp quits (~tooreviti@117.182.180.118) (Quit: Konversation terminated!) |
| 2020-11-15 16:32:51 | <Rembane> | My guess is that they do it for (real or made up) performance gains. |
| 2020-11-15 16:33:32 | → | lemald joins (~eddie@capybara.lemald.org) |
| 2020-11-15 16:33:56 | <kuribas> | the performance gain is real, but you could get the same with a custom ExceptT transformer IMO. |
| 2020-11-15 16:34:24 | <davean> | kuribas: prove it. GHC often fails to merge transformer stacks. |
| 2020-11-15 16:34:36 | <kuribas> | davean: when? |
| 2020-11-15 16:34:44 | <kuribas> | davean: in my tests it worked fine... |
| 2020-11-15 16:34:44 | <davean> | "almost always" |
| 2020-11-15 16:34:59 | <davean> | I've never actually seen it merge them fully. It gets close |
| 2020-11-15 16:35:05 | <kuribas> | davean: when the stack is in different modules? In the same module? |
| 2020-11-15 16:35:32 | <kuribas> | or when it becomes so big it doesn't inline the functions? |
| 2020-11-15 16:35:38 | <davean> | see the part where I've said I've never seen it. |
| 2020-11-15 16:35:44 | <davean> | Litterly never seen it. |
| 2020-11-15 16:35:53 | <kuribas> | I've seen it many times... |
| 2020-11-15 16:36:00 | <davean> | Have you checked the actual core? |
| 2020-11-15 16:36:04 | <kuribas> | yes |
| 2020-11-15 16:36:10 | <davean> | Congrats. |
| 2020-11-15 16:36:12 | <kuribas> | with optimizations on of course. |
| 2020-11-15 16:36:27 | <kuribas> | davean: I'll do a test and report the result :) |
| 2020-11-15 16:36:41 | <kuribas> | no point in arguing when you can test :) |
| 2020-11-15 16:37:01 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2020-11-15 16:38:24 | <dminuoso> | Well, in case of attoparsec, CPS avoids the need for fusion in the first place. |
| 2020-11-15 16:38:26 | × | mputz quits (~Thunderbi@dslb-084-058-211-084.084.058.pools.vodafone-ip.de) (Ping timeout: 256 seconds) |
| 2020-11-15 16:38:47 | <dminuoso> | If you encode it with sum types, you rely on GHC to do deforestration |
| 2020-11-15 16:38:47 | <kuribas> | dminuoso: to get better compile times? |
| 2020-11-15 16:38:47 | <davean> | Yah fusion is really good. Its just not entirely reliable. |
| 2020-11-15 16:39:14 | <dminuoso> | kuribas: Not just that, you get much more reliable performance, rather than relying on GHC to do it for you |
| 2020-11-15 16:39:27 | → | Amras joins (~Amras@unaffiliated/amras0000) |
| 2020-11-15 16:39:33 | <dminuoso> | Which can be dependent on build flags, how well inlining can take place, GHC version |
| 2020-11-15 16:40:52 | <kuribas> | letting the compiler do the work is a good thing IMO |
| 2020-11-15 16:41:35 | <kuribas> | I don't mind trading compile times for developper times, easier to understand code, and less chance of bugs. |
| 2020-11-15 16:42:05 | → | Chi1thangoo joins (~Chi1thang@87.112.60.168) |
| 2020-11-15 16:42:50 | × | p-core quits (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515) (Remote host closed the connection) |
| 2020-11-15 16:44:15 | → | alx741 joins (~alx741@186.178.110.6) |
| 2020-11-15 16:44:29 | <dminuoso> | Its not about whether GHC can take work off you |
| 2020-11-15 16:44:33 | <dminuoso> | Its whether GHC can reliably do it for you. |
| 2020-11-15 16:45:10 | <kuribas> | I don't need a 100% gain, 80% will do. |
| 2020-11-15 16:45:13 | <kuribas> | but not 20% |
| 2020-11-15 16:45:28 | → | DavidEichmann joins (~david@62.110.198.146.dyn.plus.net) |
| 2020-11-15 16:45:55 | <davean> | well most of the community thinks putting in a few extra minutes to get the 100% is more than worth it for core libraries. |
| 2020-11-15 16:46:12 | <kuribas> | yeah, I guess so |
| 2020-11-15 16:46:20 | → | knupfer joins (~Thunderbi@i5E86B494.versanet.de) |
| 2020-11-15 16:46:27 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:c56c:6f1e:9a5c:a8b9) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-11-15 16:46:44 | <davean> | Also, like, often combining them can make the code conceptually simpler because you're no longer dealing with the product. Some cases thats not true. It varies. |
| 2020-11-15 16:46:52 | <dminuoso> | Right, especially since with libraries the compiler choice (version and flags) is out of the library authors control |
| 2020-11-15 16:47:03 | × | knupfer quits (~Thunderbi@i5E86B494.versanet.de) (Client Quit) |
| 2020-11-15 16:47:10 | <dminuoso> | So by using CPS, the library author ensures you get optimizations without you your help |
| 2020-11-15 16:47:15 | → | knupfer joins (~Thunderbi@200116b82c37cc00b9ffe288e94dd584.dip.versatel-1u1.de) |
| 2020-11-15 16:47:24 | <kuribas> | dminuoso: I am not advocating against CPS |
| 2020-11-15 16:47:43 | <kuribas> | dminuoso: I am proposing a CPSed version of ExceptT |
| 2020-11-15 16:48:27 | <kuribas> | that could be used as drop-in replacement for ExceptT |
| 2020-11-15 16:49:22 | <dminuoso> | ah |
| 2020-11-15 16:50:21 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:c56c:6f1e:9a5c:a8b9) |
| 2020-11-15 16:50:56 | <davean> | kuribas: oh, you know that inlining often ruins performance on non-microbenchmarks, right? Also in particular on lower-end CPUs. |
| 2020-11-15 16:51:15 | <kuribas> | what do you mean? |
| 2020-11-15 16:51:30 | <kuribas> | ghc compile times? |
| 2020-11-15 16:51:43 | → | goldcell joins (~goldcell@2607:fea8:2c40:307::50de) |
| 2020-11-15 16:51:56 | <davean> | Inlining increases code size, and when you start spilling cache, or even not fitting in microop cache, performance degrades. So large pieces of code are often better off *without* inlining to get the sharing. |
| 2020-11-15 16:51:59 | <goldcell> | does haskell get around the need to conditionally express variables? |
| 2020-11-15 16:52:29 | × | wwwww quits (~wwwww@unaffiliated/wwwww) (Ping timeout: 260 seconds) |
| 2020-11-15 16:52:30 | <davean> | kuribas: inlining is a common case where a local optimization becomes a global pessimisation |
| 2020-11-15 16:52:34 | <davean> | goldcell: what is |
| 2020-11-15 16:52:43 | <davean> | goldcell: what is "conditionally express variables"? |
| 2020-11-15 16:53:07 | <kuribas> | davean: yes, but in the case you want the inlining. |
| 2020-11-15 16:53:13 | <kuribas> | "this case" |
| 2020-11-15 16:53:21 | <davean> | kuribas: in particular you see this a lot with serialization/deserialization libraries. |
| 2020-11-15 16:53:25 | <goldcell> | e.g. when a value can be a null type or the type you actually want |
| 2020-11-15 16:53:51 | <davean> | goldcell: what is a "null type"? |
| 2020-11-15 16:53:53 | <ski> | we have `Maybe', for absence of values |
| 2020-11-15 16:54:05 | <davean> | A type is specific |
| 2020-11-15 16:54:15 | <davean> | you could designate one as ... no, I don't think "null type" makes sense. |
| 2020-11-15 16:54:25 | × | machinedgod quits (~machinedg@24.105.81.50) (Ping timeout: 265 seconds) |
| 2020-11-15 16:54:30 | <kuribas> | davean: inlining also allows for other optimizations, like deforestation... |
| 2020-11-15 16:54:39 | <davean> | kuribas: sure. |
| 2020-11-15 16:54:42 | → | wwwww joins (~wwwww@unaffiliated/wwwww) |
| 2020-11-15 16:54:50 | <kuribas> | without inlining, functional programs would be very slow. |
| 2020-11-15 16:55:11 | <kuribas> | maybe GRIN could improve on this. |
| 2020-11-15 16:55:29 | <kuribas> | by only inlining functions where you know there will be optimizations done. |
| 2020-11-15 16:55:52 | <p0a> | goldcell: yeah it does |
| 2020-11-15 16:55:57 | <davean> | kuribas: we use inlining to get to deforestation, but thats not truly paired IMO |
| 2020-11-15 16:56:13 | <p0a> | goldcell: (1+) <$> Just 2 ==> Just 3, whereas if you do (1+) <$> Nothing you get Nothing |
| 2020-11-15 16:56:13 | <davean> | goldcell: are you sure you don't mean null values? |
| 2020-11-15 16:56:24 | <goldcell> | ski, yeah I think that's what I'm looking for |
| 2020-11-15 16:56:40 | <davean> | Maybe covers values being null, not types though? |
| 2020-11-15 16:57:02 | <davean> | (and even in C, there is "null" but there isn't a "null type", each type's null is different) |
| 2020-11-15 16:57:17 | <davean> | (Though with REALLY complicated rules saying they have to compare the same and such) |
| 2020-11-15 16:57:28 | <goldcell> | I was just programming in go, where it is called nil |
All times are in UTC.