Logs: freenode/#haskell
| 2020-11-16 16:54:39 | <merijn> | tomjaguarpaw: Ok, rephrase, this input should be independent of your benchmark, yes |
| 2020-11-16 16:54:44 | <merijn> | Uniaika: It has some other benefits too |
| 2020-11-16 16:54:58 | <tomjaguarpaw> | What do you mean by "independent"? |
| 2020-11-16 16:55:36 | <merijn> | Uniaika: One problem with many GC solutions is "fragmentation" i.e. if all your data is scattered throughout your memory, it can be hard to find space to allocate huge chunks. Compacting avoids this by resulting in zero fragmentation |
| 2020-11-16 16:56:02 | <merijn> | tomjaguarpaw: Well, you can use a compact region to GC you 1 GB ahead of time and make future GC (during your benchmark) essentially free |
| 2020-11-16 16:56:30 | <merijn> | Uniaika: There's another benefit. If all data in your heap is compact at the start of your heap, your allocator becomes *really* cheap |
| 2020-11-16 16:56:37 | <tomjaguarpaw> | Interesting. I have never done that. |
| 2020-11-16 16:56:50 | <tomjaguarpaw> | That sounds nice. |
| 2020-11-16 16:57:01 | hackage | lz4-hs 0.1.5.1 - lz4 bindings for Haskell https://hackage.haskell.org/package/lz4-hs-0.1.5.1 (vmchale) |
| 2020-11-16 16:57:05 | × | enoq quits (~textual@194-208-146-143.lampert.tv) (Quit: Textual IRC Client: www.textualapp.com) |
| 2020-11-16 16:57:21 | <merijn> | Uniaika: Basically, your allocator is just "a pointer to the end of the current use region of the heap", allocation is just "increment pointer by 20 bytes". Which is good because lazy languages don't just produce a lot of garbage, they allocate a lot too |
| 2020-11-16 16:58:06 | <merijn> | tomjaguarpaw: Basically, you GC an entire chunk of data into a separate compact region and instead of copying the data on every GC, it only copies the entry point to the region |
| 2020-11-16 16:58:36 | <merijn> | tomjaguarpaw: https://tech.channable.com/posts/2020-04-07-lessons-in-managing-haskell-memory.html |
| 2020-11-16 16:58:38 | → | vacm joins (~vacwm@70.23.92.191) |
| 2020-11-16 16:59:18 | <tomjaguarpaw> | Cool, thanks merijn! That could be very handy. Right now I am measuring GC time and subtracting it :P |
| 2020-11-16 17:00:08 | <merijn> | tomjaguarpaw: It will obviously slow down your overall time to run the benchmarks (if you use data only once and need to copy all of it first, that's slower). But it's deterministic at least |
| 2020-11-16 17:00:29 | → | knupfer joins (~Thunderbi@200116b82cb80f00d4db69fffe520a17.dip.versatel-1u1.de) |
| 2020-11-16 17:00:29 | × | knupfer quits (~Thunderbi@200116b82cb80f00d4db69fffe520a17.dip.versatel-1u1.de) (Client Quit) |
| 2020-11-16 17:00:31 | × | conal quits (~conal@64.71.133.70) (Quit: Computer has gone to sleep.) |
| 2020-11-16 17:00:43 | → | knupfer joins (~Thunderbi@i5E86B4E0.versanet.de) |
| 2020-11-16 17:01:31 | × | Amras quits (~Amras@unaffiliated/amras0000) (Ping timeout: 272 seconds) |
| 2020-11-16 17:01:53 | × | justanotheruser quits (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 260 seconds) |
| 2020-11-16 17:02:01 | <tomjaguarpaw> | I don't really mind that. Copying the data will be quick compared to running the function. |
| 2020-11-16 17:02:51 | → | cole-h joins (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) |
| 2020-11-16 17:03:44 | → | kritzefitz_ joins (~kritzefit@212.86.56.80) |
| 2020-11-16 17:03:50 | → | idhugo_ joins (~idhugo@80-62-116-202-mobile.dk.customer.tdc.net) |
| 2020-11-16 17:04:01 | <glguy> | Anyone what the complexity is of ghc-compat's compactAdd? I'm wondering if it has to copy the whole compact region or if it is able to add incrementally |
| 2020-11-16 17:04:31 | <merijn> | glguy: Sounds like a question for #ghc :) |
| 2020-11-16 17:04:45 | × | quarters quits (~quarters@unaffiliated/quarters) (Ping timeout: 240 seconds) |
| 2020-11-16 17:06:05 | × | Tario quits (~Tario@201.192.165.173) (Read error: Connection reset by peer) |
| 2020-11-16 17:06:50 | × | idhugo quits (~idhugo@80-62-116-101-mobile.dk.customer.tdc.net) (Ping timeout: 265 seconds) |
| 2020-11-16 17:07:48 | × | incertia quits (~incertia@d60-65-215-180.col.wideopenwest.com) (Ping timeout: 265 seconds) |
| 2020-11-16 17:10:43 | → | p-core joins (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515) |
| 2020-11-16 17:11:06 | × | Ariakenom quits (~Ariakenom@h-82-196-111-82.NA.cust.bahnhof.se) (Read error: Connection reset by peer) |
| 2020-11-16 17:11:21 | → | geekosaur joins (82659a09@host154-009.vpn.uakron.edu) |
| 2020-11-16 17:11:25 | <Martinsos> | I read that ghc recently added a new type of GC, "incremental", that works in a different fashion and should help with avoiding big spikes of GC. How does that fit into the discussion? Can we choose which one we use? Does it affect the strategies around GC? |
| 2020-11-16 17:11:51 | <merijn> | Martinsos: There is a new GC in recent GHCs yes |
| 2020-11-16 17:11:51 | → | idhugo__ joins (~idhugo@80-62-116-101-mobile.dk.customer.tdc.net) |
| 2020-11-16 17:12:15 | <merijn> | Martinsos: The answer is the if you do not require stable latency, the default one is probably best |
| 2020-11-16 17:12:19 | → | Gurkenglas joins (~Gurkengla@unaffiliated/gurkenglas) |
| 2020-11-16 17:12:26 | × | asheshambasta quits (~user@ptr-e1lysawl9rr13i61o92.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2020-11-16 17:12:50 | → | incertia joins (~incertia@d60-65-215-180.col.wideopenwest.com) |
| 2020-11-16 17:13:02 | × | knupfer quits (~Thunderbi@i5E86B4E0.versanet.de) (Ping timeout: 272 seconds) |
| 2020-11-16 17:14:17 | <Martinsos> | merijn: Makes sense! I am planning to try to build a game as a side project, in Haskell, so that is why I was reading about GC - this new GC should be better for games if I got it correctly, to avoid sudden loss of ticks/frames. So I guess we need to set some flag to use non-default one? |
| 2020-11-16 17:14:52 | × | idhugo_ quits (~idhugo@80-62-116-202-mobile.dk.customer.tdc.net) (Ping timeout: 246 seconds) |
| 2020-11-16 17:15:12 | <merijn> | Martinsos: It'd be better for games, yes. Although, honestly I don't think the latency guaranteed by the new GC is good enough for high FPS games |
| 2020-11-16 17:15:41 | <merijn> | At least, not without managing the amount of live data, etc. manually |
| 2020-11-16 17:17:32 | → | christo joins (~chris@81.96.113.213) |
| 2020-11-16 17:18:04 | <Martinsos> | merijn: Cool! I am aware Haskell is probably not the best choice for high FPS games due to GC, C++ would or some lower language would be better choice, but I doubt my game will require that level of performance so it should be fine, and I am excited about modeling everything in Haskell. |
| 2020-11-16 17:18:20 | <merijn> | Martinsos: The max pause time for the new one is 20ms, but a 60 FPS framerate gives you 16.6ms *max* per frame |
| 2020-11-16 17:19:04 | <merijn> | Martinsos: OTOH, you could consider writing a dedicated render loop in C that talkes with Haskell code implementing game logic |
| 2020-11-16 17:19:19 | <merijn> | Then you might get logic pauses, without hitting framerate |
| 2020-11-16 17:19:37 | <Martinsos> | Right, I was hoping I could extract some parts into C if needed! |
| 2020-11-16 17:19:59 | × | hekkaidekapus quits (~tchouri@gateway/tor-sasl/hekkaidekapus) (Remote host closed the connection) |
| 2020-11-16 17:20:18 | <merijn> | And also, just because you *can* hit that latency, doesn't mean you will. If your gamestate is small even the regular collector might be good enough |
| 2020-11-16 17:20:24 | → | hekkaidekapus joins (~tchouri@gateway/tor-sasl/hekkaidekapus) |
| 2020-11-16 17:21:53 | <Martinsos> | Sure, the game will be 2D with lightweight graphics so I don't think it should be an issue. If it will be it will at least be an opportunity to learn more about GC :D. |
| 2020-11-16 17:22:02 | × | christo quits (~chris@81.96.113.213) (Ping timeout: 256 seconds) |
| 2020-11-16 17:22:24 | → | justanotheruser joins (~justanoth@unaffiliated/justanotheruser) |
| 2020-11-16 17:26:37 | × | kuribas quits (~user@ptr-25vy0iaahu2pezvpnfb.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2020-11-16 17:29:54 | → | hexreel joins (~h@2600:1700:28e2:14d0:b0ee:1522:822e:a283) |
| 2020-11-16 17:30:17 | → | Tario joins (~Tario@201.192.165.173) |
| 2020-11-16 17:31:30 | → | conal joins (~conal@64.71.133.70) |
| 2020-11-16 17:35:43 | × | borne quits (~fritjof@200116b864b5430099e934deb93b1409.dip.versatel-1u1.de) (Ping timeout: 272 seconds) |
| 2020-11-16 17:36:12 | → | conal_ joins (~conal@107.181.166.220) |
| 2020-11-16 17:36:20 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2020-11-16 17:36:30 | × | conal quits (~conal@64.71.133.70) (Ping timeout: 260 seconds) |
| 2020-11-16 17:37:12 | × | Aquazi quits (uid312403@gateway/web/irccloud.com/x-nsgilupshvjjyzul) (Quit: Connection closed for inactivity) |
| 2020-11-16 17:38:51 | → | Iceland_jack joins (~user@31.124.48.169) |
| 2020-11-16 17:41:25 | × | hiroaki quits (~hiroaki@ip4d168e73.dynamic.kabel-deutschland.de) (Remote host closed the connection) |
| 2020-11-16 17:42:45 | → | hiroaki joins (~hiroaki@ip4d168e73.dynamic.kabel-deutschland.de) |
| 2020-11-16 17:45:57 | × | conal_ quits (~conal@107.181.166.220) (Quit: Computer has gone to sleep.) |
| 2020-11-16 17:48:33 | → | crdrost joins (~crdrost@2601:646:8280:85f0:51fc:6f63:a768:a428) |
| 2020-11-16 17:49:02 | → | christo joins (~chris@81.96.113.213) |
| 2020-11-16 17:49:36 | × | avdb quits (~avdb@ip-213-49-61-183.dsl.scarlet.be) (Read error: Connection reset by peer) |
| 2020-11-16 17:50:23 | × | ChaiTRex quits (~ChaiTRex@gateway/tor-sasl/chaitrex) (Ping timeout: 240 seconds) |
| 2020-11-16 17:50:31 | → | avdb joins (~avdb@ip-213-49-61-183.dsl.scarlet.be) |
| 2020-11-16 17:50:59 | → | conal joins (~conal@64.71.133.70) |
| 2020-11-16 17:51:28 | × | conal quits (~conal@64.71.133.70) (Client Quit) |
| 2020-11-16 17:52:15 | → | conal joins (~conal@64.71.133.70) |
| 2020-11-16 17:52:45 | → | ChaiTRex joins (~ChaiTRex@gateway/tor-sasl/chaitrex) |
| 2020-11-16 17:53:05 | × | christo quits (~chris@81.96.113.213) (Ping timeout: 240 seconds) |
| 2020-11-16 17:53:25 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2020-11-16 17:53:26 | × | hekkaidekapus quits (~tchouri@gateway/tor-sasl/hekkaidekapus) (Remote host closed the connection) |
| 2020-11-16 17:53:35 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2020-11-16 17:53:49 | → | hekkaidekapus joins (~tchouri@gateway/tor-sasl/hekkaidekapus) |
| 2020-11-16 17:55:35 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2020-11-16 17:56:01 | → | otulp joins (~otulp@ti0187q162-6038.bb.online.no) |
| 2020-11-16 17:57:02 | × | Varis quits (~Tadas@unaffiliated/varis) (Ping timeout: 264 seconds) |
| 2020-11-16 17:58:42 | → | jlamothe joins (~jlamothe@198.251.55.207) |
| 2020-11-16 17:58:47 | × | justsomeguy quits (~justsomeg@unaffiliated/--/x-3805311) (Ping timeout: 260 seconds) |
| 2020-11-16 18:00:01 | × | GothAlice1 quits (~GothAlice@178.162.212.214) () |
| 2020-11-16 18:00:25 | × | xff0x quits (~fox@2001:1a81:529e:a500:93fd:46ff:4df5:fd50) (Ping timeout: 272 seconds) |
| 2020-11-16 18:01:04 | → | xff0x joins (~fox@2001:1a81:529e:a500:b7fe:796e:1fbb:7036) |
| 2020-11-16 18:01:42 | × | crdrost quits (~crdrost@2601:646:8280:85f0:51fc:6f63:a768:a428) (Ping timeout: 260 seconds) |
| 2020-11-16 18:02:27 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2020-11-16 18:03:04 | → | moet joins (~moet@mobile-166-137-177-145.mycingular.net) |
| 2020-11-16 18:04:28 | → | crdrost joins (~crdrost@c-98-207-102-156.hsd1.ca.comcast.net) |
| 2020-11-16 18:08:52 | → | Wood joins (~wood@2001:d08:1003:2574:5caf:6abd:a992:e5a2) |
| 2020-11-16 18:08:52 | × | coot quits (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
All times are in UTC.