Logs: freenode/#haskell
| 2020-10-06 02:18:59 | <hololeap> | how important is it to know where to add INLINE pragmas these days? will compiling with -O2 on the latest GHC be sufficient without worrying about using INLINE? |
| 2020-10-06 02:19:26 | × | solonarv quits (~solonarv@astrasbourg-653-1-252-112.w92-161.abo.wanadoo.fr) (Ping timeout: 272 seconds) |
| 2020-10-06 02:19:31 | hololeap | is actually using GHC 8.8.4, not the latest one |
| 2020-10-06 02:20:22 | <dolio> | Depends on the program. |
| 2020-10-06 02:20:42 | → | berberman_ joins (~berberman@2408:8207:2560:ee60::a44) |
| 2020-10-06 02:20:46 | → | solonarv joins (~solonarv@adijon-655-1-70-207.w90-13.abo.wanadoo.fr) |
| 2020-10-06 02:23:19 | <hololeap> | can you elaborate, dolio? |
| 2020-10-06 02:23:42 | <dolio> | Well, if I remove all the inline pragmas from vector-algorithms, it will be a lot slower. |
| 2020-10-06 02:23:57 | <dolio> | (Unless I compensate in other ways.) |
| 2020-10-06 02:24:07 | × | berberman quits (~berberman@2408:8207:2560:ee60:584e:a9ff:fe9b:d3fe) (Ping timeout: 244 seconds) |
| 2020-10-06 02:24:28 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:f68c:50ff:fe0b:b774) |
| 2020-10-06 02:24:34 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:f68c:50ff:fe0b:b774) (Client Quit) |
| 2020-10-06 02:24:36 | <dsal> | If you need something inlined, or need it not inlined, you should say so. |
| 2020-10-06 02:25:26 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:f68c:50ff:fe0b:b774) |
| 2020-10-06 02:25:30 | <dolio> | That isn't the only significant factor, necessarily. But sometimes it enables important optimizations, and GHC will not automatically inline everything. |
| 2020-10-06 02:25:55 | <dolio> | Inlining everything isn't even really desirable. |
| 2020-10-06 02:25:58 | → | jle` joins (~mstksg@cpe-23-240-75-236.socal.res.rr.com) |
| 2020-10-06 02:25:59 | × | jle` quits (~mstksg@cpe-23-240-75-236.socal.res.rr.com) (Changing host) |
| 2020-10-06 02:25:59 | → | jle` joins (~mstksg@unaffiliated/mstksg) |
| 2020-10-06 02:26:10 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:f68c:50ff:fe0b:b774) (Client Quit) |
| 2020-10-06 02:26:32 | <hololeap> | i don't understand what makes a function needing to be inlined, where GHC wouldn't already do it automatically. is there a good primer on all this? |
| 2020-10-06 02:26:33 | <dsal> | Does GHC ever automatically inline anything? I've had pretty big optimizations from telling it to inline things I thought would be obvious. |
| 2020-10-06 02:26:56 | <dolio> | Well, here's an example from vector-algorithms again. |
| 2020-10-06 02:27:11 | <dolio> | The algorithms need to be inlined so that the code can be specialized to the comparison function. |
| 2020-10-06 02:27:18 | <dsal> | If you have a tiny function you use in a lot of places, copying the instructions will be faster than making a function call. |
| 2020-10-06 02:27:33 | <dolio> | Because if that doesn't happen, the overhead of comparing integers will be massive. |
| 2020-10-06 02:28:01 | → | brandly joins (~brandly@c-73-68-15-46.hsd1.ma.comcast.net) |
| 2020-10-06 02:28:06 | <hololeap> | dsal: what determines the size of a function? |
| 2020-10-06 02:28:09 | <dolio> | Like, a couple instructions on unboxed values vs. function calls on boxed values. |
| 2020-10-06 02:29:19 | <dsal> | hololeap: I mean like, you write the abstraction that makes sense, but if you have something that's called enough that the overhead of calling it makes a difference in your runtime, inlining might help. |
| 2020-10-06 02:29:57 | <dolio> | The actual size of the expression is the size. |
| 2020-10-06 02:30:05 | <dolio> | I'm not sure what exactly the threshold is. |
| 2020-10-06 02:30:39 | <dsal> | If it's a lot of code, and you use it in a lot of places, inlining while make your code a lot bigger and your cache less effective. |
| 2020-10-06 02:31:20 | <dolio> | I'm pretty sure `f x = x + x` is small enough for GHC to decide to inline it automatically. But if you're in doubt, and it matters, it's better to annotate it. |
| 2020-10-06 02:31:31 | × | jle` quits (~mstksg@unaffiliated/mstksg) (Ping timeout: 256 seconds) |
| 2020-10-06 02:31:36 | → | user2 joins (~user@068-190-177-201.res.spectrum.com) |
| 2020-10-06 02:31:49 | <hololeap> | ok, it's becoming clearer |
| 2020-10-06 02:32:33 | × | user2 quits (~user@068-190-177-201.res.spectrum.com) (Client Quit) |
| 2020-10-06 02:33:40 | <dolio> | I've been experimenting with doing vector-algorithms with backpack, and that doesn't require inlining tons of code. |
| 2020-10-06 02:33:52 | <hololeap> | the problem is, i've been spending all my time learning haskell focusing on semantics and getting stuff to compile. i haven't looked into performance or tweaking GHC at all beyond using -O2 every time |
| 2020-10-06 02:33:55 | <dolio> | Because you can specialize the implementation to the comparson/types. |
| 2020-10-06 02:34:42 | <dolio> | Well, it might not matter a whole lot depending on what you're doing. |
| 2020-10-06 02:35:37 | <dolio> | If you're trying to beat C's qsort, though, it matters. |
| 2020-10-06 02:36:44 | <hololeap> | i'm using a lot of newtype wrappers around monad transformer stacks; packing and unpacking while using inherited typeclasses. and a lot of production code i've seen uses INLINE a lot for this type of thing. but i wonder how much of it is necessary. |
| 2020-10-06 02:37:18 | → | zoom55AA joins (~zoom55aa@068-190-177-201.res.spectrum.com) |
| 2020-10-06 02:37:24 | <dsal> | Profiling is usually a good step before taking action. |
| 2020-10-06 02:37:45 | <dsal> | benchmarking helps both as well, but benchmarking as an effort can be pretty misleading. |
| 2020-10-06 02:38:27 | <hololeap> | i don't even understand the difference between profiling and benchmarking :/ |
| 2020-10-06 02:39:18 | <dsal> | benchmarking is writing a tool that gives you a repeatable measurement. |
| 2020-10-06 02:39:25 | <dsal> | profiling is using a tool that tells you where time is spent. |
| 2020-10-06 02:39:41 | × | rusua_ quits (uid124537@gateway/web/irccloud.com/x-mpizelreyaaubxup) (Quit: Connection closed for inactivity) |
| 2020-10-06 02:40:03 | <dsal> | So profiling might tell you that a particular function is where you spend a lot of your time. So you write a benchmark for that function, and then do stuff to the implementation until the benchmark gives you consistently better results. |
| 2020-10-06 02:40:18 | <dsal> | It's a little tricky in haskell, but the tools are helpful. |
| 2020-10-06 02:40:30 | <hololeap> | what tools should i be looking into? |
| 2020-10-06 02:40:53 | <dsal> | criterion (or whatever that lighter version is people use, but I still use criterion, I think) |
| 2020-10-06 02:41:11 | <dsal> | And like, wherever "how to profile haskell" takes you. |
| 2020-10-06 02:42:02 | <hololeap> | cool, i will crawl the web for it, but i also appreciate specific advice from people who have done it. |
| 2020-10-06 02:42:24 | <dsal> | stack test --profile |
| 2020-10-06 02:42:37 | <dsal> | It's a report you read. |
| 2020-10-06 02:43:21 | <dsal> | Your test or application or whatever runs and then you look at it, stroke your bear, say "hmm... I see" and then your code is faster. |
| 2020-10-06 02:44:01 | <dsal> | In any case, you don't try to optimize anything you're not measuring. |
| 2020-10-06 02:44:13 | → | nbloomf joins (~nbloomf@2600:1700:83e0:1f40:71a4:5e3f:3433:7ae1) |
| 2020-10-06 02:44:19 | <dsal> | I've seen every optimization you can think of slow code down. |
| 2020-10-06 02:44:41 | → | abhixec joins (~abhixec@c-67-169-141-95.hsd1.ca.comcast.net) |
| 2020-10-06 02:44:41 | <hololeap> | is the species of bear a crucial variable in this equation? |
| 2020-10-06 02:45:02 | × | cr3 quits (~cr3@192-222-143-195.qc.cable.ebox.net) (Quit: leaving) |
| 2020-10-06 02:45:16 | <dsal> | Maybe. It's best to go in without assumptions. |
| 2020-10-06 02:45:17 | ski | . o O ( "Let's hug a bear." ) |
| 2020-10-06 02:45:57 | → | falafel joins (~falafel@2605:e000:1527:d491:99fe:5613:f0a7:56f0) |
| 2020-10-06 02:46:17 | → | Stanley00 joins (~stanley00@unaffiliated/stanley00) |
| 2020-10-06 02:47:55 | × | ralejs_ quits (~ralejs@2620:10d:c093:400::5:2842) (Read error: Connection reset by peer) |
| 2020-10-06 02:48:23 | → | ralejs joins (~ralejs@2620:10d:c093:400::5:2842) |
| 2020-10-06 02:49:31 | → | vicfred joins (~vicfred@unaffiliated/vicfred) |
| 2020-10-06 02:50:51 | ← | zoom55AA parts (~zoom55aa@068-190-177-201.res.spectrum.com) ("WeeChat 2.9") |
| 2020-10-06 02:51:40 | → | zoom84 joins (~zoom55aa@068-190-177-201.res.spectrum.com) |
| 2020-10-06 02:51:47 | × | lagothrix quits (~lagothrix@unaffiliated/lagothrix) (Killed (hitchcock.freenode.net (Nickname regained by services))) |
| 2020-10-06 02:51:55 | → | lagothrix joins (~lagothrix@unaffiliated/lagothrix) |
| 2020-10-06 02:54:06 | × | falafel quits (~falafel@2605:e000:1527:d491:99fe:5613:f0a7:56f0) (Remote host closed the connection) |
| 2020-10-06 02:56:58 | hackage | reanimate-svg 0.12.0.0 - SVG file loader and serializer https://hackage.haskell.org/package/reanimate-svg-0.12.0.0 (DavidHimmelstrup) |
| 2020-10-06 02:58:35 | → | jle` joins (~mstksg@unaffiliated/mstksg) |
| 2020-10-06 02:58:54 | → | falafel joins (~falafel@2605:e000:1527:d491:99fe:5613:f0a7:56f0) |
| 2020-10-06 03:00:01 | × | rob01 quits (~rob0@178.162.204.214) () |
| 2020-10-06 03:01:34 | → | drbean joins (~drbean@TC210-63-209-99.static.apol.com.tw) |
| 2020-10-06 03:02:55 | × | berberman_ quits (~berberman@2408:8207:2560:ee60::a44) (Ping timeout: 240 seconds) |
| 2020-10-06 03:03:40 | × | jle` quits (~mstksg@unaffiliated/mstksg) (Ping timeout: 256 seconds) |
| 2020-10-06 03:04:09 | → | berberman joins (~berberman@2408:8207:2563:5ae0:584e:a9ff:fe9b:d3fe) |
| 2020-10-06 03:06:25 | × | drbean quits (~drbean@TC210-63-209-99.static.apol.com.tw) (Client Quit) |
| 2020-10-06 03:16:08 | → | notzmv` joins (~user@177.45.26.174) |
| 2020-10-06 03:17:23 | × | notzmv quits (~user@unaffiliated/zmv) (Ping timeout: 240 seconds) |
| 2020-10-06 03:17:27 | → | elliott_ joins (~elliott@pool-108-51-141-12.washdc.fios.verizon.net) |
| 2020-10-06 03:17:38 | × | bloodstalker quits (~bloodstal@46.166.187.178) (Read error: Connection reset by peer) |
| 2020-10-06 03:18:04 | <zoom84> | when I load a module with a type error in a function, GHCI shows me the expected and actual types, and also shows me all the bindings. is there a way to display the bindings on command for a given function, outside of compile errors |
| 2020-10-06 03:18:51 | <dsal> | The bindings? Are you debugging? |
| 2020-10-06 03:18:58 | <dsal> | Or do you just want type annotations? |
| 2020-10-06 03:18:59 | <dsal> | :T fix |
| 2020-10-06 03:19:00 | <dsal> | :t fix |
| 2020-10-06 03:19:02 | <lambdabot> | (a -> a) -> a |
| 2020-10-06 03:19:21 | <zoom84> | more exploring than debugging |
| 2020-10-06 03:19:37 | <zoom84> | :t shows me the sig. i'm looking to the the sig and the bindings that resulted from it |
| 2020-10-06 03:19:39 | <lambdabot> | error: |
All times are in UTC.