"couldn't properly understand this function" for Haskell (GHC) Hello World about bolt HOT 3 OPEN

I see. From what I can tell there's a lot performance to be gained from improving the existing backend/runtime. BOLT can still help if the resulting code is large and causes a significant amount of instruction cache and TLB misses. On Linux you can measure those running the application under perf -e instructions,L1-icache-misses -- <your app with options>. If you end up with under 5 misses per a thousand instructions, then it's better to look at other options to improve the code. Compute-heavy applications, for example, spend most of their time in loops and are not great candidates for code layout optimizations provided by BOLT.

from bolt.

I don't have an experience with GHC, and I don't have an access to version 8.4.3. However, I tried 7.6.3 with the "Hello World" program, and although BOLT processes the binary, the resulting executable segfaults. It appears there are multiple custom control transfer tables that are embedded into the code, and they are unmarked in the symbol table. stg_ap_p_fast is once instance of a function that uses such tables. Again, I'm unfamiliar with GHC, and cannot know what is the purpose of this function.

In general, since GHC uses non-standard code sequences involving indirect jumps, it will require a special support in BOLT. How important is this for you? Do you have a large performance-critical application written in Haskell?

from bolt.

Cool, I appreciate you trying it out!

I'm out of my depth here but certainly not surprised that BOLT doesn't work on GHC code as I know it's not a platform you test against.

How important is this for you? Do you have a large performance-critical application written in Haskell?

Difficult question! I'm trying out BOLT because I'm curious and wanted to see what would happen and if I could write a blog post about it (though I do write a lot of haskell for a living, some of which needs to be tuned or carefully tested for performance).

But I have real reasons to be interested in BOLT (or similar tools... I don't honestly have a great sense of what BOLT does besides reorder blocks for better locality) vis a vis GHC/haskell:

• much performance depends on optimizations that happen early in compilation (rewrite rules), which are dependent on inlining; in general marking functions INLINE is good for performance, but this does lead to bloat (whether or how much code bloat leads to performance penalties I think is mostly rumor; BOLT seems like a great tool to explore this)
• there are no LTO or similar whole-program optimization passes available
• the native code generator gets very little active development AFAICT; there is almost no strength reduction type optimizations done, the register allocator is not so great (at least I've observed it do a worse job than the LLVM backend), etc. nor does the runtime which is written in C
• the LLVM backend is also, apparently, sort of crufty or in need of tuning or in some way is not well-suited to what GHC needs; maybe some kind of simple peephole pass would make a huge performance improvement

If you are asking whether I'd be interested in contributing time or money the answer is I probably don't have the knowledge to do that at this point. I might be able to help coordinate or shepherd a GHC ticket, if something could be done on that end

from bolt.