+list
---------- Forwarded message ---------- From: Guido Trotter <[email protected]> Date: Fri, Aug 30, 2013 at 2:42 PM Subject: Re: [PATCH master] (EXPERIMENTAL) Optimize Haskell compilation To: "Jose A. Lopes" <[email protected]> On Fri, Aug 30, 2013 at 2:25 PM, Jose A. Lopes <[email protected]> wrote: > This patch is an early attempt at optimizing compilation of Haskell > binaries. Currently, it optimizes only 'hs2py-constants'. If you > look at the diff, you will the changes necessary to optimize a Haskell > binary target. The same ideas proposed in this patch for > 'hs2py-constants' should work on the other binaries as well. > > In short, the idea is to compile (on demand, that is, when necessary) > each source file to a normal object file, a coverage object file, and > a profiling object file. Also, the binary is linked with the proper > object files. This is achieve with some Makefile variables: > > 1. *_SRCS: holds the .hs files > 2. *_OBJS: holds the .o files (no coverage or profiling) > 3. *_COVERAGE_OBJS: holds the .hpc.o files (with coverage) > 4. *_PROFILE_OBJS: holds the .prof.o files (with profiling) > > Then, rewrite the Haskell binary target to fetch the proper > dependencies. > > As a result, on the command line there are the following possiblities: > > 1. normal compilation > > make src/hs2py-constants > > 2. compile with coverage > > make HCOVERAGE=true src/hs2py-constants > > 3. compile with profiling > > make HPROFILE=true src/hs2py-constants > > This patch is just an early draft. Comments are highly appreciated. > If any of you see a problem that I have missed, please let me know. > > Signed-off-by: Jose A. Lopes <[email protected]> While right now we don't have library differences or "ifdefs" differences, there are plans to get some. See for example bug: https://code.google.com/p/ganeti/issues/detail?id=535 This should not stop us from doing this, as it would still be an improvement to compile everything twice (one with test and one without) than $number_of_binaries. I am wondering if we should take it one step further: 1) define various "profiles" that a haskell program can be compiled with: HCOVERAGE=c HPROFILE=p HTEST=t HMYLIBRARY=q (future possible use) (maybe not the best possible list. also, are all of these "single" profiles, mutually exclusive, or should they be flags that can be added or removed from a compilation, so I can choose Coverage+Profile, or Test+Profile+Coverage, ...) 2) Define which .hs support which feature (eg HMYLIBRARY could be an ifdef just in two files, so no point in compiling all other files with or without it) 3) When compiling a binary find the right profile (which depends on the configure values, and on the binary itself) 4) Compile each .hs only once per needed profile, eliminating the flags it doesn't support (eg cpqt would be with with all the flags above, but another .hs would go cpt if it doesn't support the "q" flag) Finally link each binary with the correct .o depending on the flags so that duplication is reduced to the minimum. Or maybe this is too complex and it's friday and I shouldn't think too much. :p But I just wanted to throw it in, just in case there were comments. Thanks, Guido -- Guido Trotter Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370
