[HN Gopher] Making GHC faster at emitting code (2022)
       ___________________________________________________________________
        
       Making GHC faster at emitting code (2022)
        
       Author : ingve
       Score  : 100 points
       Date   : 2023-05-14 09:06 UTC (13 hours ago)
        
 (HTM) web link (www.tweag.io)
 (TXT) w3m dump (www.tweag.io)
        
       | robertlagrant wrote:
       | I know this is maybe reductive, but I wonder if just skipping
       | SDocs on compile and just recompiling with SDocs enabled on
       | failure, to get a nice error message, would be a viable
       | improvement.
        
         | tikhonj wrote:
         | SDoc is an abstraction for generated formatted text _including
         | the assembly the compiler generates_. The problem was not that
         | the code generator was generating _extra_ output, but that the
         | text-formatting functionality it used was doing extra
         | bookkeeping that made sense for human-readable text but was not
         | necessary for machine-readable assembly.
         | 
         | Using the same abstraction for both seems a bit silly at first,
         | but it helped the codebase stay more consistent and was already
         | pretty well-optimized. The changes in the article optimized it
         | further by splitting out some of the more expensive
         | functionality while keeping the same general engineering
         | advantages.
        
       | kccqzy wrote:
       | > One potential solution would be to allow attaching a pragma to
       | the `IsLine` and `IsDoc` classes to request that GHC aggressively
       | specialize all definitions that use them.
       | 
       | I'd love to see this as an actual feature request. As the article
       | says C++ and Rust both already do this as part of the language
       | definition, and I can see this is just a straightforward change
       | to make abstractions more "zero-cost" so to speak (not including
       | compile time costs).
        
       | samsquire wrote:
       | I compiled to assembly in an experimental barebones compiler, it
       | is easy to get started. If I could host GCC or LLVM in my process
       | and skip the ASCII serialization and parsing, that would be an
       | awesome API. This has given me an idea to blog about...
       | 
       | I'm surprised I couldn't find a library that stores opcodes for
       | each architecture.
       | 
       | I have tried to decipher the Intel x86 manuals but I ended up
       | relying on GCC to see what assembly is produced.
        
         | kccqzy wrote:
         | There was actually a very old and venerable tutorial on writing
         | compilers in Haskell; it did not use ASCII serialization, but
         | instead uses Haskell's FFI to directly invoke LLVM functions to
         | do everything. That's very neat!
         | 
         | https://www.stephendiehl.com/llvm/index.html
        
         | rockwotj wrote:
         | FWIW compiling the LLVM ir is a common approach, and LLVM has
         | builders that don't require serialization
        
       | grrdotcloud wrote:
       | Glasgow Haskell Compiler
       | 
       | Articles and headlines with TLAs without initial definitions are
       | AAF.
        
         | Smaug123 wrote:
         | Would any reader who did not already know the name of the
         | standard Haskell compiler have been any more enlightened if it
         | had said "Glasgow Haskell Compiler" in the first paragraph? As
         | it stands, the first paragraph of the article merely strongly
         | implies it's an optimising compiler for Haskell, moderately
         | strongly implies that it's _the_ compiler for Haskell, and
         | links to the GHC GitLab. I assert that the only reason one
         | might want the words  "Glasgow Haskell Compiler" here is if you
         | wanted to search for it unambiguously, but "GHC haskell" is
         | already entirely unambiguous. It's not like the name is
         | descriptive; you're not going to do anything differently
         | because it was born at the University of Glasgow.
        
           | grammarxcore wrote:
           | I had to open the article to understand what it was about.
           | The initialism is ambiguous; I thought someone might be
           | trying to shorten GitHub Copilot and was curious to see how
           | the team behind it was optimizing its speed. I would have
           | been much more enlightened.
           | 
           | If you're attempting to share something with an audience not
           | steeped in your jargon, it's usually better practice to lead
           | with the full then shorten later.
        
             | kzrdude wrote:
             | One could use the less accurate title "Making haskell
             | faster at emitting code" I guess!
             | 
             | However, don't we have to accept sometimes that the title
             | does not tell the full story, it's just half a sentence
             | after all, it's not even a summary, it's the heading?
        
             | whateveracct wrote:
             | This is HN. Headlines are full of jargon - it's an
             | expectation for a diverse technical forum.
        
       ___________________________________________________________________
       (page generated 2023-05-14 23:01 UTC)