Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documenting best practice for profiling *internals* of Julia #6639

Closed
ArchRobison opened this issue Apr 25, 2014 · 13 comments
Closed

Documenting best practice for profiling *internals* of Julia #6639

ArchRobison opened this issue Apr 25, 2014 · 13 comments
Labels
building Build system, or building Julia or its dependencies docs This change adds or pertains to documentation

Comments

@ArchRobison
Copy link
Contributor

Julia compilation speed is important, and to study it requires profiling the compiler, including LLVM. So I'd like to use this issue to collect the best known practices, and maybe even get it documented somewhere. Basically, the issue is how to turn on debugging symbols in the binaries without turning on assertions and other baggage.

[Updated 2014-Apr-28] See later note for current best practice. Rest of this note retained only for preserving context of later comments.


Here is what I've been doing so far (which is likely not best possible practice):
1.In Make.user, include the lines:

USE_INTEL_JITEVENTS = 1

The first line is necessary if using Intel VTune Amplifier.
2. Start a release build. After LLVM is configured, I stopped the process and edited julia/deps/llvm-3.3/build_Release and uncommented these two lines (not consecutive):

DEBUG_SYMBOLS = 1
KEEP_SYMBOLS = 1

Then I rebuilt LLVM and Julia.

It appears that the LLVM configure script has options --enable-debug-symbols and --enable-keep-symbols to set said symbols above. But it's unclear to me if these can be somehow set in Make.user and passed on down to LLVM's configure script.

@tkelman
Copy link
Contributor

tkelman commented Apr 25, 2014

For better ways of sending new flags to LLVM's configure:
If you're not using LLVM_SANITIZE in Make.user then you should be able to use LLVM_CC = --enable-debug-symbols --enable-keep-symbols to get them sent to LLVM's configure (not the intended usage here, could easily change). The more proper way to do it would be adding a couple lines here https://github.com/JuliaLang/julia/blob/master/deps/Makefile#L204-L246 to put these into LLVM_FLAGS based on some new Make.user parameter. Or allowing LLVM_FLAGS to start out nonempty by using += from the beginning.

ViralBShah added a commit that referenced this issue Apr 26, 2014
…user

Also add --enable-keep-symbols --enable-debug-symbols when doing `make LLVM_DEBUG=1`
As discussed in #6639.
@ViralBShah
Copy link
Member

You can now set LLVM configure options in Make.user. Also, make LLVM_DEBUG=1 should do what you want.

@ivarne
Copy link
Member

ivarne commented Apr 26, 2014

Shold we document all these Make.user configuration options somewhere?

@timholy
Copy link
Member

timholy commented Apr 26, 2014

The FAQ?

@ViralBShah
Copy link
Member

The thing is that you can pretty much override anything in our Makefiles through Make.user. If we want to do this, we should probably just have a Building Julia section in our manual, and thoroughly document various build related configuration options.

@ivarne
Copy link
Member

ivarne commented Apr 26, 2014

There is of course the problem that build options tend to be added without much thought (or inadvertently broken), so any documentation will quickly be outdated. Still I think some of these options deserves to listed somewhere. Makefiles can be quite hard to read if you want to find out how things work.

@ViralBShah
Copy link
Member

I think the reverse ought to be true though. Options that are documented should be treated no different than APIs. Any changes to documented options should reflect in documentation and version updates.

@ArchRobison
Copy link
Contributor Author

My impression is that LLVM_DEBUG=1 not only retains debugging symbols, but also turns off optimization. So it's not quite the right thing for doing profiling, since LLVM is in C++ and turning off inlining can severely skew profiles.

@ViralBShah
Copy link
Member

We can certainly enable optimizations in LLVM_DEBUG, if ok with others. @loladiro ?

@Keno
Copy link
Member

Keno commented Apr 28, 2014

At some levels there's not much difference between retaining debug symbols and turning off optimizations. C++ relies on heavy inlining to make anything fast, so you'll never get great stack traces when debugging optimized code.

@ViralBShah
Copy link
Member

I guess there is the generic LLVM_FLAGS, which you can use to pass in the exact sequence of configure options you want. Perhaps we just leave it at that?

@ArchRobison
Copy link
Contributor Author

Using LLVM_FLAGS seems reasonable to me. With #e220dd2, here's current best practice that I know of for compiling Julia for internal profiling:

  1. In Make.user, include the lines:
USE_INTEL_JITEVENTS = 1
LLVM_FLAGS += --enable-debug-symbols --enable-keep-symbols
SHIPFLAGS += -g

[Updated 2014-May-7] The first line is necessary if you are using Intel VTune Amplifier. If using Intel VTune Amplifier, consider applying this patch, otherwise you may see warnings about the "sigalstack is too small".

  1. Run make

Amplifier has been complaining about needing a bigger signal stack, but I haven't figured out whether that's hurting the profiles.

@kshyatt kshyatt added the potential benchmark Could make a good benchmark in BaseBenchmarks label Sep 15, 2016
@KristofferC KristofferC removed the potential benchmark Could make a good benchmark in BaseBenchmarks label Jul 17, 2018
@vtjnash vtjnash closed this as completed Jan 25, 2022
@vtjnash
Copy link
Member

vtjnash commented Jan 25, 2022

we have better support for this now (with make LLVM_DEBUG=symbols USE_BINARYBUILDER_LLVM=0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
building Build system, or building Julia or its dependencies docs This change adds or pertains to documentation
Projects
None yet
Development

No branches or pull requests

9 participants