gmane.comp.lang.haskell.glasgow.user

Andrew Hunter | 19 Jul 02:53

Building libraries with ticky-ticky

Hi,

I have some code I want to use ticky-ticky profiling on (if it
matters, I want some of the data ticky-ticky collects about frequency
of updates and related matters.)  However, I'm specifically interested
in the code running with some modificiations I've made to the RTS, so
I need to build GHC with ticky-ticky.

That in itself isn't hard--the documentation said to just run "make
way=t" in rts/, which seemed to work; but the documentation also said
that to get meaningful numbers, I should make sure to build the
libraries with ticky-ticky (which makes sense--I'm interested in the
same data whether or not the updates happen in a function from List or
one I wrote, &c.)

The documentation does *not*, however, say (anywhere I can find) how
to do this!  My natural guess was to go into mk/build.mk, and add
-ticky to GhcLibHcOpts, but that didn't work (regardless of whether I
had previously built a ticky rts, this produced a multitude of linker
errors.)  I also tried, on a lark, adding "t" to GhcLibWays, and this
didn't die, but I'm unclear if it...did anything at all, really.  I
see no way to really tell one way or another.

So, any help or advice on how to tell the GHC build system to build a
set of libraries with ticky-ticky profiling enabled would be greatly
appreciated. (FWIW, I'm not distributing anything, so it'd be more
than adequate for stuff to be broken for non ticky use, I just need to
build some test executables and be sure they're logging the right
data.)

(Continue reading)

headers

Tim Chevalier | 21 Jul 06:08

Re: Building libraries with ticky-ticky

On 7/18/08, Andrew Hunter <ahunter <at> cs.hmc.edu> wrote:
>  The documentation does *not*, however, say (anywhere I can find) how
>  to do this!  My natural guess was to go into mk/build.mk, and add
>  -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I
>  had previously built a ticky rts, this produced a multitude of linker
>  errors.)  I also tried, on a lark, adding "t" to GhcLibWays, and this
>  didn't die, but I'm unclear if it...did anything at all, really.  I
>  see no way to really tell one way or another.
>

Hi, Andrew--

I'm not surprised that building the libraries with ticky enabled
doesn't work, because when I fixed ticky-ticky profiling a year and a
half ago after it was bit-rotted, I hardly tested it and all and
certainly didn't try building the ticky libraries.

If I try "make way=t" in libraries/, which should be the proper way to
build the ticky libraries, I get errors, so I'm surprised it succeeded
for you (unless the build system thought that the libraries were
up-to-date and didn't try building the ticky version.)

The reason you got linker errors was because, I assume, you had
compiled the libraries with -ticky but you weren't passing the -ticky
flag to GHC when you compiled your program. If you don't pass the
-ticky flag, GHC doesn't link with the ticky RTS, so the library code
will include all sorts of undefined symbols.

But since you said below that it's OK if things are broken for
non-ticky use, you should just be able to do:

(Continue reading)

headers

Andrew Hunter | 21 Jul 08:35

Re: Building libraries with ticky-ticky

On Sun, Jul 20, 2008 at 09:08:58PM -0700, Tim Chevalier wrote:
> I'm not surprised that building the libraries with ticky enabled
> doesn't work, because when I fixed ticky-ticky profiling a year and a
> half ago after it was bit-rotted, I hardly tested it and all and
> certainly didn't try building the ticky libraries.
> 

I'm not surprised to see this answer--looking at tickets and mailing lists, it was clear that ticky-ticky
wasn't in the best of shape, but I couldn't figure out what exactly the state of affairs was, so I figured I'd ask.

> The reason you got linker errors was because, I assume, you had
> compiled the libraries with -ticky but you weren't passing the -ticky
> flag to GHC when you compiled your program. If you don't pass the
> -ticky flag, GHC doesn't link with the ticky RTS, so the library code
> will include all sorts of undefined symbols.
> 

Right--thing is, it seemed I was getting linker errors on compiling
the *libraries*--which seems weird, given that the libraries shouldn't
be getting linked, should they?  I'm not entirely sure this is what I
was seeing, so, well, not a huge consideration, but it does seem
weird.

> But since you said below that it's OK if things are broken for
> non-ticky use, you should just be able to do:
> $ cd libraries/
> $ make clean
> $ make EXTRA_HC_OPTS=-ticky
> $ cd [wherever]
> $ ghc -o foo -ticky foo.hs

(Continue reading)

headers

Tim Chevalier | 21 Jul 09:55

Re: Building libraries with ticky-ticky

On 7/20/08, Andrew Hunter <ahunter <at> cs.hmc.edu> wrote:
>
> Right--thing is, it seemed I was getting linker errors on compiling
>  the *libraries*--which seems weird, given that the libraries shouldn't
>  be getting linked, should they?  I'm not entirely sure this is what I
>  was seeing, so, well, not a huge consideration, but it does seem
>  weird.

That is indeed weird, and I don't know why that would be happening. It
didn't happen after you rebuilt in a clean directory, though, right?
(Or at least that's what you seem to imply below.)

>
> After removing "p" from GhcLibWays, which makes sense--the docs make
>  it clear we can't combine prof and ticky, though it also implies that
>  it maybe *should* work; might someone what to look into this?--this
>  worked great, thanks.  My tests are running nicely and giving what
>  seems like accurate data.  Thanks for the very helpful response.
>

I think combining prof and ticky might be nontrivial, because the RTS
has all sorts of conditional compilation in it that may be predicated
on prof and ticky being mutually exclusive. At least, it's not
something I would want to dive into implementing unless I had a good
reason, and after all, you can just recompile the same code repeatedly
with different options to get both prof and ticky results (although
that could get annoying.)

>
> Sweet.  Admittedly I'm not yet a GHC wizard, but I'd love to help out

(Continue reading)