#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Do you really need a separate binary file? That seems a bit complicated... Can't you just have literal data in the assembly file? There are a bunch of other tickets about literal strings: * #16014 * #15210 * #15113 * #13390 Would any of these get fixed? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have experimented with this in the following branch: https://gitlab.haskell.org/hsyl20/ghc/tree/hsyl20-T16190 It adds a GHC command-line flag to choose the threshold (in bytes) above which the strings are dumped in a binary file (e.g. `./inplace/bin/ghc- stage2 -fbinary-string-threshold=200`). The current implementation performs the transformation in the tidy pass. I'm not sure if it is the best place to do it. The included `bench_literal.sh` script generates an Haskell source file which prints a string literal and then benches the time required to compile it. Below are the results for different string lengths. With this test, the optimization starts to be really noticeable for string literals

500K.

|| Size || No optimization || Threshold 100 || Gain || || 128 || 0.730 || 0.770 || -5% || || 3K || 0.731 || 0.829 || -13% || || 30K || 0.736 || 0.805 || -9% || || 100K || 0.804 || 0.856 || -6% || || 500K || 1.038 || 0.912 || +12% || || 1M || 1.342 || 1.101 || +18% || || 2M || 1.926 || 1.446 || +25% || || 3M || 2.539 || 1.805 || +29% || || 30M || 20.182 || 10.244 || +49% || I couldn't test with TH generated string literals as it crashes the compiler because some names become garbage with the optimization enabled. We should probably only enable the optimization if we generate an actual linked object file. It isn't done yet. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

What does "no optimisation" and "threshold 100" mean? I though if "threshold 100" means that if a literal is > 100 bytes then it is put in

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): the extra file, then every single line will do that, so the threshold is irrelevant. Indeed with threshold=100 the optimization applies in every tested case to the string literal in the file. I could have written "optimization enable" but then we would have wondered what the threshold was (in particular if the optimization was triggered for small strings).

I wonder why it every slows down? Just the extra file handling?

I guess it's extra file handling (generation and linking) + the traversal of the module bindings. With the small strings, this test seems to be consistently worse with the optimization enabled (i.e. it's not just measure noise). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds great! Before you are done, could you write a Note that gives a birds-eye view of all the moving parts involved in string literals, and point to it from appropriate places? Thanks for working so hard on this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): @simonpj I will add a note for this one before submitting a MR. @hvr Yes. With the new approach there is no interaction at all as we don't perform any substitution in Core anymore. Whenever the NCG has to embed a big chunk of bytes, it can use the ".incbin" technique. If we add literals that use `ByteArray`, we can easily dump them into a file too, whatever their actual contents is: big `ByteArray`s are already pinned by GHC so we just have to `write` them by using their address and size. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/143 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed Comment: Merged in master with 1d9a1d9fb8fe0a1fea2c44c4246f102ff3e1f3a3 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/143 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"0f1eb88c93143359fa671bb72aceebc299c87a95/ghc" 0f1eb88c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0f1eb88c93143359fa671bb72aceebc299c87a95" Add perf test for #16190 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16190#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler