Newest at the top
| 2025-02-08 12:00:58 +0100 | <geekosaur> | unless you mean unregisterised mode, but you absolutely don't want that if you want speed; it's intended for porting and produces extremely slow but extremely portable ANSI C |
| 2025-02-08 11:59:56 +0100 | <geekosaur> | not since 7.2 |
| 2025-02-08 11:59:28 +0100 | <euouae> | does ghc still target C? because tahts' what STG targets in SPJs paper |
| 2025-02-08 11:53:47 +0100 | <geekosaur> | (certainly old implementation papers will be too old to help, especially since none of them will know about amd64 or aarch64) |
| 2025-02-08 11:48:28 +0100 | <geekosaur> | there are a few things at Cmm and STG levels but you won't find anything except the ghc source to help with those |
| 2025-02-08 11:48:19 +0100 | <euouae> | Ah, hm... I meant that I want to write code that is fast, not to study the optimizations of GHC |
| 2025-02-08 11:47:50 +0100 | <geekosaur> | almost all optimizations in ghc are done at the level of Core |
| 2025-02-08 11:47:46 +0100 | <euouae> | I've read that Core does not capture certain issues with memory use & other benchmarking analysis |
| 2025-02-08 11:47:25 +0100 | <geekosaur> | GRIN itself seems to be kinda stuck, but STGi will show you how STG works without requiring you to delve into implementation details (SPJ's paper talks a lot about register allocation etc.) |
| 2025-02-08 11:47:02 +0100 | <euouae> | when you say stick to Core for optimizations & parallel what do you mean? |
| 2025-02-08 11:46:47 +0100 | <euouae> | nice thanks |
| 2025-02-08 11:46:02 +0100 | <geekosaur> | https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-inter… |
| 2025-02-08 11:45:51 +0100 | <int-e> | I don't really know which one comes closest to current GHC in terms of syntax and semantics. |
| 2025-02-08 11:45:32 +0100 | <geekosaur> | not the while thing, just the external STG interpreter |
| 2025-02-08 11:43:52 +0100 | <int-e> | Hmm there's the more recent "making a fast curry: push/enter vs. eval/apply" paper as well. And another implementation: https://hackage.haskell.org/package/ministg |
| 2025-02-08 11:43:48 +0100 | <euouae> | Are you talking about <https://github.com/grin-compiler/ghc-whole-program-compiler-project>? |
| 2025-02-08 11:43:41 +0100 | <geekosaur> | if you want to write optimized and parallel code, stick to Core |
| 2025-02-08 11:43:07 +0100 | <geekosaur> | *incomplete |
| 2025-02-08 11:43:00 +0100 | <geekosaur> | even though that is imcomplete (e.g. doesn't support update frames) |
| 2025-02-08 11:42:36 +0100 | <geekosaur> | IMO if you want to know how to implement it, read SPJ's paper. If you want to understamnd what's going on down there, see Csaba Hruska's STGi |
| 2025-02-08 11:42:30 +0100 | <euouae> | But if I should say something I guess my goal is to write optimized & parallel code |
| 2025-02-08 11:41:58 +0100 | <euouae> | I'm just messing around with the lower parts I don't have explicit goals |
| 2025-02-08 11:41:49 +0100 | <euouae> | I |
| 2025-02-08 11:39:57 +0100 | <__monty__> | That depends rather more on your goals than anything. |
| 2025-02-08 11:38:20 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-08 11:38:02 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Client Quit) |
| 2025-02-08 11:37:54 +0100 | hazmat_237 | (~hazmat_23@user/Monospace) Monospace |
| 2025-02-08 11:37:54 +0100 | hazmat_237 | (~hazmat_23@2406:7400:56:f19f:793f:9847:668d:4a12) (Changing host) |
| 2025-02-08 11:37:46 +0100 | <euouae> | (including the semantics) |
| 2025-02-08 11:37:44 +0100 | hazmat_237 | (~hazmat_23@2406:7400:56:f19f:793f:9847:668d:4a12) |
| 2025-02-08 11:37:26 +0100 | <euouae> | I noticed that GHC has a -ddump-stg-from-core that looks a lot like what the paper discusses. Is it a good idea to look at this or has it mutated a lot since 1992? |
| 2025-02-08 11:37:08 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-08 11:37:01 +0100 | <euouae> | Hello I'm reading the 1992 STG paper by Jones and I'm wondering if it's worthwhile paying attention to all the technical aspects of the STG language |
| 2025-02-08 11:36:59 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-02-08 11:36:39 +0100 | euouae | (~euouae@user/euouae) euouae |
| 2025-02-08 11:32:56 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-02-08 11:29:18 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-08 11:26:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-08 11:25:17 +0100 | ColinRobinson | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-02-08 11:25:05 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-08 11:24:51 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 11:17:25 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-02-08 11:15:38 +0100 | JuanDaugherty | ColinRobinson |
| 2025-02-08 11:12:52 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-02-08 11:12:19 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-08 11:04:07 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-02-08 11:03:49 +0100 | euleritian | (~euleritia@dynamic-176-006-128-136.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-02-08 11:03:04 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2025-02-08 11:01:47 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Ping timeout: 252 seconds) |
| 2025-02-08 10:56:21 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |